LSD. Integration pitfalls
====================

###### tags: `Research`

# Intro

Liquid staking tokens represent user stakes in the Ethereum PoS network. Unlike basic staking, liquid staking allows users to utilize their liquidity in other protocols while still earning rewards from their staked ETH. In basic staking, funds are locked up and inaccessible for a specific period of time, but with liquid staking, the value of the tokens is derived from the staked ether.

These liquid staking tokens, also known as LSDs, have various functionalities. They can be transferred, traded, used as collateral, or redeemed for the underlying staked ETH. Some protocols even increase the redeemable value of ETH over time, resulting in the constant rise of the tokens' value. Other protocols introduce rebasable tokens, which means that users' token balances can fluctuate based on factors like slashings. Additionally, certain protocols implement rewards checkpoints for LSDs, allowing stakers to transfer their tokens without losing their accumulated rewards.

In this article we delve into the key concepts of different Liquid Staking protocols. Additionally, we shed light on potential security problems that may arise when integrating liquid staking tokens integration into other protocols.

## Lido (stETH/wstETH)

### Implementation details
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%.

### Security concerns
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.

## Coinbase Wrapped Staked ETH (cbETH)

### Implementation details
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.

### Security concerns
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.

## Rocket Pool (rETH)

### Implementation details
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.

### Security concerns
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.

## Frax (sfrxETH)

### Implementation details
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.

### Security concerns
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.

## StakeWise (sETH2 and rETH2)

### Implementation details
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.

### Security concerns
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.

# Outro
There are various approaches to implementing liquid staking protocols and their tokens. It is crucial to consider contract ownership and excessive rights, as they can disrupt the logic of protocols that employ these tokens (such as cbETH and Rocket Pool). Protocols integrating liquid staking derivatives (LSDs) should also take into account fluctuations in exchange rates or token values. Typically, the exchange rate increases, and protocols do not include mechanisms for reducing it (as seen with Frax and StakeWise). However, there is a possibility that exchange rates may decrease unexpectedly due to validator slashings or penalties (as observed with Lido). In cases where protocols do not penalize or reward balances, a reimbursement mechanism should be in place to ensure that lost staked ether does not affect the conversion ratio from LSD back to ether.

It is also important to mention different protocol configurations. DAOs or protocol owners can modify minting fees (as in the Rocket Pool case), which can negatively impact integrating protocols by providing them with fewer LSDs than anticipated. Oracles can also change their methods of submitting rewards or exchange rate data, leading to varying arbitrage opportunities and potential liquidity loss for some protocols.

Furthermore, protocols that rely on the actions of a protocol team require special attention. For example, the frxETH case involves a decision window during slashings or penalties, while StakeWise aims to finalize the third version of their protocol, which could alter burning and penalizing mechanics.