LSD. Integration pitfalls

There are two tokens - stETH and wstETH. When users provide ETH they immediately receive stETH tokens which represent their stake. wstETH can be minted using stETH and a special wrapper contract. The wstETH token can be created by using a special wrapper contract. Now, here’s where it gets interesting: stETH is a rebasable token, meaning its balance reflects the user’s rewards or penalties based on their participation. On the other hand, wstETH maintains a constant balance and its value (amount of redeemable stETH) increases over time.

To mint stETH tokens, users can call the submit function and bring ether to stake. Additionally, stETH tokens can also be minted during the processing of oracle reports by calling the _processRewards function. Now, when a user wants to convert some of their stETH into ETH rewards (or withdraw their entire deposit), they need to make a request and lock their stETH in the withdrawal queue. As a result, the user receives a unique NFT that represents their position in the queue. Then, they patiently wait for the oracle report and the finalization of their request. Once these conditions are met, the user can burn their NFT to obtain the requested ether. However, there are withdrawal amount limits in place, which means users may need to split their burnable stETH into multiple parts to enter the withdrawal queue. It’s important to note that the stETH:ETH ratio is determined at the time of request finalization and cannot exceed the ratio at the time of request creation. However, it can decrease if there are any slashings or penalties incurred.

Now, let’s talk about some safeguards in the system to prevent wild fluctuations. To limit significant changes in the exchange rate and balance, there is a clever contract called OracleReportSanityChecker contract. This contract helps mitigate the impact of incorrectly reported oracle data. Additionally, there are limits on potential token rebases, which can be configured. Furthermore, there are also limits on the number of validators that can join or exit the system in a single day. These measures effectively control and restrict the potential for a rebase to occur, although it’s still possible within a recommended range of less than 0.05% to 0.1%.

Protocols seeking to incorporate stETH into their ecosystem must embrace the dynamic nature of rebases, both upward and downward. By doing so, they acknowledge the inherent challenges associated with rebasable tokens. One crucial aspect is that balances should not be stored in state variables. Instead, the protocol logic should consider the actual contract balance, which can be obtained through stETH.balanceOf(address(this)). While wstETH offers more stability in terms of balances, it’s important to note that there are cases where its exchange/unwrap rate to stETH needs to be taken into consideration as well. To address this, protocols integrating these tokens have the opportunity to establish specific limits on balance or rate variances, ensuring a smoother integration and optimum performance.

cbETH is not your ordinary token. Its functionality is intentionally limited, giving it a unique quality. This limitation stems from its centralized nature, which adds a touch of exclusivity to the token. In the world of cbETH, only a select few special addresses have the power to create or destroy cbETH tokens. This authority is safeguarded by the powerful onlyMinters, ensuring that minting and burning privileges are tightly controlled. The masterMinter address holds the key to unlock the ability to bestow minting and burning allowances upon any address. This means that with the configureMinter function, the masterMinter can grant specific amounts of minting and burning power. It’s like a secret code granting access to the hidden realms of cbETH creation and destruction.

And that’s not all! Blacklisting is at play within the cbETH ecosystem. Transfers, approvals, mints, and burns can all be subjected to this mechanism. It adds an extra layer of security and control, ensuring that only authorized actions take place within the realm of cbETH.

Here’s where things get interesting. The exchange rate and balance dynamics of cbETH depend on the configuration of the protocol. Embedded within the token contract is the exchangeRate() function, providing a glimpse into the exchange rate between ETH and cbETH. However, this rate is not arbitrary. It is determined by a select few addresses with the only onlyOracle modifier, who hold the power to push changes to the exchange rate. Of course, these addresses are subject to limitations on the magnitude of such rate changes. In scenarios where significant allowances are involved, brace yourself for noteworthy fluctuations that can have a profound impact.

In this ever-evolving landscape of tokens and protocols, embracing stETH, wstETH, or cbETH requires a deep understanding of their unique characteristics and challenges. But fear not, for those who navigate these complexities with caution and innovation shall unlock access to a world of possibilities.

Furthermore, it is crucial to establish effective safeguards in scenarios where the exchangeRate() experiences a decline or remains stagnant for an extended period (such as when the allowance for minters has been exhausted). Additionally, it’s imperative for integrating protocols to recognize that cbETH originates from Coinbase, a centralized exchange, and all limitations stem from the requirement for users to initially interact with the exchange interface in order to mint or burn cbETH tokens.

The rETH token operates differently from other tokens because it cannot be rebased. To determine the current exchange rate between rETH and the underlying staked ether, the getExchangeRate() function is used. This function relies on the reported ether balance from nodes and stored in a special contract called RocketNetworkBalances. Ether balance is divided by the current rETH supply and that value is considered as the current exchange rate.

The rETH mint function is restricted and can only be called by the RockerDepositPool contract. On the other hand, burn function is not restricted and can be called by any holder of rETH. However, for the burn call to succeed, there must be enough ether in the RocketDepositPool contract (an excess deposit pool balance) plus ether stored on the RocketTokenRETH contract itself.

