Since the Ethereum 2.0 beacon chain went online just over a month, the balance of the Ethereum 2.0 mortgage address has exceeded 2.4 million Ethereum. At the same time, a large number of third-party staking platforms have been launched, including the centralized trading platform Binance and decentralized DeFi projects such as Rocket Pool and Lido. These different staking solutions are different in many aspects.
Despite their differences, they have one thing in common: all projects are proposing solutions to the inevitable frictions created by staking Ethereum. So, what exactly are these frictions?
First of all, the technical complexity of Ethereum 2.0 pledge is beyond the capabilities of ordinary users. With the rapid increase in the price of Ethereum ($1040 at the time of compilation), the minimum deposit requirement of 32 Ethereum is becoming more and more out of reach for ordinary users. Finally, in order to achieve the transition to Ethereum 2.0 in a safe and controllable manner, the pledge has a non-current lock-up period of 18-24 months.
In summary, these restrictions can prevent less sophisticated users from entering the “profitable” Ethereum 2.0 staking market.
How does the pledge pool solve this problem?
This is where the Ethereum 2.0 pledge pool comes in. They obtain Ethereum from multiple users and perform Ethereum 2.0 staking operations on behalf of users, so that any participant can receive staking rewards, regardless of their technical level or deposit scale.
In addition, they are trying to alleviate lengthy liquidity requirements by issuing Ethereum mainnet tokens that represent users’ deposits and rewards on the Ethereum 2.0 chain. These pledged tokens provide holders with an opportunity to unlock liquidity, allowing users to trade Ethereum 2.0 pledged tokens into Ethereum native tokens in secondary markets such as Uniswap to withdraw from the pledge early, and use their pledged tokens The ability to participate in DeFi (for example, as collateral at Aave).
However, the implementation models of pledged tokens between different pools are different, which will undoubtedly bring some serious effects to users. For example, Lido’s third-party pledge token (stETH token) is different from StakeWise’s third-party token, so pricing in the secondary market should be different. At the same time, Rocket Pool’s rETH token and stETH implementation are also different, and CREAM’s crETH2, Stkr’s aETH, etc. are also different.
In short, there are many differences in the token mechanisms from different staking pools, and these differences may cause confusion and bring adverse consequences to end users. However, these differences can be classified and evaluated in order to discover the strengths and weaknesses of their respective pledge pools. In addition, this comparative analysis can show the price efficiency of different Ethereum 2.0 pledge tokens.
In this article, I will uncover the mystery of the principle of Ethereum 2.0 tokenization and give examples of how the tokenization of different staking pools works.
Staking token model
According to the classification of the token structure, two different structures can be distinguished: one is a single token design, which aims to obtain the initial deposit and income of depositing a token at the same time; the other is a dual token design, which will pledge deposits and The rewards are used as two different tokens.
Single token design
The single token structure is based on the concept of rebalancing or repricing tokens. This is the most popular design, and most staking pools use this strategy, probably because of its simplicity. By issuing a single token when the user deposits, the pledge pool seeks to realize the rights and responsibilities of rewards and punishments in the same token. This can be achieved in two ways:
1. Change the quantity: the rewards and punishments in the Ethereum 2.0 pledge contract are reflected by changing the token balance. In the 1.5th token circulation stage, each pledge token will be in the pool at a ratio of 1:1 Converted to ETH in China;
2. Change the price: The rewards and penalties in the Ethereum 2.0 pledge contract are reflected by the token price. In the 1.5 token circulation stage, the amount of redemption of each pledge token is rewarded by the pledge pool. fluctuation.
1. The way to change the number of tokens, representative projects include: Lido and Binance.
2. Change the way of representing prices, Rocket Pool, Cream, StaFi and Stkr.
Although different mechanisms are used to reflect the accumulation of revenue, the design of a single token has one thing in common: deposits and rewards are bundled in the same token. This means that whenever you buy or sell tokens in the market or get tokens from depositors, you will receive/sell deposits and any rewards accumulated in the pool in the past.
Dual token design
Instead, the dual token structure is based on the concept of two rebalanced tokens, which reflect deposits and rewards respectively.
In contrast, the dual token structure is based on the concept of two rebalanced tokens that reflect deposits and returns respectively. Taking stakewise tokens as an example, deposit and return tokens are stETH and reETH respectively.
When holding a dual-token design of pledged tokens, the token stETH representing the pledged Ethereum will not grow, and the rwETH (reward ETH) tokens accumulated at a 1:1 ratio will be reflected in the share of income in the pledge pool increase. In short, the sum of these tokens constitutes the overall revenue state and can be freely transferred between the Ethereum network and used in the same way as a single token in a smart contract.
As long as it holds pledge tokens, it will accumulate reward tokens. As the reward pool grows, the balance of stETH, the Ethereum token representing the deposit, remains unchanged, but the holding address will receive the reward token reETH.
The dual token structure allows the creation of a new dynamic hybrid model similar to bonds, but the difference is that it divides the pledge into two parts with different accrued values and cash flow expectations (principal and interest), thereby enabling Manage personal pledges more effectively and flexibly.
Details of staking tokens
When it comes to the core of the work of Ethereum 2.0 pledged tokens, the design choices of different pools become more subtle, but they can still make major differences.
Off-chain oracle
In order to be an effective solution to liquidity stagnation, tokens must accurately reflect the value of the pledged tokens held. This requires placing the correct amount of Ethereum in the pledge pool to support the corresponding pledge tokens. In order to achieve this, the staking pool needs to track their node balances in the Beacon Chain and issue tokens against them.
But what you need to know is that the contract responsible for issuing tokens and the balance of the verification node are not on the same blockchain (Ethereum 1.0 VS Ethereum 2.0).
Unfortunately, the ERC-20 contract responsible for issuing tokens and the node’s balance are not on the same chain (ETH1 vs ETH2). The token contract on the Ethereum 1.0 chain cannot directly synchronize the balance from the verification node of the beacon chain. The pledge pool needs to bypass this restriction by using off-chain oracles. Its working principle is similar to that of Chainlink, which is now ubiquitous.
The off-chain oracles can obtain the beacon chain data in the following ways: First, an oracle computing node must run Ethereum 1.0 and Ethereum 2.0 nodes at the same time in order to interact with the two chains at the same time. Once both nodes are started, the oracle will collect information from the verification nodes belonging to a specific pledge pool from the beacon chain and transfer it to the ERC-20 smart contract on the Ethereum 1.0 chain. Once the beacon chain information is submitted to the ERC-20 contract, the number of tokens will be updated according to the change in the verification program balance (or the exchange rate will be changed to issue new tokens). This change can go up or down, depending on whether the balance increases (i.e. get rewards) or decreases (i.e. incur fines/).
Unfortunately, the off-chain oracle brings a disadvantage: the entity that controls the oracle effectively controls the update of the token. In order to alleviate this problem, the pledge pool requires multiple oracles to submit the same information at the same time, in order to update the token information through a consensus mechanism, and allocate oracles to achieve a certain degree of decentralization.
Stake token balance refresh rate
Each token balance update in the ERC-20 contract involves a gas fee. In order to optimize gas fees, most service providers prefer to update the token balance every day. Most people think this is enough, because the daily income is very low (ranging from 0.005% to 0.063% per day), making more frequent updates irrelevant.
However, in the event of large-scale slashing, daily updates may not be enough. As long as the verification node makes a mistake that incurs confiscation, a “penalty and confiscation” will occur, which will cause the verification node to lose in a few minutes. If the frequency of updating the balance is lower than 24 hours, it will cause disastrous consequences.
The problem here is that any user can track the amount of Ethereum in the verification node monitoring the pledge pool through epochs (via the beacon chain browser), and “foresee” the reduction of its balance before the token is updated. Once users are aware of the potential loss that is about to occur, they will execute the ERC-20 smart contract in advance, sell tokens on the secondary market to reduce losses, and cause unsuspecting liquidity providers to suffer permanent losses and be fined. Holds a large number of positions in the pledge pool.
In order to avoid this situation, the pledge pool can adjust the refresh frequency of its ERC-20 contract to a higher frequency and increase the cost of gas fees to prevent the risk of balance mismatch during the penalty. But in reality, it is unlikely that the staking pool will update the token balance more frequently (let alone every epoch). On the contrary, they are more inclined to reduce the risk of forfeiture by improving safety procedures, or only plan to increase the frequency of updates when a forfeiture event does occur.
Therefore, it is recommended that users and liquidity providers (LPs) of the staking pool monitor the balances of the verification nodes that they hold or provide liquid staking pools to prevent untimely penalties and preemptions.
to sum up
I hope that the research and understanding of the Ethereum tokenized pledge design can stimulate in-depth discussions in the Ethereum community on the advantages and disadvantages of different staking pools, improve the efficiency of the tokenized Ethereum staking market, and protect those who know little about their use. The pledger who suffers accidental consequences for his products.
Some concepts discussed in this article deserve further analysis and discussion, and can have a profound impact on the annualized rate of return (APR) derived from the Ethereum 2.0 pledge pool.
