The important change following the upgrade is the launch of withdrawals for staked ETH. Although this gives a lot of new opportunities, we should approach it wisely not to expose users to danger.
Thanks to this article you will:
- understand what the upcoming update changes for crypto staking,
- learn about the challenges faced by staking protocols,
- see Lido’s approach and how they decide to minimize the risks,
- get a FREE security checklist covering threats for liquid staking.
Shanghai/Cappella upgrade
So far, crypto staking has been a one-sided operation. Activating the validator involved performing duties without the possibility to step down and get back ETH. Once locked, it was inaccessible - till now.
The upcoming Shanghai (for execution layer) and Capella (for consensus layer) upgrades enable staking withdrawals on Ethereum, allowing individuals and protocols to unlock both staked ETH and staking rewards.
One of the EIPs considered for inclusion in the Shanghai network upgrade is EIP-4895: Beacon chain push withdrawals as operations. This proposal supports validator withdrawal to the execution layer via gas-free push operation, which means that there is no need to execute additional transactions to collect rewards.
Will the staking rewards start flowing on their own? It depends. Make sure that all your validators have the correct withdrawal credentials set. You are ready when your prefix is 0x01, and NOT 0x00.
You can easily check that by for example visiting initiated deposits section at Ethereum Explorer:
What if your withdrawal prefix is 0x00? No worries, you just need to broadcast which execution layer account should be used for withdrawals by signing the BLSToExecutionChange message and your withdrawal prefix will be updated to 0x01.
WARNING! Setting a withdrawal address is a one-time operation, so make sure you are setting the correct address.
All the necessary details you will find here.
Challenges faced by staking protocols
It was clear from the beginning that this moment would come. Everyone who froze their ETH believed that one day they would be able to unlock them. This time is coming and great changes for staking protocols with it. That will finally unlock their full potential.
However, it will not be so easy, let's take a look at what challenges they face.
Async nature of Ethereum withdrawals
The distribution of rewards works in its “independent” rhythm; they do not compete with regular transactions included in the block. Contrary to the well-known pull over push principle, it's reversed here. The funds flow to the indicated address whether we want it or not. Validator indexes are queued and checked if they are eligible for withdrawal.
Each validator is evaluated by 3 simple instructions:
By default, this will not be an instant effect. We can wait even a few days for partial and full withdrawals, depending on the number of validators and the number of skipped addresses.
See the time to complete provided at ethereum.org:
The relatively long wait is something to keep in mind when planning the unstaking and staking reward distribution mechanisms. Consider splitting your process into several smaller operations.
Withdrawal credential rotation
The address to which staking rewards flow is set once during setting up the validator, being more specific - during the initial deposit. If we want to change it, we have to re-run the validator again, and this means not only a long process of exiting but also the loss of staking rewards during this operation.
The longer the period between cutting off rewards and re-participating in block validation (e.g. more validators need to rotate credentials), the greater the loss.
That is why the address of the treasury or other contract to which the funds’ flow should be permanent or not changed often.
The use of an address-retaining proxy may help to enable updates and improvements.
Another approach might be a very slow transition by exiting only validators with old withdrawal credentials and setting up with new ones, but that might take a lot of time and require maintaining backward compatibility.
Spreading penalties among holders
To not only motivate intended behavior through staking rewards, but also to punish undesirable behavior, there are penalties. The challenge is that when users want to unstake, it is not so easy to determine exactly how much they should get for their tokens.
Minor penalties for inactivity and incorrect attestations are assigned at the beginning of each epoch and are not a big problem. However, slashing might be.
Why?
- It can take even more than 36 days for the slashing to be fully reflected in the rewards.
- Staking pools are more prone to mass slashing.
Where is the problem? In being fair.
We definitely do not want to favor entities that can protect their capital by observing the state of penalties. We want all holders to be treated equally.
The challenge is to be prepared for mass slashing, but also act efficiently when this relatively rare phenomenon does not occur.
Above all, be transparent with your users. Introduce rules that do not favor individuals.
Validator exits
In the case of large withdrawals that cannot be handled from rewards or newly staked Ether, validators’ exits will be required to recover 32 ETH. This operation requires a separate mechanism if nodes are not fully controlled by you and many different operators get staked Ether at their disposal.
You should think about the way, rules, and order in which validators will be selected for an exit. Otherwise, it might be hard to convince anyone to do it voluntarily.
Keeping high protocols APR
To maximize the return on investment for users staking crypto, it is required to make multiple business decisions affecting the project architecture and to optimize them.
It is important to think about answers to the questions, such as:
- Do we prefer users to get their payouts as soon as possible, or rather that their payouts be as large as possible?
- For how long should users earn from their staked assets after requesting a withdrawal?
- From where should we withdraw funds to users in the first place? Buffer? Flowing rewards? Stakeed ETH that has not yet been allocated to launch a node?
- When to start another node? As soon as 32 ETH is accumulated, or is it better to have a small reserve to easily handle small withdrawals?
I don't think there is one best answer, at least now. But, I'm sure there will be plenty of ideas here.
Let's see how current market leaders approached this upgrade by exploring their 3 mechanisms.
Lido approach to withdrawals
Main flow - claims
In this case, Lido mirrors the payout conditions in its process. Asynchrony and queuing allow for effective capital management, and the time required to perform the necessary operations is delegated to the user who has to lock their stETH, wait till operation fulfillment, and then claim rewards.
How is it done?
To withdraw locked Ether, the user needs to lock the stETH amount to be withdrawn by sending the withdrawal request to the WithdrawalQueue contract.
Then all the requests are served by the FIFO queue. Protocol calculates the share redemption rate and obtains Ether to fulfill the withdrawal request. The calculated amount is locked for the user and their stETH is burned.
The user can claim their locked Ether at any time after fulfillment of the withdrawal request.
What is important is that the stake stops earning for the user after fulfillment. A later claim cannot increase the payout;, what counts here is the moment when they get out of the queue and their order is filled. The redemption rate can be just worse than during withdrawal submission. The main reason for that is spreading penalties/slashing across both stETH holders and withdrawers until a positive rebase can still affect the request from the queue.
What’s more, the withdrawal requests are supposed to be transferable. Users will be able to sell their position in the queue on a secondary market.
In the case of such a mechanism, it is important not to create a mechanism that encourages users to be in the withdrawal queue right after a deposit, even though they don’t want to withdraw.
To prevent continuous saving spots, Lido will not allow withdrawal requests to be canceled.
Two operating modes (turbo and bunker)
Due to the fact that the slashing mechanism takes a relatively long time to fully complete. Two operating modes have been introduced.
Turbo mode - used most of the time for normal operation where no serious complications (small inactivity penalties, singular slashings) occur. Processes stETH withdrawals as soon as the protocol has enough Ether to fulfill the request.
Bunker mode - special mode triggered through external Oracles information about mass slashing events within the last 36 days for validators. It adds an extra delay (at least 18 days) to the withdrawal process to fully socialize penalties among withdrawers and holders. After that time, if there are no more problems reported by Oracles - the protocol returns to turbo mode.
You may be wondering: What about user withdrawals if bunker mode is triggered again and again (due to slashing or malicious data served by oracle)?
That’s a good question, but I haven’t found an answer for that yet.
However, mechanisms that are worth considering here might be:
- a small window between delays for payouts reported at a time when it was impossible to know in advance about the next slashing,
- using several oracles as sources of information to increase redundancy,
- partial fill of all queued withdrawals.
Gatekeepers committee
Although everyone tries to anticipate all possible scenarios, there is always the risk of missing something important. This is where emergency features come in very often, and the gatekeepers committee is one of them. It stops withdrawals in the protocol in case of a dangerous situation to gain time.
Gatekeeper is constructed from two elements: the gate seal smart contract stopping the withdrawals and the multisig with the rights to trigger it. We can think of it as a timelock for withdrawals executed by multisig with appropriate rights to do so.
What makes it different from the typical timelock is that:
- It stops withdrawals and no further deposits (usually we deny further deposits to limit potential losses for users and allow withdrawals so that they can decide on their own funds).
- When this emergency function is triggered, there is a vote on the appropriateness of using the gate seal. The Lido DAO votes on whether it was used legitimately and the stop should persist or the reaction was not valid and the protocol should carry on.
- The feature can be used only once, then DAO has to select the new multisig explicitly.
I encourage you to read the provided proposal to learn about other mechanisms proposed by Lido, especially Staking Router which introduces modular infrastructure. They invented many more interesting solutions to minimize the risk and keep their protocol efficient.
Very soon, we will be able to see them in action.
SCSVSv2 liquid staking category
To help staking protocols better prepare for threats, we started working on a separate category in the Smart Contract Security Verification Standard v2. It will not only support auditors to look for specific threats but also help project teams to develop their own approach to handling withdrawals based on best security practices.
Among threats currently included in this category there are the following checks:
| C7.1 | Verify that the rewards mechanism for staked tokens is implemented correctly, and that rewards are distributed fairly and proportionally to all stakers. |
| C7.2 | Verify that all rewards and fee values are in accordance with the documentation. |
| C7.3 | Verify that the rewards mechanism is protected against manipulation or exploitation by malicious actors, such as those who attempt to stake large amounts of tokens to gain an unfair advantage. |
| C7.4 | Verify that during the first stake (when the pool is empty) the appropriate amount of tokens are received by the user. |
| C7.5 | Verify that the staking protocol has appropriate controls in place to prevent unauthorized access to the staked coins and the system's infrastructure. |
| C7.6 | Verify that the protocol has a mechanism for detecting and preventing any attempts at "double-staking" or "stake grinding". |
| C7.7 | Verify that there is a mechanism in place to detect and prevent any attempts at "staking pool front-running," where a malicious staking pool operator can manipulate the rewards mechanism to their advantage. |
| C7.8 | Verify that the user bond is sufficient to cover protocol risks. |
| C7.9 | Verify that the rewards mechanism is protected against "slashing attacks" where a malicious actor attempts to cause other stakers to lose their rewards by attempting to vote for multiple validators at once. |
| C7.10 | Verify that the protocol has a way to handle the situation where a validator goes offline or becomes unresponsive. |
| C7.11 | Verify that the protocol has a way to handle the situation where a validator is found to be compromised and their private keys are leaked. |
| C7.12 | Verify that withdrawal requests cannot be canceled or that canceling them does not affect APR protocols. |
| C7.13 | Verify that withdrawals are not constructed in a way that encourages the staker to stay in the withdrawal queue even though they do not want to withdraw. |
| C7.14 | Verify that the redemption rate at which a request is fulfilled cannot be better than the redemption rate on the withdrawal request creation (if it's a multi-step process). |
| C7.15 | Verify that if the positive rebases affect requests in the queue, it is only to the point where rebases compensate for previously accrued penalties and don’t push the redemption rate higher than it was at the moment of the withdrawal request’s creation. |
| C7.16 | Verify that there is an established mechanism for selecting and ejecting validators in the event of unstake to recover the 32 ETH entrusted to the operator. |
| C7.17 | Verify that there is a mechanism to rotate withdrawal credentials. |
We encourage you to contribute, let’s share our experiences to build a safer future.
Summary
As we can see, the upcoming upgrade brings a lot of new opportunities, but also potential threats. Be careful and do your best to protect your users.
If you have any questions or need help, write to me and let’s have a chat.
- Did you like this article? Be sure to share it on social media!
Subscribe to the newsletter to not miss any of the future articles. Composable Security 🇵🇱⛓️ is a company that increases the security of projects based on solidity smart contracts.
If you need support in the field of security or auditing smart contracts do not hesitate to contact us.
About the author
Co-author of SCSVS and White Hat. Professionally dealing with security since 2017 and since 2019 contributing to the crypto space. Big DeFi fan and smart contract security researcher.