Network ether balances are submitted by the trusted oracles also known as nodes. The submitBalances function call will only pass once the required number of balance submissions from node operators is reached. It’s worth noting that there are no checks on balance changes, which could potentially have a significant impact in the event of an RPL nodes consensus attack.

Additionally, it’s important to mention that Rocket Pool applies a fee on ETH deposits. This means that users receive fewer rETH tokens compared to the amount of ether they add to the vault balance. From the start, the rETH:ETH ratio is less than 1 for every user. However, this difference in ratio is reflected in the market price of rETH, making it cost more than ETH itself by exactly the fee percentage subtracted during the deposit process.

Protocols that incorporate rETH need to consider the possibility of a decrease in the exchange rate when slashing occurs. The ratio between rETH and ETH can be significantly manipulated during periods when deposit fees are altered, as determined by the Rocket Pool DAO. This could potentially leave other protocols integrating rETH insufficient time to adjust to these changes. Additionally, it is crucial to remain vigilant about the risk of consensus attacks on RPL nodes, where nodes may submit incorrect exchange rate data. Moreover, there is a potential scenario where the protocol owner, who has control through a multi-signature system, can modify the rocketDepositPool address. Such a change would grant infinite minting privileges to the new address.

The sfrxETH is a token that operates on the ERC4626 Tokenized Vault standard. Unlike other tokens, it cannot be rebased. The process of acquiring sfrxETH involves bringing frxETH to the protocol, allowing anyone to mint this unique token. Conversely, anyone who possesses sfrxETH can exchange it back for frxETH. The fascinating aspect of this system is that there are no additional roles involved in the minting and burning functions. When a user mints sfrxETH by depositing Ether, a predetermined percentage of their ETH holdings is withheld. This portion is then utilized to enhance the liquidity of the frxETH/ETH Curve pool. By doing so, this mechanism ensures that LSD (Liquidity Sensitive Deposit) holders can exit their positions promptly, without having to wait for the withdrawal queue to process.

Furthermore, sfrxETH can be unwrapped into frxETH at its current exchange rate. Subsequently, it can be swapped for ETH through the Curve pool. Interestingly, in this process, Frax assumes the role of a liquidity provider (LP), leading to the generation of farming rewards. These rewards play a crucial role in gauge voting, which subsequently increases the CRV emissions of the pool. As a result, more LPs are attracted to participate in the ecosystem.

It is worth noting that the exchange rate between sfrxETH and frxETH only experiences upward momentum due to the absence of a mechanism to withdraw frxETH from the vault in the event of slashings or penalties. In such cases, the vault would receive subsidies through the Algorithmic Market Operations Controller (AMO). The AMO has the capability to reduce the LP position, burn frxETH, and provide the necessary ETH to match the redeemable amounts of users.

Additionally, the exchange rate between sfrxETH and frxETH increases when the Frax multi-sig contract converts ETH rewards into frxETH and deposits them into the sfrxETH vault. This unique feature adds another layer of intrigue to the ecosystem.

Protocols which integrate sfrxETH should be aware of a situation where sfrxETH may detach from frxETH during reward transfers by the Frax team’s multi-sig contract. This creates a risk of deposit front-running, where opportunistic individuals can exploit the process and extract value from protocols that have integrated sfrxETH. Additionally, it’s vital to note that in the event of slashing, the sfrxETH:frxETH ratio might remain outdated for an extended period as the Frax team has the authority to determine pool reimbursements.

There are two tokens implemented: StakedEthToken (sETH2) and RewardEthToken (rETH2). sETH2 is not a rebasable token, rETH2 is rebasable. When users stake ETH, they receive sETH2 and start receiving rETH2 tokens as rewards.

The Pool contract is responsible for minting sETH2 tokens when the stake function is called or when ether is sent to the contract. Current implementation doesn’t allow rETH2 balance to decrease. However, the documentation mentions that in the future V3 version, it will be possible to perform rebases for both sETH2 and rETH2 tokens.

Oracles provide updated data for the rewards. Rewards are calculated on the difference between the new total rewards and the previous total rewards, as uint256 periodRewards = newTotalRewards.sub(totalRewards). It is not possible to submit a smaller newTotalRewards than totalRewards. However, protocol oracles submit merkle root, containing rewards data corresponding to each staker. In the current implementation, these values can be reduced in case of slashing. Additionally, there are rewards checkpoints stored for each holder of rETH2 tokens. These values cannot be reduced in the current implementation, but their growth can be slowed down in cases of slashing.

Protocols that incorporate rETH2 must be aware that the user balance of rETH2 cannot currently be decreased, but this functionality is planned for the future. It is important to note that in the event of slashing, the current protocol behavior is undefined because there are no specified actions to reduce users’ rewards balance or sETH2 balance. However, these tokens can be upgraded, and mechanisms to address this issue may be introduced in the future.