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

So im by far not a tec-guy, but im interested in the section about the oracle-commitee, which is needed to fullfill a withdrawal request.

There are two approaches to using oracles: data can be brought on-chain and calculations can be performed there, or calculations can be performed by the oracles and the outcome can be pushed to the contract.

here are two approaches to using oracles: data can be brought on-chain and calculations can be performed there, or calculations can be performed by the oracles and the outcome can be pushed to the contract.

In general, these two approaches are equivalent in terms of the trust of the oracles committee, but the first approach would require performing the onchain calculations over unbounded data which is not practical due to limited block size and high gas costs.

For example, one of the proposed algorithms for determining the next validator to eject would require a loop over all active validators to find the next candidate. Unbounded loops will also occur when processing withdrawal requests.

Thus, a more practical approach here would be to perform calculations and data aggregation off-chain & make Oracles report the outcomes to smart contracts.

These oracles in the current state seem to bear certain risks of centralization.
As the authors state, the developers

considers this approach to be temporary and will work on a ZK-oracle that can perform the same tasks but in a trustless way.

What are the approaches to perform these tasks in a more trustless way? How far are these developements?
Anyone can elaborate on this?
For me, certain keywords immediately remindet me of Truebit. Would that possibly be capable of these tasks?

Interesting suggestion regarding the use of a ‘committee of oracles’.

Have you explored the use of Truebit style interactive verification as a trustless oracle? It only requires 1-honest validator, so has very minimal trust assumptions. You could either use Truebit directly, or fork the code and use your own validator network to run the nodes, similar to what George Hotz / Optimism did for Cannon OVM.

What are the approaches to perform these tasks in a more trustless way? How far are these developements?

This post should be relevant, but in short - there’s a proof-of-concept solution for an oracle that solves a simpler problem (total value locked oracle), but the approach there is scalable to handle arbitrarily complex logic.

At a very high level the “widthrawals oracle” logic seems to boil down to “given the data about the WithdrawalsQueue, validator balances and withdrawal requests as input, determine if any validator exists are needed, validators to exit, and finalization time according to the specified logic”.

This can be generally achieved the same way as in the TLV oracle example above:

  • merkle tree(s) (or similar techniques) to ensure that an actual and correct data about the queue/validators/widthrawals requests is used as an input via
  • implementing “specified logic” via a verifiable “program” (TVL oracle example uses Cairo, but there are some other similar technologies).

Re: Truebit - probably quite close, but looks like it does not solve the problem of not having Consensus Layer data accessible to Execution Layer and smart contracts (correct me if I’m wrong).


Gist is: we’re exploring the options & path forward, hadn’t settled on the plan yet as full focus is to make Withdrawals & Staking Router work. Look for the post e-kolpakov shared on the state of current developments — ZK-proof Total Value Locked oracle

1 Like

There are many (and counting) potential technologies around. Having to have at least one trusted actor sounds not ideal, but I hadn’t had any deep dive in Truebit specifically.

1 Like

That’s Great, I’m happy hear💖