The main mechanism for incentivizing PoS network participants to act in accordance with network rules is staking, but since both staking and liquidity provision need to lock network tokens, the liquidity of the PoS network will be affected by transactions.
Original title: “Paradigm 丨 Explore the possibility of combining staking and liquidity supply”
Written by: Paradigm
Translation: Li Hanbo
Introduction
In view of its higher efficiency, lower environmental impact and higher degree of freedom in engineering reward systems, the acceptance of Proof of Stake (PoS) is becoming higher and higher, which was impossible before.
The main mechanism to motivate PoS network participants to act in accordance with network rules is pledge . It means locking a certain amount of the network Token as collateral in the agreement to obtain the qualification to verify transactions and earn deposit rewards. Although this provides a solution for the waste of computing resources in the PoW mining mechanism, since both pledge and liquidity provision need to lock the network token, the PoS network will be affected by transactions in terms of liquidity .
This kind of transaction is particularly obvious in PoS networks with a high proportion of pledged assets, because pledge and liquidity are “competing for resources”, and liquidity is often at a disadvantage, either because the design of the pledge mechanism does not take this into account, or The incentive mechanism is biased towards pledges.
This is a big problem for PoS networks, because on the one hand, a higher pledge ratio improves the security of the network, but at the same time it has a negative impact on the liquidity of the network Token . This may cause significant slippage for users trying to buy/sell network tokens, and at the same time token price fluctuations and poor price discovery.
It seems that in the PoS field, other pledge mechanism designs and incentive models are needed. Under the premise of not jeopardizing network security and liquidity supply, pledge capital is used to coordinate the interests of all participants and take into account the needs of the community.
In addition, this research report will focus on different ways of combining pledges with liquidity supply.
Delegation certificate
One of the ways to realize equity tokenization is through the delegation certificate proposed by Chorus One. This mechanism is summarized as shown in Figure 1.
Figure 1: Authorization certificate
In this method, user 1 deposits their funds in the fund pool of verifier 1, and receives the voucher token representing their equity, and then can freely trade (for example with user 2) and act as the fund pool of verifier 1 Claims on the winning assets.
This method has several advantages.
- The authorization certificate represents the pledge Token holder, not the exchange.
- There may be discounts due to the use of claims for pool shares instead of reward distribution.
- This may be the basis for a more advanced solution that can resolve some limitations.
At the same time, there are some limitations.
- Due to different rewards and risk characteristics, Tokens are aimed at validators, so Tokens are not interchangeable between different validator pools. This in turn leads to the overall liquidity being divided by different validator Tokens.
- Liquidity is created for Tokenlize’s equity, not for basic assets.
- There does not seem to be many economic incentives to adopt this solution.
Efforts are being made to implement liquidity pledges and similar solutions projects.
- StaFi
- LiquidStake
- RocketPool
- Staker DAO
- Ramp DeFi
- Acala DeFi
- Kira network
Proof of liquidity
In a typical PoS encrypted network, pledge means that the network Token is taken out of circulation, thereby reducing liquidity.
If liquidity can grow with the increase in pledge, it seems to be better. This is the purpose of the liquidity proof method introduced by Joel Monegro from Placeholder. The main idea is to use the liquidity pool Token (for example from Balancer, Uniswap) as a liquidity proof. Then, these LP Tokens can be pledged instead of network Tokens-increasing the pledge in this way will ensure higher liquidity.
Figure 2: Proof of liquidity
The liquidity pool acts as automatic market makers (AMMs) and maintains the ratio between the Tokens it contains. For example, if a pool contains 60% DAI and 40% ETH, the automatic algorithm will maintain this ratio by buying and selling DAI/ETH. For contributions to the liquidity pool, users will receive a corresponding amount of LP Token in the liquidity pool. For example, if you deposit 20% of the liquidity into the pool, you will get 20% of the LP Token, which can be exchanged for 20% of the entire pool. Share. Of course, since LP Token represents a claim on some assets in the pool, and the underlying assets are traded on a decentralized exchange (to maintain the set ratio between the assets in the pool), LP Token may also be used as a liquidity Proof of sex.
This method may solve the problem of consistency between pledge and liquidity provision, but the pledge smart contract may need to be adjusted to allow the pledge of LP Token. The pledge reward can be based on the balance of the corresponding share of the network Token in the liquidity pool.
In addition, the pledge liquidity regulations can also allow pledgers to obtain fees from transactions conducted against the liquidity pool and reduce equity value fluctuations caused by other assets in the pool (such as DAI, ETH, etc.).
What needs to be considered is that this approach is likely to require an audit of the liquidity pool and is eligible to provide liquidity certificates for pledge .
Simple pledge
xDAI is a layer2 blockchain solution on top of Ethereum, in which the native token (xDai) is equivalent to DAI.
The xDai team has designed a unique incentive structure that can encourage a higher deposit amount and a longer deposit time, and at the same time reward the liquidity provider for unclaimed rewards. First, the annual rate cap for the total emissions of the agreement is 15%.
The annual rate of return depends on 2 factors.
- Based on supply: Depends on the proportion of pledged tokens in total token supply.
- Time-based: The length of time a certain deposit is pledged. The longer the time, the higher the rate. The growth of the fee rate is non-linear, so after about 4 months of pledge, the marginal growth of the fee rate starts to flatten.
Each factor can get up to an annual interest rate of 7.5%, and the sum of the interest rates based on these two factors will determine the annual interest rate that the pledger receives. The difference between the annual interest rate dedicated to the pledger and the annual emission limit is distributed to the liquidity provider on average every 7 days (the specific date is random). Table 1 is an example of this return distribution.
In the following example calculations, we will assume that 25% of all network token supply is pledged. If a pledger deposits 1000 Tokens into a 28-day pledge contract, then his annual interest rate will be calculated as follows.
- Based on supply: 0.25 * 7.5% = 1.875%
- Time-based annual interest rate: 28 days will correspond to 4.53%.
For the pledger
- Yield365days = 1000Tokens * (4.53% + 1.875%)/100 = 64.05Tokens.
- 28-day output=64.05*28/365=4.91Token.
For liquidity providers
- Yield365days = 1000Tokens * (15%-(4.53% + 1.875%))/100 = 85.95Tokens
- Output 28 days=85.95*28/365=6.59Token
In this special case, the liquidity providers will share the resulting 6.59 Tokens based on their respective liquidity shares in the pool.
This method effectively penalizes short-term pledgers with lower annual interest rates, and at the same time transfers the difference (and the annual emission cap) to liquidity providers. For long-term pricers, it may be interesting to allocate part of their pricing capital to liquidity providers to diversify their pricing rewards.
By adopting similar solutions, encrypted networks are likely to see an increase in the liquidity available in the liquidity pool. At the same time, this reward-sharing model seems to be a recognition and reward for those liquidity providers who use their capital in the liquidity pool to bring value to the network.
Comprehensive solution
This section introduces a comprehensive solution and describes how to combine the different methods discussed earlier.
Combination of liquidity pledge and liquidity provision
This solution is inspired by the DeFiDollar architecture.
The main idea revolves around abstracting part of the process from users, and processing liquid betting through Ethereum smart contracts. The outline of the architecture can be seen in Figure 3.
Figure 3. Comprehensive plan: liquidity provided by liquid pledge
This comprehensive solution has several components:
1. The main contract : smart contract, docking with users, coordinating all Token flow/flow to the liquidity pool, pledge contract, and issuing pledge certificate Token, and distribute cumulative rewards to certificate holders.
2. Pledge contract : a smart contract that allows depositing LP Token for pledge. Then, the contract can entrust the basic network token in the provided LP equity to the selected verifier. All generated pledge rewards will be forwarded to the main contract for distribution.
For users, this process is not much different from the previously described liquidity pledge (delegated token) scheme, that is, the user deposits a certain amount of Token into the main contract, and receives a token representing the amount of pledge deposit, and then can compare it with other User exchange. These voucher tokens will represent the requirements for the amount of deposit provided, as well as the rewards generated through deposits and LP transaction fees.
The compound approach has several advantages and can create greater flexibility.
- Holders of the voucher token can receive rewards and LP transaction fees at the same time.
- The pledge contract may be implemented in a way that makes the generated certificate Token verifier agnostic, meaning that it can be interchanged regardless of the verifier.
Special considerations for this solution.
- Pledge of LP Token: It is not a trivial matter to choose a mechanism from the LP Token representation to calculate the number of pledged Tokens, because the number of Tokens in the underlying network may change due to exchange rate fluctuations, or it may change significantly over time Rise or fall.
- Delegate the Token amount to the verifier: A solution can be to evenly distribute the amount to all verifiers, or wrt verifiers are at risk. In this way, the user will not be exposed to the risk of any specific verifier, and the generated credential Token has nothing to do with the verifier.
- Redefining fraud: Staking LP Token means that in the event of fraud, LP Token will be destroyed instead of the basic network token locked in the liquidity pool. This requires changing the penalty mechanism and possibly redefining the penalty. One of the benefits is that in this case, the penalty does not necessarily have to affect the liquidity supply.
Preliminary Conclusions
It seems that there are several methods that combine pledge and liquidity provision, which may succeed in practice. In fact, the xDai model has been launched, and at the time of writing this research report, a relatively stable liquidity amount of approximately US$2.4 million has been generated on Uniswap.
Considering the uncomplicated solution and the consistency of liquidity pledge and liquidity provision, the realization method of liquidity proof also seems very promising.
Finally, there is a large area of possible composite solutions that combine individual solutions in different ways, similar to the combination of liquidity pledges and delegation vouchers discussed briefly in the previous section. Although there are some aspects that require more in-depth analysis, such as the interchangeability of the resulting equity representation, and the development of a robust accounting mechanism for pledges and rewards.
It is worth mentioning that implementing any solution has its own advantages and disadvantages, and less obvious positive and negative externalities may potentially affect network incentives, governance, and security. These effects must be carefully considered and modeled in conjunction with specific network conditions.
Further research can focus on the more practical aspects of these solutions and study the specific pledge and governance mechanisms used. This will enable us to provide a background suggestion on which method is the best solution for combining pledge and liquidity supply.
