Withdrawals for Lido on Ethereum

The Shanghai/Capella upgrade for Ethereum, scheduled for March-April 2023, will introduce support for the unstaking of Ether. The ability to exit a validator and unstake associated Ether is required for the Lido protocol to build the withdrawals feature.

Designing the withdrawal feature for the Lido liquid staking protocol is a complex task due to the difficulty of interfacing data between the Consensus and Execution Layers, as well as the async nature of the Consensus Layer validator exit and slashing mechanics.

The Lido on Ethereum protocol team presents the proposed design for withdrawals feature. We’re looking forward for the community feedback on the matter.


We are seeking the community’s feedback to make sure that our proposal takes all important considerations into account and to identify any potential improvements. We would greatly appreciate your input on the following three questions:

  1. Are the chosen decision drivers right?
  2. Given those drivers, is that the best design possible?
  3. What can be improved in the design or its presentation?

Your feedback is invaluable to create a proposal that is effective, efficient, and fair for all stakeholders.


The document in the post is focused on user flows, tradeoffs and nuances.
To dive into validator side of design, please, look into: 1) exit order post; and 2) automation discussion.


Nice, deeply detailed work, thank you!

I’d like to investigate the inactive leak case in more detail. Should we consider this scenario separately and not finalize requests if an inactive leak was in the reporting period? Oracles only collect reports for the final slot, so we exclude the scenario when an inactive leak occurs during the report. That leaves only the scenario when it’s completed at the time of the report. This situation doesn’t seem much different from other penalties that validators may have accumulated during this period: the impact of a short inactive leak may be comparable to an unavailability of Node Operator validators for some time. And in case the inactive leak was significant, the common checks should enable the bunker mode.

So, I suppose this scenario could be handled by the common rules, which might help to simplify the implementation a little bit.


I’d like to understand better the reasoning for proposing a market for the Lido validator exit queue rather than simply rely on the core Ethereum protocol itself.

Except massive slashing, there are two other scenarios that may cause negative stETH rebase: massive downtime and inactivity leak mode of the network. For example, while both scenarios happening within a short period (from several epochs to several hours) do not affect the protocol much and do not require withdrawal request freezing, downtime of more than 80k validators for more than 24h would cause negative rebase.

For these scenarios, instead of handling inactivity mode or collecting data on offline validators, we can simplify Oracle by estimating rewards/penalties accrued by the protocol.

A 12h delay in withdrawal request processing can be a solution. If massive downtime and/or inactivity leak mode are resolved by the time Oracle reports and there is a negative rebase, the “bunker mode” is set up, otherwise there is “turbo mode”. This solution also mitigates a situation when an arbitrager puts a withdrawal request right before the Oracle report and gets ETH immediately from the protocol buffer before negative rebases happen.

1 Like

I’d like to mention the recent edits made after getting the invaluable feedback from @Izzy and DefiScientist regarding withdrawals processing on the Ethereum network.

There is a withdrawals sweep procedure that puts withdrawal operations for the withdrawable validators into execution payloads, no more than 16 per single payload currently. This sweep is applicable both for partial and full withdrawal types without prioritization. Therefore, it leads to the increased delay for the validator that requested a voluntary exit to finally withdraw the funds (27h to become withdrawable AND up to ~4.34 days to become withdrawn or ~2.17 days avg depending on the validator index and the previously completed sweep boundaries).

More details are available here: [1], [2].

For Lido it means that these timings should be accounted for when voluntary exits are performed to cover the requests if buffered ether amount is not sufficient.


It’s not “Lido validator exit queue” but “Lido withdrawal request exit queue” — two very different things in nature. Lido withdrawal request concerns stETH amount put in the queue, which isn’t tied to specific validator per se. It does, in fact, touch “validators in the Ethereum protocol” set, as in order to fill the stETH withdrawal Lido protocol has to, in some instances, ask for exiting a validator. How those are chosen and what the actual process is — the question of another post I’ve mentioned in the first comments

1 Like

(post deleted by author)