Arman Abgaryan* Utkarsh Sharma* Joshua Tobkin
(October 2023)
Abstract
The Proof of Efficient Liquidity (PoEL) protocol, designed for specialised Proof of Stake (PoS) consensus-based blockchains that incorporate intrinsic DeFi applications, aims to support sustainable liquidity bootstrapping and network security. This concept seeks to efficiently utilise budgeted staking rewards to attract and sustain liquidity through a risk-structuring engine and incentive allocation strategy, both of which are designed to maximise capital efficiency. The proposed protocol serves the dual objective of: (i) capital creation by attracting risk capital efficiently and maximising its operational utility for intrinsic DeFi applications, thereby asserting sustainability; and (ii) enhancing the adopting blockchain network’s economic security by augmenting their staking (PoS) mechanism with a harmonious layer seeking to attract a diversity of digital assets. Finally, the protocol’s conceptual framework, as detailed in the appendix, is extended to encompass service fee credits. This extension capitalises on the network’s auxiliary services to disperse incentives and attract liquidity, ensuring the network achieves and maintains the critical usage threshold essential for its sustained operational viability and progressive growth.
1 Introduction
A blockchain is a specialised immutable database operating in a decentralised manner utilising distributed computing resources, employing consensus algorithms, and acting as a secure technological platform to facilitate the execution of transactions. These platforms evolve into ecosystems with digital assets facilitating the exchange of value, assuring economic security, and enabling work. Specifically, note that some of these blockchain networks have core decentralised finance (DeFi) applications (CDAs), which are specific financial applications that are infrastructurally imperative and intrinsically integrated into a blockchain network and its economic framework, enabling the network to meet its objectives. These applications operate using pools of digital assets submitted by liquidity providers (LPs) in smart contracts to facilitate financial transactions, like lending, market making, etc. Naturally, such applications often face a paradoxical causal loop, where they need a minimum viable capital to be operational and attract users, which can only happen if the application experiences sufficient demand to offer compelling returns. Furthermore, the blockchain network underlying the CDAs runs in a decentralised and distributed manner, necessitating the use of consensus mechanisms which enable the network to agree, confirm, and validate transactions. One example of such a consensus mechanism is the Proof-of-Stake (PoS) mechanism where locked (staked) capital (in the form of digital assets) is used to secure the network and assure operational integrity. Therefore, for continuing success of not just CDAs, but also the underlying blockchain network using the PoS consensus mechanism is directly linked to: (a) the amount of (locked) capital it can attract from participants; and (b) the incentives and penalties it uses to encourage and/or discourage behaviours on the network, to harmonise experience.
Whilst blockchain networks operating in a Proof of Stake (PoS) consensus mechanism often seek to attract staked capital in their native staking token — a digital asset that users can lock or “stake”to participate in network operations like transaction validation, in return for potential rewards, and thereby help maintain the economic security and functionality of the blockchain, with stakers often being rewarded for their contribution — as their ability to sustainably attract new capital might be limited, particularly if the perceived risk-adjusted return is not immediately compelling. This means that competition for the acquisition of capital from stakers (including node operators), whose capital base may already be predisposed, leads to an interdependent quandary. Staked capital is only present when the risk-adjusted return is compelling, but this is hard to sustainably achieve until the network has baseline-staked seed capital (economic security guarantees) to be an attractive platform for its users. This creates uncertainty for the network in ensuring the participation of a critical number of service providers and staked capital for operational integrity. A similar quandary exists for participants who have access to capital, but are averse to a direct exposure to the native staking token of the network. This is partly because in the early stages of the network, the price of its native staking token may be volatile[25], and it leads to fluctuation in PoS security guarantees of a network associated with the staked asset’s value. Therefore, constrained diversification of the staked asset base has a disproportionately desirable potential to improve the robustness of security guarantees of the network.
We seek to resolve this paradoxical causal loop through a budgeted incentive program wherein PoEL, an algorithmic program designed to support blockchain networks with CDAs, effectively draws operating capital and enhances the economic realities of the underlying network, encompassing ongoing viability and economic security. The proposed incentive framework facilitates a controlled expansion of the utility of capital submitted to CDA, making it available as staked capital for the network integral to CDAs, thus providing an additional income stream for capital providers. This is achieved by offering risk-aware preferential incentives over and above regular (CDA) fees, which may be denominated in the native staking token of the adopting blockchain network, or otherwise. These incentives allow digital asset holders to fully utilise their risk capital for on-chain economic activities. Such on-chain economic activities can initiate a self-reinforcing cycle where a blockchain network’s core DeFi application seeks to attract risk capital for on-chain economic work, which also secures the network. As the capital base improves, it stabilises the economic fundamentals, which in turn attracts more capital. However, the extent to which CDA capital is available for staking, and its resulting eligibility for additional earnings, is governed by the PoEL protocol.
PoEL achieves the aforementioned vision through a two-pronged approach. First, it solves the interdependent quandary of the minimum viable amount of capital required by the CDAs and the underlying blockchain infrastructure, by serving as a novel mechanism for preferential incentives to attract liquidity. Second, it enables networks to efficiently attract capital locked in a diversity of LP pools through its novel interest rate and collateral guidance framework enabling the risk-conscious extension of the utility of the attracted capital. This has the effect of optimising a diversity of risks and rewards to effectively integrate CDA liquidity pools with the network’s own PoS scheme, thereby, improving the native network’s economic security. It is noteworthy that the proposed framework does not seek to propose an alternative PoS mechanism but rather design an auxiliary protocol which works in conjunction with existing PoS mechanisms for networks with integrated CDAs, to optimise their incentive programs to attract capital. This general framework enables digital asset owners to seek excess returns on their locked capital and enables CDAs to bootstrap liquidity, and networks to mitigate asset-specific risks, thereby improving risk-adjusted returns generated per unit of network resources.
The remainder of the paper is organised as follows: in Sec. 2 we discuss benchmark works of relevance; in Sec. 3 we outline key principles governing the protocol’s architecture; in Sec. 4 we describe the protocol’s architecture, before concluding in Sec. 5.
2 Literature Review
Digital asset-based liquidity bootstrapping in decentralised finance, also referred to as “liquidity mining,”was first introduced by a decentralised exchange IDEX [18], and thereafter improvised by their competitors, e.g. Synthetix [29] and Compound [10]. Such developments paved the way for a period of significant growth for the digital assets industry, reflected in a sharp increase in Total Value Locked (TVL) from $600 Million to $11 Billion between March and September of 2020 [11]. The approach to use additional rewards (denominated in native tokens) to attract liquidity has been adopted by different types of DeFi projects, like money market applications, for e.g., Compound, AAVE [1], Benqi [7], Alchemix [4]; AMM/DEX protocols, such as Uniswap [30], Sushiswap [28], Curve [12], Balancer [5]; insurance protocols like Nexus Mutual [22], InsurAce [19]; and derivative platforms like Perpetual Protocol [26], dYdX [15], Synthetix [29]. Some of these projects, use governance tokens [16] as a mechanism of rewarding additional liquidity. For context, methods of bootstrapping liquidity that are now popular in this domain can trace their origins in traditional finance (e.g. see: [8, 14, 21]).
Related to the concept of liquidity bootstrapping in the digital finance domain, some works that might be helpful for context include the design for UniSwap’s V3 [31] and digital asset exchanges, e.g. [17]. Broadly speaking, liquidity bootstrapping strategies implement reward mechanisms to incentivise liquidity, which could be quantified based on different factors. E.g. Curve [13] used a decentralised governance mechanism to quantify rewards using factors like asset pool weights and characteristics, and similarly, Balancer [6] quantified rewards based on factors like the type of asset, size of the pool and its state, and pool-specific fees. Once calibrated, these rewards are distributed either primarily to LPs (like in the case of Uniswap, Aave, and Curve Finance), or can be extended beyond LPs to stakeholders like traders and borrowers (like in the case of Osmosis, and Compound). However, some of the liquidity mining programs not only incur direct costs but may also expose the adopting applications to indirect costs, stemming from risks leading to manipulative abuse of promotional offerings. Further, the industry has also experienced noteworthy risk events, e.g. wash trading(and by extension, wash transactions involving credit, as witnessed by Compound) like manipulative tactics, as witnessed by FCoin’s [9] liquidity mining program, and flooding of opportunistic hot money - seeking to solely pocket any incentives and dump the digital asset once incentives are collected, instead of using it as an opportunity to be a meaningful participant in an ecosystem.
Therefore, our research seeks to present a cost and risk-conscious liquidity bootstrapping program, to enable blockchain networks with integrated core DeFi applications (CDAs), to maximise the utility of every unit of risked capital, whilst harmonising economic interests of the underlying network and the implementing CDAs. A few examples of networks that have integrated CDAs for cross-chain asset exchange and derivative use-cases include Osmosis [23], and Qasar [27]. The proposed bootstrapping mechanism is most closely related to Osmosis’ [24] incentive mechanism, which not only rewards LPs using AMM fees, but additionally rewards them for value created from assets staked by them in the network, i.e. staking rewards in exchange for assets provided to secure the network. However, the proposed protocol design is distinct from their approaches, as PoEL jointly focuses on capital efficiency and network security, by accommodating a set of well-defined principles and objectives.
3 Objectives
PoEL is defined as an algorithmic policy function, , which maps state observables () to a vector of incentives (), by using its liquidity mining program (), to essentially solve an optimisation problem constrained on the chosen risk measure and total distributable incentive budget (). Whilst being backwards compatible with many existing blockchain networks’ PoS schemes, this design ensures efficient preservation of any financial value being created for the network, by aiming to maximise the expected financial value of total transactional volume and minimise the variance of the value of the asset mix backing the security of the network, subject to stochastic constraints.
Before we progress, we seek to specify a few important concepts:
Definition 1 (Timestep)
A timestep () refers to a specific point in time when a change in state variables is observed, or input parameters are set.
Definition 2 (Epoch)
An epoch () is a short, yet relatively fixed period, akin to block time, representing instances when the protocol executes critical updates. These updates include, but are not limited to, instances such as reward distribution, accepting new users to the system, and enforcement of penalties on participants.
It is important to note that whenever a measure, say - price, carries a subscript , i.e. it is the representative price of the epoch , it means that this is the price available in the last timestep of the epoch, i.e. .
Definition 3 (Unstaking Period)
The unstaking period refers to the predetermined duration of time set by a blockchain network or DeFi platform, which follows a request to withdraw (or unstake) staked assets when the digital assets remain inaccessible or non-transferable.
The unstaking period is designed to promote a blockchain network’s security and stability, and to discourage malicious activities, by preventing abrupt changes in the staked capital and limiting the ease of materialising a malicious act.
Now, we seek to optimise over the decision variable , which is the incentive allocation matrix capturing available incentives across asset pools of a particular CDA and epochs, and present the forthcoming optimisation statement as a framework to motivate the conceptual design of the PoEL protocol presented in sections that follow.
s.t. | (1) | ||||
where, and are the weights representing the importance of each objective, s.t. ; is the length of incentivisation program in epochs; is the expected financial value for the network of total transactional volume in -th epoch; is vector of incentives distributed across asset pools in -th epoch, representing one particular column in the matrix ; represents incentives distributed for asset pool in e-th epoch; is the number of asset pools of CDA , included in the PoEL program; is a probabilistic constraint ensuring that the aggregate risks of the portfolio of asset securing the network do not exceed a certain limit () with a probability of at least ; ensures that the Conditional Value at Risk (cVaR), calculated at a pre-specified confidence interval () stays below a pre-specified limit111Note that the protocol aims to limit the expected shortfall, as indicated in the constraint. It seeks to quantify this by using the portfolio returns of assets. These assets are attracted using the epoch-specific incentives, which is the decision variable in the objective statement of the preceding optimisation problem.; and is the expectation of the variance of the marked-to-market value of the assets backing the economic security of the network222We express the financial value of transactional volume and the variance in nominal terms..
This representative optimisation problem is tackled using the proposed protocol, by way of enabling varied market forces to discover points of dynamic equilibrium (i.e. either local or global optimal solution), reflecting the protocol’s goal of accommodating the requirements and strategies of each rational economic actor. Our deployment of this optimisation framework serves to establish the context for the operating and financial principles that follow, along with the associated objectives, as detailed in the protocol architecture presented in Section 4.
3.1 Operating Principles
Risk 1 (Wash Transactions)
A wash transaction is defined as the predatory activity of transacting (e.g. buying, selling, lending, or borrowing) in an asset, with the sole objective of creating the false impression of market activity, without any meaningful change in ownership, or financial impact. Using the example of a decentralised exchange (DEX), if is the price of the asset, and is the volume traded, we can state that a trade is a wash trade if, for e.g., the DEX experiences the following sequence of trades:
Sell(t+1): | |||
Trade: |
Mitigation 1 (Wash Transactions)
We seek to discourage wash transactions, using the following tools:
- 1.
Mitigation: Disincentivising wash transactions, by e.g. financially incentivising organic user growth, by ensuring that the cost exceeds any expected gains from sustained malicious attempts.
- 2.
Transformations: Transforming point-in-time measures used to drive reward distribution policy to moving averages, makes it harder for malicious actors to manipulate key metrics through wash transactions.
Risk 2 (Continuous Quality Assurance)
In a PoS mechanism, there is a risk that in the event of an adverse change in the fair value of the staked asset, the network’s economic security might be compromised, if assets backing the network security are not marked-to-market.
Mitigation 2 (Continuous Quality Assurance)
The system continuously checks the market price of assets used to secure the network, and exhibits demonstrable intention to make adjustments to assertively tackle any accounting discrepancies which emerge.
Risk 3 (Network Liveness)
PoEL’s operational integrity principle focuses on validator sustenance333Validator sustenance refers to a validator’s ability to actively and effectively perform its role in the adopting network. () where the protocol seeks to maximally avoid all scenarios which increase, or even reinforce the likelihood of a cascading number of nodes from being disqualified from a PoS-based blockchain network, as a result of failing to meet the dynamic financial requirements, e.g. minimum staking requirements 444PoS-based blockchain networks often impose a minimum staking requirement to ensure that participants have a vested interest in the network’s stability and security. By requiring a minimum amount of tokens or cryptocurrency to be staked, the network can discourage frivolous or malicious actors who might otherwise participate without a significant investment, by slashing their staked capital. This requirement helps to align the interests of the stakeholders with the long-term health and integrity of the blockchain network..
Mitigation 3 (Network Liveness)
Operational breaches are mitigated by maintaining a breach-specific threshold, such that the event-specific probability is managed as follows:
(2) |
where is the probabilistic threshold for the likelihood of the occurrence of prespecified operational risk events. And since , in its simplest form we seek to achieve this by incentivising (or imposing) only limited and operationally robust validators to participate in PoEL, thereby reducing the risk of cascading disqualifications which would fundamentally compromise the operational integrity of the network.
Risk 4 (Backward Compatibility)
If the protocol is not backwards compatible with the adopting network’s staking mechanism555The PoEL protocol specifically seeks to be compatible with some existing networks, which use smart contracts to manage staking aspects of their system., it would limit the PoEL protocol’s real-world applicability. This limitation could impact its viability.
Mitigation 4 (Backward Compatibility)
The proposed protocol should not require any major changes to the adopting network’s staking dynamics.
Risk 5 (Stake Centralisation Attack)
A stake centralisation attack refers to an event where a user (or a group of users) amasses such a significant portion of the total staked capital in the PoS-based network, that it undermines the security of a decentralised network as the user(s) effectively control over the network’s decision-making, block creation and transaction validation processes.
Mitigation 5 (Stake Centralisation Attack)
The generally accepted shape of the liquidity density function of any financial asset, whether digital or traditional, implies that the adverseness of execution price (or the resulting market impact) from the execution of trade is positively correlated to the executed volume, and negatively correlated to the liquidity of the asset. On a ceteris paribus basis, if a single token is used for staking in a blockchain network, a malicious stakeholder seeking to attempt to buy a significant portion of the native staking token666A native staking token is a digital asset used for staking in its associated blockchain network, securing the network and enabling stakers to earn rewards in exchange for assuring the quality of the services provided by the network. Native staking tokens (NST) are key elements of a Proof of Stake (PoS) consensus mechanism. will have to incrementally pay a higher cost of execution, by way of higher market impact (especially if the adopting network is in its infancy and the native staking token has limited liquidity), compared with having the capacity to submit multiple assets to satisfy their desired staking outcome, i.e.
(3) |
where represents the market impact of executing a fixed notional value in the native staking token with a market impact function , and represents the market impact of executing a smaller notional value across N-many assets with their respective market impact functions , such that .
However, since market impact functions () are not all the same, a situation arises where the superiority of a market impact function, i.e. its ability to absorb large volumes, is directly related to the ease with which a malicious stakeholder can attempt (or successfully execute) a stake centralisation attack.
Therefore, to ensure that the incentive mechanism that enables the use of multiple assets as staked capital to secure an early-stage network, does not end up easing natural market-based barriers to a stake centralisation attack, we seek to limit the portion of capital staked through other digital assets which aren’t a native staking token, as follows:
(4) |
where is the value staked in multiple assets, and not the native staking token, value staked in the network in native staking token and is the optimal threshold which mitigates the risk.
Risk 6 (Incentive Disharmony)
Incentives provided as part of the PoEL protocol may have a predatorial effect on the incentive structure of the adopting network777Absence of incentive harmony can, e.g., distort a capital provider’s motivation to select the best validators, leading to an important agent like validator being delegated-to without merit..
Mitigation 6 (Incentive Disharmony)
To mitigate the risk of PoEL’s incentive structure being disharmonious to the incentive structure of the adopting blockchain network, the PoEL protocol penalises destructive (malicious and/or non-contributory) stakeholders by slashing their locked capital.
This framework and foreseen benefits ought to be balanced against additional risks it poses, which if unchecked, leaves the entire system more vulnerable in times of extreme volatility. Therefore, we seek to ensure that the PoEL protocol considers a variety of risks, including, but not limited to market risk.
3.2 Financial Principles
Risk 7 (Realised Volatility)
Variability, for e.g., as measured by volatility, in the basket of assets backing the network introduces stochasticity in its economic security. This can be quantified at an asset level, as follows:
(5) |
where represents an asset’s return, and is the number of assets in the portfolio.
Mitigation 7 (Realised Volatility)
The system hom*ogenises the risk-adjusted desirability of individual assets and enforces the volatility requirements on the portfolio of assets utilised in PoEL.
Risk 8 (Tail Risk)
In addition to the preceding risk which focuses on mitigating risks emerging from the second moment of returns distribution, which can be somewhat said to be “ongoing”risks, the network’s economic security is also exposed to unexpected losses, for e.g. as captured by measures like the Expected Shortfall[2], which may also additionally exacerbate the risk of cascading disqualification of validators.
Mitigation 8 (Tail Risk)
To mitigate the tail risk, the protocol’s objective statement is constrained by an expected shortfall limit.
Risk 9 (Liquidity Risk (Viscosity))
Liquidity risk is the risk that the protocol would be unable to buy or sell an asset without leading to a meaningfully adverse price impact, where the adverse price impact is quantified as , and in a simplified form, it can be expressed as a function of trading volume, bid-ask spread, and order size.
(6) |
where is the trading volume of the asset over a lookback window, is the bid-ask spread, and is the order size.
Mitigation 9 (Liquidity Risk (Viscosity))
A minimum liquidity requirement is asserted for each of the qualifying assets.
3.3 Ancillary Objectives
Based on the preceding principles, we now outline the ancillary objectives PoEL protocol seeks to target, and the incentives used to catalyse their realisation.
Target 1 (Tenure)
To incentivise the stickiness of capital submitted to liquidity pools and its subsequent use for network security, attributable incentives are positively correlated to the length of time capital is locked.
Incentive 1 (Tenure)
(7) |
where, represents the time for which -th LP capital is locked, represents the associated incentive, represents the maximum incentive available to distribute to a particular LP at a particular timestep, is the minimum incentive (portion of ), is a scaling factor that adjusts the steepness of the sigmoid curve, is a mid-point value around which the transition from the minimum to maximum incentive starts to become significant, and is a new parameter that adjusts the curve’s shape, providing additional control over how rapidly the incentive increases as locking time approach and surpasses mid-point.
Now, the role of an investor seeking to lock in an amount would be to quantify the present value of these forward incentive rates at a point in time , as follows:
(8) |
where the integral captures the continuously compounding forward incentive rates888We assume that continuous compounding would be harmonious with the adopting blockchain network’s economics., by additionally introducing an interest rate () on top of the incentive rate, aimed at capturing the slope of the interest rate curve. Note, that is a variable of integration, representing the time when incentive’s received.
Target 2 (Capital Productivity )
Capital productivity is defined as the productive utilisation of the attracted capital, where productivity is defined as a net positive utility of the expected return (incl. any additional fees generated through increased volume) when adjusted for the cost of capital.
Incentive 2 (Capital Productivity)
We assume market participants to be rational, and therefore, the PoEL protocol assumes that given its sustainable and competitive structure which dynamically responds to changes in exogenous factors, capital productivity is either always achieved, or incentive structures are updated such that there is progress in its direction.
Target 3 (Responsiveness)
The protocol aims to be responsive to changes in state variables(), to incentivise actions which seek to progress the succeeding state towards its stated goals.
(9) |
Incentive 3 (Responsiveness)
To achieve the aforementioned condition, it is designed such that it necessitates that any change in incentives progresses the protocol towards its goals, i.e.:
(10) |
4 Protocol
The preceding sections highlighted that PoEL seeks to aid in sustainably attracting capital to the liquidity pools of a CDA, while efficiently asserting the underlying network’s economic security. This can be understood as optimising the multiplier of a CDA’s operating capital available as staked capital for the underlying network. As such, PoEL is tantamount to a money market protocol in which the lender is the blockchain network, and the borrower is loaned native staking tokens in exchange for multi-asset collateral, without the associated credit risk. This is achieved through the architecture visualised in the schematics presented in Fig. 2.
We now proceed to discuss the operational mechanics of this architecture: when an LP submits asset to the i-th CDA’s liquidity pool, they receive LP tokens denoted by , representing an LP’s share in an asset-specific pool, which can be used to further borrow native staking tokens from the network by depositing assets (LP tokens) into the LP token reserve 999If a CDA’s design does not assume distribution of LP tokens to its capital contributors, other approaches can be adopted to record the capital contributors willingness to use its liquidity as collateral to participate in the incentive program.
Definition 4 (LP Token Reserve)
An LP’s token reserve of size - , in a particular epoch, is a unique collateral pool, which is mapped to a particular validator’s address (say, v-th validator), and represents the type of asset (LP token) which can be deposited in the specified reserve.
We denote the sum of the size of all LP token reserves including asset mapped to all validators by , , where represents the number of validators involved in the PoEL protocol. Once LP submits collateral (LP tokens) to a reserve pool, and receives a loan of the native staking token (where the amount depends on collateralisation rate ()), it is delegated to a particular validator (). Notably, the amount of the loan extended to the LP is continuously tested against dynamically changing collateralisation requirements, which have to be met at all times, by all borrowers, i.e. for the total amount of native staking tokens () loaned to all borrowers.
Definition 5 (Collateralisation Rate ())
The collateralisation rate quantifies the amount of collateral an LP needs to deposit, to be able to borrow desired native staking tokens. It is represented by (), for LP token , and calculated as follows:
(11) |
where is the price of LP asset denominated in the native staking token at the epoch , and represents the loaned amount of the native staking token, using collateral in asset .
For securing the network with their borrowed native staking tokens, LPs can earn epoch-specific staking rewards from the network. Once accrued, staking rewards are deposited in the reward pool, which represents the total budget available for the liquidity bootstrapping program, and denotes the size of the epoch-specific reward pool.101010Reward pool is a distinct pool holding accrued rewards generated in PoEL protocol for securing the network, and optimally distributing it to LPs, based on pre-defined rules.
The rules-based mechanism driving the reward distribution seeks to optimise allocation by granting preferential rewards to relatively more desirable assets, thus maintaining capital efficiency in the protocol. This reward distribution policy is further informed by the collateralisation rate, which seeks to help incorporate risk management dynamics, into the reward distribution policy.
- •
Budget Distribution: PoEL protocol’s budget distribution mechanism seeks to allocate the available budget across multiple epochs (), where represents the optimal epoch-specific reward for LPs of i-th CDA and is the maximum budget available for distribution in that epoch, with the intent of striking a balance between capital efficiency and boosting incentive allocation in epochs with elevated user demand.
- •
Dynamic Interest Rate: PoEL quantifies a fee on borrowers of the native staking token, which depends on the quality of the asset used for collateral, and serves the purpose of efficiently distributing reward budget, higher quality assets which have a higher demand as operating capital in a CDA are given preferential rates. This rate, represented by , is specific to an LP token and epoch, and computed as a percentage of the distributable rewards for contributors of that LP token as collateral(), that is calculated as follows:
(12) Similarly, the nominal interest payable () is calculated as follows:
(13) - •
Collateralisation Rate: Instead of using a static amount of collateral required to borrow each unit of the native staking token, the protocol sets this rate dynamically, as another tool to assert its pre-specified principles111111Principle 2 requires that . and objectives. Furthermore, the PoEL protocol aims to accommodate any fluctuations in the combined value of assets used as collateral, by modifying the loaned amount as follows:
(14) Note that in the event of an adverse price change which leads to curtailment of the loaned amount (), ownership of the loaned asset is transferred to the PoEL protocol. It can then be reassigned to another LP capable of providing collateral, or it may trigger the unstaking process to commence the withdrawal of tokens from the PoS scheme and return them to the network 121212Note that if is a positive value this does not necessarily assume that the system will extend new loans in that epoch, based on the staking dynamics of the implementing blockchain the extension of new loans in PoEL protocol might be subject to frequency constraints.. Here, represents the collateralisation rate of a specific asset.
Essentially, this reward distribution mechanism aims to harmonise individual risk management policies with their respective objectives. It is important to note that the protocol mitigates credit risk by controlling not only the collateral but also the loaned tokens allocated because the borrowed tokens are never accessible to the borrowers.
Finally, rewards are optimally allocated to the different LP token reserves and can be withdrawn by the LPs with the LP tokens.
4.1 Operational Integrity
Operationally, LPs deposit LP tokens in LP token reserves, which are subsequently delegated to validators in the form of a loan, thereby promoting PoEL’s objective to use liquidity submitted in liquidity pools to secure the network. However, this has to be achieved in a manner where the interests of the protocol are aligned with those of its agents.
This alignment is achieved as follows:
- •
Validator Due Diligence: The protocol incentivises LPs to conduct their due diligence before selecting the validator as a prospective candidate for the delegation of their assets. One method of achieving this is by slashing the collateral of LPs who delegate to misbehaving validators. If penalised, on a ceteris paribus basis, the change of the total lent amount of the native staking token delegated to a particular validator () can be calculated as follows:
(15) where is the slashing rate regulated by the adopting network’s PoS mechanism, or set independently as a parameter in PoEL; and represents the loaned amount of native staking tokens delegated to v-th validator in the previous epoch. On a ceteris paribus basis, once slashed, an LP token reserve balance () would change as follows:
(16) where is the highest index of LP tokens submitted to the LP token reserve that are mapped to validator ’s address (the subject of slashing); and is the price of the LP token in e-th epoch.
Slashing thus serves as a deterrent against LPs who might strategically delegate to malicious validators, possibly intending to compromise network quality, or among other effects, cause a depreciation in the price of the network’s native staking token.
- •
Liveness: The network might stall if a sufficient number of validators breach the core principle of minimum staking requirement, leading to their ejection, which if happening concurrently (or cascadingly) could pose a risk to the network’s liveness (Risk 3). This issue must be systematically addressed while considering the unique design and economic characteristics of each adopting blockchain network. We seek to accomplish this by quantifying a ceiling of the amount of loaned native staking tokens that are available to be delegated to validators, whilst considering:
- –
Minimum viable number of nodes required for the adopting blockchain network to remain operational.
- –
Minimum staking requirement enforced in the adopting blockchain network.
Additionally, a range of other network-specific factors must be considered. These are generally incorporated into a function used to quantify the loanable ceiling () for each validator, ensuring that .
- –
- •
Diversification: PoEL incentivises diversification of assets comprising the collateral base, to manage the resulting impact of volatility stemming from assets locked in the network. In essence, if the asset base had n-many different assets131313Under the presumption that the underlying multivariate distribution characterising the basket of assets maintains the relevance and applicability of the covariance matrix., then the following can be written for the portfolio-level variance.
(17) where and are individual asset volatility, is the correlation coefficient between two assets, is the portfolio variance, and are asset-specific weights.
- •
Tenure: PoEL incentivises LPs to lock their assets in a CDA for a longer period, to effectively help smooth out the value of the locked assets, thereby, promoting the long-term participation of LPs and stabilising the system.
In the forthcoming sections, we elaborate on some of the some of the levers used to assert the network’s operational integrity.
4.1.1 Dynamic Collaterisation Rate
The protocol quantifies collateral, which is the amount of an asset that must be staked by LPs to gain access to borrowed native staking tokens to perform work themselves, or delegate it to another validator. To ensure that despite evolving dynamics, the protocol’s state is either at, or always progressing towards meeting its risk-conscious economic objectives, the collateralisation rate is quantified dynamically for individual assets. This rate is dynamically adjusted in keeping with the following objectives, which are continuously tested individually, with resulting changes that are required applied cumulatively.
- •
Qualification: A decentralised governance mechanism may be used to enforce a list of criteria, e.g. minimum liquidity, maximum volatility, decentralisation, etc., that must be satisfied before an asset is admissible to the universe acceptable as collateral.
- •
Risk hom*ogenisation: We standardise the varying quality of assets provided by LPs as collateral, enabling the protocol to hom*ogenise the risk-adjusted desirability of an asset, leading to the following condition to be held:
(18) where represents an abstraction of all measures of asset-specific risk; and is the representative risk of all assets in the basket, say the median or mean.
- •
Diversification: The quality of collateral is crucial, yet the pursuit of specific assets must be weighed against diversification to mitigate both known and unknown risks. We calculate the collateralisation rate for an asset () as follows:
(19) where is the minimum collateralisation rate, and can be calculated as:
(20) Here, is the asset specific risk scaling factor in the e-th epoch, which seeks to control the tradeoff between the deviation of an asset’s weight in the asset-basket (risk) from the target rate141414For simplicity, the risk scaling factor would be initially set to be the same for all assets, i.e. .; adjusts sensitivity to weight deviations from targets by determining the steepness of the exponential curve, allows for control over how expediently the collateralisation rate responds to changes in asset weights; adjusts the steepness of the curve dependent on whether there is positive or negative deviation, intended to compel expedient action of asset providers; represents target weights of asset 151515 would mean that an asset cannot be admitted as collateral.; and represents the weight of the asset in the basket in e-th epoch. This approach means that an excess or deficit of a specific asset influences the collateralisation rate. Specifically note that for all practical purposes , assuming that security considerations mean that system parameters cannot be changed as frequently.
Explicitly, it should be observed that the exponential function within the expression encapsulates a non-linear reaction to deviations in weight, which is suitably contingent upon both the magnitude and direction of the divergence of weights from the predefined target.
Now, the target asset-specific mix is set off-chain using the following optimisation problem:
subject to,
where represents the target weights of different assets in the portfolio; and is variance of an individual asset with weight and expected shortfall limits of the overall asset mix of the portfolio161616This model posits that by imposing a constraint on the expected shortfall of the asset portfolio, the PoEL protocol can effectively minimise financial risks associated with systemic vulnerabilities, such as sudden and significant asset price declines., respectively; represents the pre-defined ceiling on the volatility of collateral portfolio; is the cumulative distribution of returns () of assets comprising the portfolio; is the confidence level; represents the value at risk; and is the target weight allocated to the native staking token in the asset basket, based on the capital staked by capital providers directly in the native staking token, excluding the native staking token that has been borrowed by LPs.
This problem is comprised of quadratic objectives (portfolio variance) and linear and non-linear constraints (weight and risk constraints). Whilst a standard Quadratic Programming solver could have efficiently tackled a convex optimisation problem comprised of a quadratic objective function and linear constraints, the presence of non-linear constraint in the expected shortfall and inherent uncertainty in variables involved in the optimisation statement, a Stochastic Programming solver would be pertinent, as naturally if there wasn’t any inherent uncertainty, a Conic Optimisation solver could have also sufficed. We only briefly state these alternatives, as the precise methodology to be adopted for solving this off-chain is beyond the scope of this work.
- •
Unstaking Time: The unstaking time, as defined previously, is implemented as a security measure in PoS blockchain networks, but can expose the PoEL protocol to Risk 2, i.e. if the length of an epoch is shorter than the unstaking time, an adverse shift in asset price may lead to a scenario where , which is even applicable if the ownership of the loaned NSTs transfers from the user to the protocol. Since this risk cannot be directly mitigated, we seek to manage the impact if this risk were to emerge, through an upper bound on the variance of the portfolio of assets that are accepted as collateral in the system.
- •
Operational Robustness: To avoid scenarios where an agent attempts to borrow a significant enough portion of the native staking token to attempt a stake centralisation attack, we seek to enforce a maximum threshold loaned ownership of native staking tokens by LPs. This is achieved by asserting that the weight of native staking tokens directly staked in the PoS (not borrowed from the network) is not below a particular threshold on the loaned asset, i.e.
This ensures that the PoEL protocol maximally mitigates Risk 5, and this threshold weight could be used to quantify the amount of native staking tokens which can be borrowed in any epoch(), as follows:
In essence, the dynamic collateralisation rate requiring a higher (or lower) collateral amount on a relative basis to another asset, imposes an opportunity cost on the LP seeking to borrow native staking tokens, thereby, enabling the PoEL protocol to meet its stated risk diversification objective.
To ensure that the system fulfils the operational robustness objective described above, the collaterisation rate needs to dynamically change to accommodate the threshold . As such, we now consider the dynamics of the system when the collateral is comprised of three assets, say, , and , such that the amount of borrowed tokens can be calculated as follows:
(21) |
If the user continues to add more assets to the LP token reserves, or if the price of an asset increases, the amount of the loaned native staking token could exceed the maximum threshold . For such cases, we introduce the variable , which is applied as a multiplier to the collateralisation rate, aiming to increase the collateralisation rate of all assets to a point that would ensure the total borrowed amount does not exceed the predefined threshold .
(22) |
We can now rearrange the preceding equation to calculate , as follows:
(23) |
4.1.2 Locking Time
The PoEL protocol allows LPs to choose the duration for which they wish to lock their assets in LP token reserves, a period henceforth referred to as the locking time. Concurrently, it provides incentives to encourage sticky capital, thereby promoting the network’s economic security and stability. This is accomplished through the specified incentive for Target 1, where the final reward received by an LP/borrower in epoch is determined by a function, which we reiterate below:
(24) |
where represents the number of epochs for which l-th LP’s capital is locked, represents the associated incentive, represents the maximum incentive available to distribute to a particular LP at a particular epoch, is the minimum incentive (a portion of ), is a scaling factor that adjusts the steepness of the sigmoid curve, is a mid-point value around which the transition from the minimum to maximum incentive starts to become significant, and is a new parameter that adjusts the curve’s shape, providing additional control over how rapidly the incentive increases as the locking time approaches and surpasses mid-point.
The maximum reward itself () is computed as follows:
(25) |
Having discussed operational aspects, we now discuss how staking rewards and interest rates are used to achieve the protocol’s objectives.
4.2 Financial Management
To assert the adopting network’s objectives, encourage a risk-aware choice for LPs, and optimally use the budgeted incentives allocated to attract liquidity, the protocol complements income generated from CDA-specific fees with the allocation of preferential rewards (generated from securing the network) and variable lending fees. This approach results in a combination of risks and rewards (preferential incentives) which aid the PoEL protocol in achieving its stated objectives.
4.2.1 Dynamic Reward Allocation
Rewards are accumulated for LPs who delegate their capital to validators, thus enabling them to meet staking requirements and assert the economic security of the network. These rewards are kept in a combined reward pool, as shown in Fig.2. The pool’s resources, reflecting its health, finance the preferential incentive budget. This budget is carefully distributed to support the protocol’s objectives, notably Target 3, which focuses on enhancing capital efficiency and fostering user adoption. The allocation of this budget for preferential incentives in each epoch is determined by the following optimisation problem, which we aim to solve using smart contracts by tracing user on-chain behaviour:
(26) | ||||
s.t. | ||||
where is the capital efficiency of i-th CDA 171717The described mechanism assumes that only a single CDA is involved in the PoEL program in any epoch, and the system does aim to optimise the reward distribution between different CDAs., which is defined below; is the size of the reward pool 181818The size of the reward pool could be calculated based on total earned staking rewards from PoS for the borrowed native staking token and distributed rewards to LPs ; is the minimum staking reward that needs to be distributed in the epoch as part of the liquidity bootstrapping program and is based on a system parameter; is the maximum number of epochs for which the liquidity mining program is operational191919The period for which the incentive programme is operational may be longer than the period during which staking rewards are distributed to the reward pool, i.e., , where is the number of epochs during which there is a distribution of the staking rewards to the reward pool. In other words, this is intended to reiterate that the duration of the incentive programme is distinct from the duration for which borrowed NSTs could be staked in the network, i.e., the system will continue distributing rewards from the pool to LPs as long as , even after the end of the staking reward distribution period; is a vector of total reward budget distributed to LPs in a particular CDA across epochs; and is the total staking reward earned and distributed to reward pool for borrowed native staking tokens.
Now, to enable us to track the efficiency of any rewards distributed to attract liquidity, we introduce a new measure - Capital Efficiency Rate.
Definition 6 (Capital Efficiency Rate)
The capital efficiency rate for a specific CDA measures the proportion of capital submitted by LPs as operating capital to liquidity pools of a CDA, which has been utilised by the user, and quantified as follows:
(27) |
where is the (nominal) capital available in the participating202020For simplicity, we assume that all liquidity pools of a CDA are participating in the PoEL incentivisation program. liquidity pools of i-th CDA in e-th epoch; and represents the (nominal) LP capital in e-th epoch, which has been deposited in the pools.
An alternative definition of the preceding measure can be calculated to measure the productivity of distributed rewards for the fees that those rewards generate, i.e. , where the is the fees earned in nominal terms during the epoch by the CDA(as a result of its usage), and is the rewards distributed with the epoch to LPs of CDA.
Now this measure can be generalised to different DeFi applications, which enables us to measure if a CDA has the potential to be sustainable beyond the period when additional incentives are provided to attract liquidity, which is largely aimed at breaking the interdependent causal loop referenced in the introductory sections. This potential can be measured by its ability to generate a high enough capital efficiency, which will help maximise the financial value of the transactional volume.
Now, since there is a finite amount of budget available (staking rewards accumulated in the reward pool) to distribute as incentives, we front-load incentives to help kick-start the system in its nascent stages, and when it is experiencing high capital efficiency rates - to meet user demand. Therefore, the reward () is quantified as follows:
(28) |
where represents the number of epochs over which the moving average of the capital efficiency () is calculated; is the size of epoch-specific reward pool; is the target capital efficiency rate in a window ; is the staking reward rate of the adopting blockchain in -th epoch; and are parameters governing the relationship between the deviation from target capital efficiency rate and the reward distributed; is a parameter which defines the smallest portion of staking rewards that need to be distributed to bootstrap the liquidity of CDA.
We propose an algorithm (Appendix A) to optimise the protocol’s target (moving average) capital efficiency rate (), to enhance a CDA’s average capital efficiency. The algorithm tracks changes in the moving average capital efficiency rate over two distinct time windows, and , where , , and . The algorithm initiates by setting an initial target capital efficiency rate () and defining lengths for the short () and long () time windows. Global parameters, namely regulate the speed of negative adjustments, and regulates the speed of positive adjustments. It calculates the first () and second () derivatives of the moving average of capital efficiency rate over last epoch. The decision logic involves increasing or decreasing the target rate () based on the direction and acceleration of these derivatives. If both windows’ first derivative indicate an efficiency increase, the target rate decreases; conversely, it increases if there’s a decrease in efficiency. The extent of adjustment is determined by the alignment of the second derivatives in both windows, with full adjustments made when both windows corroborate the acceleration or deceleration of the trend, and reduced adjustments otherwise. The algorithm outputs the adjusted target capital efficiency rate, effectively balancing short-term responsiveness with long-term trend analysis.
The dynamic formulation presented in Algorithm 1 enables the protocol to use a direct measure of the rate of change, as opposed to its lagged and vulnerable (e.g. to whipsawing markets) proxies like the crossover of moving averages. The use of both long and short windows, first and second derivatives, enables the protocol to be more sensitive to short-term trends, but to accomplish it more effectively in the context of historical data. However, note that because we operate in a discrete-time world, where the capital efficiency rate is measured in equally spaced intervals of one epoch we would be required to approximate the first and second derivatives, as follows, for example:
4.2.2 Variable Lending Fee
Complementing the dynamic reward allocation scheme presented in the preceding section, the PoEL protocol uses interest rates to enable it to meet its stated objectives. This interest () is calculated as a portion of total rewards distributable to LPs, which is dynamically calculated to optimise the distribution of rewards between different LPs who submitted different LP tokens and thereby to maximise aggregate capital efficiency. This rate is modulated through a smart contract or a combination of on-chain/off-chain trustless computation logic, aiming to solve a single-objective optimisation problem. It is constrained by a reward budget for the -th epoch, seeking to maximise the total capital efficiency of the -th CDA in the -th epoch. This efficiency has a monotonic relationship with the fees earned by a CDA.
(29) | ||||
s.t. | ||||
where is the highest index of LP tokens from different pools of i-th CDA that are submitted to the PoEL protocol; and is a vector of interest rates charged from rewards distributable for staked NST that has been borrowed using different LP tokens as collateral; represents the staking rewards distributable to LP token reserves for a staked native staking token that has been borrowed using -th asset as collateral. Logically, solving the above optimisation problem necessitates the system to incentivise pools experiencing increased demand, while reducing incentives for less popular pools. Therefore, we now quantify the capital efficiency rate () for an asset pool within a CDA:
(30) |
where is the (capital) liquidity available in asset pool of the CDA at the epoch ; and is the liquidity of the asset in CDA that has been submitted by LPs 212121Similar to the alternative definition of the capital efficiency rate provided for CDAs, an alternative definition of the same measure for a particular asset pool is: , where is the fees earned from utilisation of working capital of asset pool of i-th CDA during the epoch .. It can be observed that the aforementioned formulation essentially provides a point-in-time snapshot of the capital efficiency rate, which may leave room for malicious users to manipulate key measures, therefore, instead of using a point-in-time measure, we seek to calculate the capital efficiency rate over a period of time (look-back window of length - epochs), and denote it with .
To quantify the optimal interest rate for various assets, we identify the asset pool within a CDA which exhibits the highest and lowest (moving average) capital efficiency, designated as and , respectively. On a ceteris paribus basis, allocated rewards are positively correlated to the capital efficiency in the system, which leads to a scenario where the asset pool with the lowest capital efficiency () attracts the lowest reward, and the asset with the highest capital efficiency () attracts the highest reward. We use these dynamics to scale allocated rewards, using the weight , with increasing capital efficiency, as follows:
(31) |
where and are minimum and maximum weights attached to assets; is a system parameter governing the convexity of relationship between weights and the capital efficiency rate; and is the factor which governs the desirability of a higher capital efficiency asset in the portfolio, such that .
Now, the rewards distributable () to an LP’s token reserves for an asset () in an epoch is calculated as follows:
(32) |
where represents the distributable rewards across all assets.
Now, we can also calculate the applicable interest rate charged for each asset (), as follows:
(33) |
5 Conclusion
In this work, we have presented the concept of Proof of Efficient Liquidity (PoEL) protocol, which is designed for PoS blockchain infrastructures with intrinsic DeFi applications, seeking to support sustainable liquidity bootstrapping and network security. We have reviewed existing literature (Sec. 2), in the context of which the protocol’s governing principles (Sec. 3), and the proposed protocol architecture (Sec. 4) can be understood.
In forthcoming revisions, we will formally prove that the proposed protocol architecture meets its stated objectives, provide case studies through agent base simulation, and pave the path for expanding the protocol to an algorithmic model for interest rate calculations using LPs on-chain reputation scores and loss modelling, enabling us to price and manage varied risks stemming from liquidity bootstrapping. Finally, we will also explore decentralised automation services to optimise capital allocation and harmonise incentive schemes, in the context of competing incentive programs running on the same blockchain network, albeit for different CDAs.
Appendices
Appendix A Algorithm 1: Target Capital Efficiency Rate
Appendix B Service Fee Credits
In the work thus far, we presented how the PoEL protocol described in this work enables blockchains with intrinsic CDAs to attract, and efficiently and sustainably retain capital using budgeted financial incentives. We now explore how the underlying incentive structures used therein can be extended to incentivise the use of auxiliary services (Assuming that the network provides additional services beyond those related to CDA) embedded in the adopting blockchain network (e.g. smart contract transactions) linked to the new capital, with an additional focus on catalysing sustainable, and efficient usage of the network (incl. its resources).
This is achieved by endeavouring to expand the user base, which not only enhances the network’s decentralisation but also sustainable economic rationality222222A higher number of users and transactions helps reduce the fixed cost per transaction, which accounts for gas fees and infrastructural expenses, and thus additionally bolsters the efficiency of the network’s financial and infrastructural resources. This can be distributed over an increased number of transactions if the resources are productively utilised.. Therefore, with more users and transactional volume, there is a better utilisation of liquidity submitted to the CDAs. Furthermore, it is clear that for the sustainable viability of a blockchain network, it must have a foundational number of users and transactions. However, this presents a circular dilemma: users and transactions gravitate towards networks already perceived as viable, meaning a network requires users to generate value, yet it needs to offer value to attract users.
To solve this quandary, we introduce service fee credits which serve the dual purpose of dynamically attracting capital, and incentivising initial network usage, which we hope is extenuated with network effects - a phenomenon when a product or service subject to network effects becomes more valuable as more people use it, e.g. in a social network [3, 20]. These credits complement, not replace, staking rewards, which are earned by LPs who use their assets to contribute to the adopting blockchain network’s economic security.
Definition 7 (Service Fee Credits)
Service fee credits are non-transferable, timed, and limited credits, which are denominated in the native staking token and linked to a user’s wallet address, such that they can be used to offset future costs arising from the user’s use of the network or be delegated to another user. These credits are granted to users when they submit capital to a CDA’s liquidity pool(s) and PoS scheme. These service credits, represented by , where is the number of epochs for which credits are available for use in a period we call, rounds (), and represents replenishment caps, which represents the round-specific predetermined ceiling to which further credits can be added and used by the user address .
For ease of reader’s convenience, in Fig. 3, we present schematics that exhibit how these credits fit in the context of the wider network, and how its distribution policy is closely linked with the incentive budget allocation process used in the PoEL protocol to attract capital.
Now, in the definition of service fee credits, we introduced the notion of round-specific () replenishment caps (), which change with time and are linked to the nature of assets that comprise the capital submitted to the network. This is calculated as follows:
(34) |
where is the rate which dynamically determines the portion of the total submitted capital (in asset ) that can be used to replenish the capital provider’s credit account at the beginning of a particular round; is the size of the LP-token reserve at the beginning of a round; and is the price of LP-token at the beginning of a round.
As also stated in their definition, service fee credits are limited, meaning they are subject to a dynamic (periodic) limit (), which can be computed for a specific user as follows:
(35) |
where is the number of LP token reserves in the system, and is the share of the user in the -th asset’s LP token reserve. Naturally, given some uncertainty in the user behaviour, we could use a stochastic differential equation to model the inherent uncertainty, e.g.: , where is a Wiener process term representing random fluctuations, and and represent the drift and volatility terms, respectively. Furthermore, the system could incorporate a time-based locking incentive mechanism for users regarding replenishment cap allocation, akin to the framework suggested in Incentive 1, which will further encourage extended locking periods.
Finally, we calculate the point-in-time () balance () of the service fee credits for a particular account () in a given round, as follows:
(36) |
where is the number of network services for which service fee credits can be used; and is the amount of service fee credits that have been utilised by -th user address to pay for the service in the round .
Having defined the baseline concepts, we now consider the impact of bounding time when the service fee credits can be used. Therefore, on a ceteris paribus basis, the change (replenishment) in credit () at the beginning of a round can be calculated as follows:
(37) |
where is the last timestep of the round .
Altogether, from a user’s perspective, their risked capital is eligible for three streams of revenues - (i) PoS rewards, (ii) fees generated from CDAs, and (iii) service fee credits. However, since service fee credits are time-bound, it can be said that at the end of each round when their credits expire, unutilised credits are a source of cost, and therefore, a user’s optimal return maximisation strategy ought to include full utilisation of awarded credits, which would aid the network in bootstrapping userbase and network activity.
Service Fee Credit BudgetingThe PoEL protocol presented a budgeted reward distribution policy, which was used to tactfully incentivise staked capital, which can be modified to budget any credits awarded.
For rounds , the total budget () available to finance such credits is:
(38) |
where is the highest index of LP tokens; and is the addition to the credit budget in -th epoch, which can be determined using the state of the treasury and governance mechanisms.
If the service fee credit program lasts for a defined number of rounds, and the budget is not static with time, then it can be stated (ex-post) that if the protocol is successful in attracting liquidity in earlier stages of its life, then , meaning that in a mature state , implying that in earlier stages of the protocol, the protocol would seek to invest more in the incentive program and as the network matures, curtail any benefits. In other words, the additional amount () needed to finance the incentive program would decrease at an increasing pace over time. This amount () can be ascertained by inter-temporarily harmonising the network’s fiscal objectives (a component of a blockchain network’s fiscal policy), using a constrained optimisation problem which seeks to maximise the incentives distributed, under the constraint of network’s survivability (defined in terms of the number of users associated with their auxiliary services and CDAs). In essence, this optimisation problem would enable us to ascertain the total (lifetime) distributable budget, and point-in-time budget, using the network’s current state (e.g. including the number of users, the transactional volume, the number of services, etc.), and its precise functional form using the aforementioned state variables. Furthermore, using the framework presented in Sec. 4.2.1, we can ascertain the precise amount of credits available for distribution in each round, based on the distance of state variables to its aspired optimal value. Once a round-specific budget () is ascertained, the credit incentive mechanism can use the baseline PoEL protocol’s variable lending fee modelling to ascertain the correct amount of incentives (by way of estimating the asset-specific replenishment cap) that can be provided for each unit of liquidity brought to the network.
Appendix C List of Notations
Notation | Description |
---|---|
A timestep, representing a specific point in time when a change in state variables is observed or input parameters are set. | |
An epoch, representing a short yet relatively fixed period akin to block time representing instances when the protocol executes critical updates. | |
Represents the number of epochs for which l-th LP’s capital is locked. | |
The maximum number of epochs for which the liquidity mining program is operational. | |
The mid-point value around which the transition from the minimum to maximum incentive starts to become significant. | |
Distinct time windows for tracking changes in the moving average capital efficiency rate. | |
Traded volume. | |
A vector of state variables specific to the protocol. | |
The price of an asset at time t = i. | |
Asset-specific bid-ask spread. | |
Trading volume of an asset over a prespecified look-back window . | |
A vector of total reward budget distributed to LPs in a particular CDA across epochs. | |
The (nominal) capital available in participating liquidity pools of the i-th CDA in the e-th epoch. | |
Incentives distributed for asset pool in -th epoch. | |
Maximum incentives available to distribute to a particular LP. | |
Minimum incentives available to distribute to a particular LP. | |
The optimal epoch-specific reward for LPs of i-th CDA. | |
Represents the associated incentive. | |
Represents the maximum incentive available to distribute to a particular LP at a particular epoch. | |
Represents the minimum incentive (a portion of ) available to distribute to a particular LP at a particular epoch. | |
The minimum staking reward that needs to be distributed in the epoch as part of the liquidity bootstrapping program and is based on a system parameter. | |
Staking rewards earned. | |
The staking reward rate for the adopting blockchain in the e-th epoch. | |
Vector of interest rates charged from rewards distributable for staked NST. | |
Rewards distributable to an LP’s token reserves for an asset in an epoch. | |
LP Token reserve, representing the size of an LP’s token reserve in a particular epoch, representing a unique collateral pool mapped to the -th validator’s address. | |
The price of LP asset denominated in the native staking token at the epoch . | |
The loaned amount of the native staking token, using collateral in asset . | |
The total amount of native staking tokens loaned to borrowers. | |
Size of buy (or sell) order. | |
Nominal interest payable. | |
The amount of native staking tokens which can be borrowed in any epoch. | |
Collateralisation rate, quantifying the amount of collateral an LP needs to deposit to be able to borrow desired native staking tokens. | |
A system parameter denoting the minimum collateralisation rate for all pools. | |
Weights associated with each conceptual objective. | |
The weight of the asset in the basket in e-th epoch. | |
target weights of asset . | |
Minimum and maximum permissible weights of an asset. | |
Weight associated with the capital efficiency of asset in the portfolio. | |
Realised standard deviation of a particular asset. | |
Probabilistic threshold for the likelihood of the occurrence of prespecified operational risk events. | |
Market impact function of j-th asset. | |
market impact of executing a fixed notional value in the native staking token with a specific market impact function. | |
The risk scaling factor for asset . | |
Steepness of collateral diversification curve. | |
The smallest portion of staking rewards that need to be distributed to bootstrap the liquidity of CDA. | |
Target (moving average) capital efficiency rate to enhance a CDA’s average capital efficiency. | |
Initial target capital efficiency rate. | |
First and second derivatives of the moving average of capital efficiency rate over the last epoch, respectively. | |
Global parameter regulating the speed of negative adjustments. | |
Global parameter regulating the speed of positive adjustments. | |
Realised return of a particular asset. | |
Scaling factor adjusting the steepness of the sigmoid function controlling the incentive awarded based on tenure, in comparison to the target tenure. | |
Parameter adjusting the steepness of available incentive’s relationship with the tenure of deposit (i.e. locking time). | |
The scaling factor adjusting steepness of the sigmoid curve governing the reward in relation to the locking time. | |
A new parameter that adjusts the curve’s shape, providing additional control over how rapidly the incentive increases as the locking time approaches and surpasses mid-point. | |
The capital efficiency of i-th CDA. | |
The size of reward pool. | |
Liquidity available in asset pool of the CDA at the epoch . | |
Capital efficiency rate over a period of time (look-back window of length - epochs). | |
The sensitivity to weight deviations in the collateral basket from its target. | |
System parameter governing the convexity of the relationship between weights and the capital efficiency rate. | |
Factor governing the desirability of a higher capital efficiency asset in the portfolio. | |
Interest rate charged for each asset . | |
Reward budget for the -th epoch. | |
Highest index of LP tokens from different pools of the -th CDA. | |
Staking rewards distributable to LP token reserves for a staked NST borrowed using the -th asset. | |
Capital efficiency rate for an asset pool within a CDA. |
References
- [1]AAVE.AAVE.https://aave.com/.[Online; accessed 20-September-2023].
- [2]Carlo Acerbi and Dirk Tasche.On the coherence of expected shortfall.Journal of banking & finance, 26(7):1487–1503, 2002.
- [3]Allan Afuah.Are network effects really all about size? the role of structure andconduct.Strategic Management Journal, 34(3):257–273, 2013.
- [4]Alchemix.Alchemix.https://alchemix.fi/.[Online; accessed 20-September-2023].
- [5]Balancer.Balancer.https://balancer.fi/.[Online; accessed 20-September-2023].
- [6]Balancer.Balancer Liquidity Mining.https://balancer.gitbook.io/balancer/core-concepts/bal-liquidity-mining.[Online; accessed 14-September-2023].
- [7]Benqi.Benqi.https://benqi.fi.[Online; accessed 20-September-2023].
- [8]Benjamin Clapham, Peter Gomber, Jens Lausen, and Sven Panz.Liquidity provider incentives in fragmented securities markets.Journal of Empirical Finance, 60:16–38, 2021.
- [9]Coindesk.FCoin Crypto Exchange Draws Fire for Controversial Business Model.https://www.coindesk.com/markets/2018/06/22/fcoin-crypto-exchange-draws-fire-for-controversial-business-model/.[Online; accessed 25-September-2023].
- [10]Compound.Compound.https://compound.finance.[Online; accessed 20-September-2023].
- [11]Simon Cousaert, Jiahua Xu, and Toshiko Matsui.Sok: Yield aggregators in defi.In 2022 IEEE International Conference on Blockchain andCryptocurrency (ICBC), pages 1–14. IEEE, 2022.
- [12]Curve.Curve.https://curve.fi/.[Online; accessed 20-September-2023].
- [13]Curve.Curve Understanding Gauges.https://resources.curve.fi/reward-gauges/understanding-gauges/.[Online; accessed 15-September-2023].
- [14]JagjeevS Dosanjh.Market maker incentives and market efficiency: Evidence from theaustralian etf market.Technical report, Citeseer, 2013.
- [15]dYdX.dYdX.https://dydx.exchange/.[Online; accessed 21-September-2023].
- [16]Sizheng Fan, Tian Min, Xiao Wu, and Cai Wei.Towards understanding governance tokens in liquidity mining: a casestudy of decentralized exchanges.World Wide Web, 26(3):1181–1200, 2023.
- [17]Michael Feng, Rajiv Bhat, and CarloP LasMarias.Liquidity mining: A marketplace-based approach to market makercompensation.Hummingbot research paper, 2019.
- [18]IDEX.IDEX.https://idex.io/.[Online; accessed 21-September-2023].
- [19]InsurAce.InsurAce.https://www.insurace.io/.[Online; accessed 20-September-2023].
- [20]SumitK Majumdar and Sriram Venkataraman.Network effects and the adoption of new technology: evidence from theus telecommunications industry.Strategic Management Journal, 19(11):1045–1062, 1998.
- [21]AlbertJ Menkveld and Ting Wang.How do designated market makers create value for small-caps?Journal of Financial Markets, 16(3):571–603, 2013.
- [22]Nexus Mutual.Nexus Mutual.https://nexusmutual.io/.[Online; accessed 20-September-2023].
- [23]Osmosis.Osmosis.https://osmosis.zone/.[Online; accessed 21-September-2023].
- [24]Osmosis.Superfluid Staking.https://docs.osmosis.zone/osmosis-core/modules/superfluid/.[Online; accessed 2-September-2023].
- [25]ArthurAB Pessa, Matjaž Perc, and HaroldoV Ribeiro.Age and market capitalization drive large price variations ofcryptocurrencies.Scientific Reports, 13(1):3351, 2023.
- [26]Perpetual Protocol.Perpetual Protocol.https://perp.com/.[Online; accessed 21-September-2023].
- [27]Qasar.Qasar.https://www.quasar.fi/.[Online; accessed 21-September-2023].
- [28]Sushiswap.Sushiswap.https://www.sushi.com/.[Online; accessed 20-September-2023].
- [29]Synthetix.Synthetix.https://synthetix.io/.[Online; accessed 21-September-2023].
- [30]Uniswap.Uniswap.https://uniswap.org/.[Online; accessed 20-September-2023].
- [31]Jimmy Yin and Mac Ren.On liquidity mining for uniswap v3.arXiv preprint arXiv:2108.05800, 2021.