In-depth analysis of ETH2.0 mortgage pool and token model
The cryptocurrency field is experiencing unprecedented growth and innovation. One only needs to see that this is true in the mortgage space-less than a month after ETH2 went online, users have been provided with many third-party mortgage platforms. They range from centralized exchanges like Binance to DeFi projects like RocketPool and StakeWise, and they are different in every aspect.
However, among all the differences, they have one thing in common: they all try to find a solution to the necessary friction that anyone encounters when staking ETH. What are these frictions?
One of them is that the technical complexity of collateralizing ETH exceeds the skills of ordinary users. In addition, given the rapid increase in the price of ETH in the past month (currently $1,025 at the time of writing), ordinary users are required to pay a deposit of 32 ETH, which is more and more beyond their capacity for ordinary users. Finally, mortgage funds have a period of insufficient liquidity of about 18-24 months, which is a security measure implemented for people to safely and controllably transition to ETH2.0.
Combining the above restrictions, it will allow less mature users to exit the lucrative ETH mortgage market.
How does the mortgage pool solve this problem?
This is the purpose of the ETH2.0 mortgage pool. They accumulate ETH from multiple users and run the ETH2 mortgage infrastructure on behalf of the user, so that anyone can receive mortgage rewards, regardless of their skill level or deposit size.
In addition, they are trying to alleviate lengthy liquidity requirements by generating ETH1 tokens that represent the deposits and rewards obtained by users on the ETH2 chain. By exchanging tokens for ETH in secondary markets such as Uniswap, these mortgage token holders are provided with the opportunity to withdraw from the mortgage and have the ability to use their Ether held in DeFi (for example, as mortgage).
However, the implementation of the token model between each pool is different, which will undoubtedly bring some serious impacts on the end users. For example, Lido's stETH token is not the same as StakeWise's stETH token, so it should be priced at different prices in the secondary market. At the same time, RocketPool's rETH token is implemented differently from Stakewise's stETH, as are CREAM's crETH2, Stkr's aETH, etc.
In short, there are many differences in the mechanism of tokens from different pools, which may cause confusion and bring undesirable consequences to end users. However, these differences can be categorized and evaluated in order to make an informed decision when deciding which mortgage pool to join. In addition, this comparative analysis lays the foundation for the valuation method of mortgage tokens, allowing different Eth2 to represent the price efficiency between tokens.
The main purpose of this article is to help educate the community to understand the different types of token economy used in popular mortgage pools today. We hope to avoid expensive mistakes caused by people's insufficient understanding of the product, and hope that the community will contribute to the discussion of effective pricing and arbitrage opportunities in the Eth2 pool industry.
Mortgage ETH token model
We can distinguish between two different structures: a single token design is designed to capture both the initial deposit and the mortgage income in a token. The dual token design divides the captured deposits and rewards into two different tokens.
Single token design
The single token structure is based on the concept of rebalancing/repricing tokens. This is the most popular design and is used by most pools due to its simplicity. By generating a single token to the user when depositing, the pool attempts to capture the accumulation of mortgage rewards and fines within the same token. It can be done in two ways:
- The mortgage rewards and penalties accumulated on ETH2 are reflected in the changes in the token balance (hence the term "rebalancing"), so in stage 1.5, each mortgage ETH token should be exchanged for ETH in the pool at a ratio of 1:1 .
- The accumulated mortgage rewards and penalties on ETH2 will be reflected in the token price (hence the term "repricing"), so that in stage 1.5, the amount of ETH that can be redeemed for a unit of token varies with the number of rewards and penalties in the pool fluctuation.
It’s best to use examples to illustrate the differences in these token mechanisms:
I. Balance change: Deposit 1 ETH into the pool and get 1 mortgage ETH token.
As the rewards or punishments in the pool increase, the token balance of each participant in the pool will change accordingly, that is, 1.1 ETH = 1.1 mortgage ETH token balance in the pool. Therefore, the mortgage income will be captured in the address that keeps increasing the token balance and generated by the pool. Starting from stage 1.5, all pledged ETH tokens can be exchanged for ETH at a ratio of 1:1.
The design is used by Lido Finance and Binance.
Please note that the balance of mortgaged ETH tokens is always equal to the number of ETH in the pool; the exchange rate remains at 1 during the entire mortgage period.
II. Price changes: Deposit 1 ETH into the pool, and receive mortgage ETH tokens at the ETH/ETH2 token exchange rate during the same period. The exchange rate given in the pool is determined by the ratio of the total supply of ETH and tokens in the pool, and varies according to the amount of rewards and penalties generated in the pool.
Assuming that the exchange rate at the time of deposit is 1, that is, the pool has not yet received any rewards, 1 ETH = 1 collateralized ETH token.
As the rewards and penalties in the pool increase, the balance of the user's pledged ETH tokens will remain unchanged, but now, the token claim for each unit of ETH in the pool changes. In other words, there is 1 mortgage ETH token in the pool = 1.1 ETH in the pool.
Therefore, the price of each mortgage ETH token changes from 1 ETH to 1.1 ETH, which reflects the user's mortgage income. In stage 1.5, users can redeem all pledged ETH tokens as ETH in the pool at the final ETH/ETH2 ratio.
Rocket Pool, CREAM, Stkr and StaFi use such tokens.
Pay attention to changes in exchange rates-it captures the increase in the mortgage rewards users receive.
Although different mechanisms are used to reflect the accumulation of revenue, the single-token design has one thing in common: deposits and rewards are bundled in the same token. This means that whenever a user buys and sells tokens in the market, or receives this token from a supplier when depositing, the user will receive/sell the deposit and the rewards accumulated in the pool in the past.
We will discuss the implications of this design choice in another article, but when evaluating the pool, users should consider design factors, as it will guide users’ APR expectations and predictions on the pricing of tokens in the secondary market.
Dual token design
Instead, the dual token structure is based on the concept of two rebalanced tokens that reflect deposits and rewards respectively.
The user's deposit in the pool (some people call it the principal for earning rewards) is reflected in the deposit ETH tokens.
Like other rebalancing tokens, it is generated at a ratio of 1:1 with the ETH deposited by users.
When deposited in the address, the deposit ETH tokens will not grow, but will accumulate rwETH (reward ETH) tokens, reflecting the growth of the collateral held by the user in the pool at a ratio of 1:1. The sum of these tokens constitutes the user's overall mortgage balance, and can be freely transferred between Ethereum addresses and used in smart contracts like single tokens.
This is an example to illustrate:
Deposit 1 ETH into the pool and get 1 ETH token (stETH).
As the rewards in the pool grow, the balance of the deposited ETH tokens will remain unchanged, but its presence in the address will trigger the accumulation of reward ETH (rwETH) tokens to reflect the growth of the rewards in the pool. As long as it holds deposit ETH tokens, it will accumulate reward ETH tokens.
After Phase 2, all tokens will be exchangeable for ETH in the pool at a ratio of 1:1, regardless of whether they represent deposits or rewards.
The only staking pool designed with dual tokens is StakeWise.
The dual token structure allows the creation of a new hybrid tool similar to the dynamics of bonds, but the difference is that it separates the mortgage balance into tools with different accrual systems and cash flow expectations (principal and interest), so as to achieve Manage mortgages more effectively and reasonably.
For example, as rewards are obtained, they can be gradually sold in an effective STRIPs market to users who wish to obtain benefits through mortgages but do not mortgage themselves.
What powers all tokens
When it comes to the core principles of how collateralized ETH tokens work, the design choices of different pools become more subtle, but still have a significant impact.
Off-chain oracles
In order to be an effective solution to the lack of liquidity, tokens must accurately reflect the value of collateral held by users. This requires the mortgage pool to always have an appropriate amount of ETH in the pool to support its token issuance. The pool does this by tracking the balance of its validators in the beacon chain and generating tokens against them.
Unfortunately, the ERC-20 contract responsible for generating tokens and the balance of the validator (ETH1 and ETH2) are not on the same blockchain. The token contract on the ETH1 chain cannot directly synchronize the balance of the verifier in the beacon chain. The pool overcomes this limitation by using an off-chain oracle, and the working principle of the oracle is similar to the commonly used Chainlink now.
The off-chain oracle allows communication with the beacon chain in the following ways: First, the oracle operator must run the ETH1 and ETH2 nodes at the same time to communicate with the two chains at the same time. Once both nodes are established, oracle will collect information about validators belonging to a specific mortgage pool from the beacon chain and transfer it to the ERC-20 contract on the ETH1 chain. Once the information in the beacon chain is submitted to the ERC-20 contract, the number of tokens (or the exchange rate for generating new tokens) will be updated according to the change in the validator balance. This change can occur either upwards or downwards, depending on whether the balance has increased (that is, rewarded) or decreased (that is, penalized).
Unfortunately, the off-chain oracle has a shortcoming: the entity that controls the oracle effectively controls the token balance. In order to alleviate this problem, pool operators require multiple oracles to submit the same information at the same time in order to update the token balance through a consensus mechanism, and distribute oracles among independent entities to achieve a certain degree of decentralization.
Nevertheless, these solutions are still not ideal, and users are advised to pay attention to whether the pool runs its Oracle in a sufficiently decentralized manner.
StakeWise beacon chain oracle arrangement example
Balance refresh rate
Each update of the token balance in the ERC-20 contract involves gas fees, which in some cases may cost a lot of money. In order to optimize gas fees, most service providers tend to update the token balance daily. Most people think this is sufficient because the daily return on mortgages is quite low (ranging from 0.005% to 0.063% per day), making more frequent updates irrelevant.
However, in the event of large-scale cuts, daily updates may not be enough to solve the problem. As long as the validator commits one of the slashable crimes, a "slash cut" will occur, which will cause the validator's balance to be lost on a large scale within a few minutes (in the most extreme cases, even the entire balance is lost). If the validators of many mortgage pools are cut at the same time, there is nothing more disastrous than updating the balances more frequently every 24 hours.
The problem here is that any user can track the amount of ETH in the mortgage pool validator through epoches (via the beacon chain browser) and understand that it will drop significantly before its balance is reflected in the token. Once the users who hold the pledged ETH tokens realize the mismatch between the ETH in the pool and the token supply, they will run the ERC-20 contract in advance and dump the tokens on the secondary market to save money, so that no Guard against permanent losses and excessive exposure of liquidity providers in the reduced mortgage pool.
In order to avoid this situation, these pools can adjust the refresh rate of their ERC-20 contracts to a higher frequency to balance the increased gas cost with the risk of imbalance in the case of sharp reductions. In fact, the pool is unlikely to be prepared to update the token balance more frequently (let alone every epoch!). Instead, they prefer to reduce the risk of major cuts through improved safety procedures, or only plan to increase the frequency of updates when a cut event actually occurs.
Therefore, it is generally recommended that pool users and liquidity providers monitor the balances of validators belonging to the pool that they hold or provide liquidity. In the future, services such as Beaconcha.in may provide subscriptions for notifications about major cuts, which will help spread information about major cuts and make the secondary market for secured ETH tokens more efficient.
Socialization of profit and loss
The mortgage income and losses of all fund pools are proportional to the size of user deposits and the total amount of deposits in the fund pool (proportionally). This is done to avoid situations where some users receive lower or higher income than other users due to the performance of the validators randomly assigned to them. Assuming that all collective operators act honestly, the main difference is that they are randomly selected to pick out more suggestions, including higher rewards, so the socialization of benefits sounds fair.
However, the socialization of rewards among pool participants still introduces a certain degree of unfairness in the staking process, especially when checking the activation queue of the Eth2 validator (at the time of writing, this process has continued for about 19 day). For example, the total amount of rewards obtained by the validator is distributed to all token holders, while the tokens themselves are generated for new users when depositing. Therefore, even users who have just deposited ETH will participate in the distribution of rewards (because they hold tokens), regardless of whether their deposits have been matched and activated on the beacon chain.
This means that the income of the pool is evenly distributed among all participants in the pool, as if all the deposited ETH is making a return, but in fact, due to the current activation delay of about 19 days, not all deposited ETH is actually ETH is productive. As a result, the APR of holding tokens will be different from the average APR of pool validators, so users should be prepared for this.
Rewards will be distributed among all participants, even if not all of the deposited ETH has been activated
The loss of one user is the gain of another user. There are pros and cons to this situation-everything depends on the user's own point of view. From the perspective of users who have just made a deposit, this socialization is beneficial because it allows them to skip the activation queue that is currently over 3 weeks. Instead, they start making money from mortgages from the moment they deposit funds. At the same time, pool losses caused by mortgages will also reach such users faster.
On the other hand, everyone who has activated ETH and received rewards is willing to share the burden of fines with new token holders, and they will be less hit. However, under normal circumstances, if the pool is operated in a profitable manner, then socializing income with those who have just made a deposit will reduce the profitability of existing users relative to their deposits. The pools with the fastest deposit growth are most affected by this.
Perhaps the simplest way to describe this interaction is that new users will effectively borrow from their own rewards in the future, thereby skipping the activation queue and starting to receive rewards faster.
In general, the faster the number of new deposits in the pool grows and the longer the duration, the greater the drag on the income of existing users. Due to the popularity of pools, this shortcoming can be partially compensated by providing tokens with greater liquidity. Users should consider these factors when choosing who to mortgage with, and pool operators may find ways to generate tokens only when the ETH of a new user is activated.
Charge for service
Pool service fees usually apply to the amount of rewards they receive, ranging from 8% to 23%. The calculation of the reward attributable to the user will take this fee into account immediately, so the growth of the token balance will reflect this fee. When judging the performance of different pools based on the growth rate of the token pool, keep this important detail in mind.
For example, consider two collateralized ETH tokens from two pools, which have the same mechanism and the same validator performance. The tokens in the lower fee pool will naturally grow faster than the tokens in the higher fee pool.
This function is essential for comparing and evaluating the prices of different tokens in the secondary market and their use in DeFi applications. The change in the net rate of return will result in the price difference of different mortgage ETH tokens. Even under the same liquidity depth, lower fees also mean less discounts for ETH.
Re-mortgage reward
A common misunderstanding is that the mortgage pool will automatically re-mortgage the rewards, so the growth becomes compounded. Unfortunately, this is a myth-it is impossible to automatically re-enter the mortgage in the current ETH2 specification, and users should be wary of anyone who claims to re-stake rewards in the pool. Only in stage 1.5 is it possible to withdraw the reward from the validator before re-staking and compounding in the pool. We still have 18 months from that moment, so please beware of false advertising.
Despite the lack of native support, it can also be manually remortgaged by using a dual-token structure pool. Users of such pools can sell mortgage rewards separately from deposits and reinvest the proceeds back into mortgages. As long as the reward tokens can be sold on the secondary market without discount, they can even get a compound return.
The compound effect will become truly powerful over a long period of time, but it can even make a significant difference in a shorter period of time. The chart assumes that the APY in the network is 10%
This naturally makes StakeWise the only operator with a dual-token structure, but let's not rush to act: although we have a strategy to keep the discount for rewarding ETH tokens to a minimum, we cannot guarantee that it will work. Until this concept is confirmed, obtaining compound returns from mortgages before the 1.5 stage is still a problem.
in conclusion
We hope that a common understanding of the design selection and tokenization principles of collateralized ETH tokens can stimulate in-depth discussions on the advantages of different collateral pools in the Ethereum community, bring the required efficiency to the collateralized ETH token market, and protect related interests They are protected from unintended consequences caused by lack of understanding of the product.
We believe that some of the concepts discussed in this article deserve further analysis and discussion, especially the socialization of validator balance changes and the frequency of token contract updates, because they may have a profound impact on the APR generated by the pool.
