TL;DR

The Lido protocol should allow for faster withdrawals for most stakers under most conditions. This is made possible by the Lido protocol buffer, the use of which is prioritised for withdrawal requests (provided there is enough ETH in the buffer to fulfil them).

 

In particular, assuming current network size, no exit queue on the Beacon chain, and no serious incidents on the network:

 

• For most stakers who use Lido (i.e those who hold less than 1000 stETH), most withdrawal requests should take less than 1 day to complete (compared to 2-6 days for a standard Ethereum withdrawal) assuming there is enough ETH in the Lido protocol buffer to service the withdrawal requests. If there isn’t, then a Lido withdrawal request can take slightly longer than a standard Ethereum withdrawal (between 3-8 days).

 

• Lido withdrawal requests in the range of 1000 to 5000 ETH are also likely to be completed relatively quickly (≈ 2 days) compared to standard Ethereum withdrawals (2-6 days): for example, the expected processing time for a request of 5000 stETH is 2 days – though this can take longer (between 5-9 days) if there is a shortage of ETH in the protocol buffer. Alternatively, it should be possible to swap such an amount in the ETH-stETH Curve pool for a small discount (less than 0.12% as long as the pool is balanced).

 

• Lido withdrawal requests greater than 5000 ETH and up to 100,000 ETH are expected to take between 4-10 days to complete (compared to 4-8 days under a standard Ethereum withdrawal). Alternatively, it should be possible to swap an amount of this size in a balanced Curve pool for a discount of between 0.12% (for amounts closer to 5000 ETH) and 2% (for amounts closer to 100,000 ETH).

 

• Lido withdrawal requests greater than 100,000 ETH are expected to take two weeks to complete.

 

N.B. All the time estimates given above are conditional on there being no exit queue, and no major slashing events or other unforeseen tail-risk scenarios. Withdrawal time could be delayed if there are changes to the assumptions.

 

Some other important points worth highlighting:

 

• Expedited withdrawals are made possible by the Lido protocol buffer, the use of which is prioritised for withdrawal requests (provided that there is enough ETH in the buffer to fulfil them). Based on the history of ETH staked using Lido, Execution Layer rewards, and our current estimate of Consensus Layer rewards, we estimate that there is a ~97% probability that the protocol buffer has more than 1000 ETH on any given day (when there is no demand for withdrawals). This means there is a very high probability that total daily withdrawal requests of less than 1000 ETH can be fulfilled within a day. For comparison, the normal Ethereum withdrawal process can take anywhere between 2 and 6 days (assuming no exit queue and no incidents with an exiting validator).

 

• If there is an especially large Beacon chain exit queue, the Lido protocol buffer can result in significant time savings, even for relatively large withdrawals (up to 15,000 ETH). For example, if the exit queue is on the order of 56k validators (or approximately 10% of the current network size), the Lido protocol can shorten the time to withdrawal completion by approximately 1 month  (compared to a standard Ethereum withdrawal).

 

• In contrast to vanilla staking, a post-withdrawal slashing shouldn’t affect the time to withdrawal: since the Lido protocol allows stakers to receive tokens routed directly from either another validator or the protocol buffer, the staker does not need to wait the 36 days associated with a slashing delay.

 

• Chaotic tail-risk scenarios, such as a mass slashing event, can trigger an emergency mode in the protocol called “bunker mode” which has the effect of temporarily postponing withdrawals. If the Lido protocol is in bunker mode, withdrawal requests are delayed until the consequences of the incident that caused it to enter this state are resolved (withdrawal delays can last anywhere between 1 and 36 days while the Lido protocol is in bunker mode).

 

• Quasi-instantaneous exits are possible via exchange (although there is an inevitable time-money tradeoff): Assuming enough liquidity, a staker using Lido always has two other options to exit from stETH that are quasi-instantaneous: they can either swap stETH for ETH on a DEX / CEX, or sell the NFT received when a withdrawal request was submitted. Although in both cases, a discount is expected.

 

Withdrawing without using Lido

In order to withdraw funds from the Beacon chain, three main steps need to be taken:

1. A staker broadcasts an exit message to send a validator to the exit queue.
2. The validator in question receives a withdrawable epoch (and continues performing its validator duties until that epoch is reached).
3. The validator’s balance is transferred via inclusion in a block (after it has been sweeped).

 

The breakdown of time between the exit message being sent and the tokens being transferred, is as follows:

Withdrawal delay + Sweeping time (Base case)

 

There are two additional factors that can lengthen the exiting process: exit queue and post-withdrawal slashing.

 

When there is an exit queue, one has to add an exit queue delay:

Withdrawal delay + Sweeping time + Exit queue delay (Exit queue case)

 

While exiting, there is also a chance (albeit small) that a validator gets slashed. If this happens, the withdrawal time will also include a slashing delay:

Withdrawal delay + Sweeping time + Slashing delay (Slashing case)

 

The worst case scenario (from a withdrawal time perspective) implies an exiting validator getting slashed while stuck in an exit queue:

Withdrawal delay  + Sweeping time + Exit queue delay  + Slashing delay (Worst case)

 

Exit time with no exit queue and no slashing (Base case)

Let’s first consider the optimistic case (no exit queue and no slashing).

 

Once the exit message is registered, a withdrawable epoch is assigned. This period is determined by MIN_VALIDATOR_WITHDRAWABILITY_DELAY with MAX_SEED_LOOKAHEAD. In total it sums to 261 epochs, or ~ 27.8 hours.

 

When a withdrawable epoch is reached, a validator becomes eligible for withdrawal, and its balance can be included in the next available block (a maximum of 16 withdrawals can be processed in a single block).

 

The actual block where this happens depends on the sweeping time, which in turn depends on the total network size and the relative position of the validator index in the queue. To put things in context, the Median time estimate for sweeping (under current network size) is 2.4 days, while the time estimate for processing all validators (maximum waiting time) is 4.8 days.

 

Summing up withdrawal delay and sweeping time for the current network size (~563k validators) a withdrawal takes (Base case):

 

~ 1.7 days: for extremely lucky validators (10th percentile) during sweeping.

 

~ 3.6 days: for the average validator (50th percentile ) during sweeping.

 

~ 6 days: for unlucky validators (the last to be processed) during sweeping.

 

Note that the above estimates apply for a single validator. If your withdrawal request is big enough to send a significant number of validators to exit, it will create an exit queue, which will result in a longer processing time. Under the current network size, the maximum rate of exit is 75 validators/hour (that’s the same as 2,400 ETH/hour; 1,800 validators/day, or 57,600 ETH/day).

 

To put the exit queue processing time in context, exiting one validator from the Beacon chain takes on average 3.6 days (and not more than 6 days under normal conditions), while each additional 10,000 ETH adds ~0.17 days.

 

As noted above, as the network size fluctuates, the estimated time to withdrawal also changes. Here’s a summary table that takes into account three network size scenarios:

 

Time (days) to exit under 3 network size scenarios with no exit queue:

Standard exit	Current network			Current network + 50%			Current network - 50%
Validators to exit	Min	Median	Max	Min	Median	Max	Min	Median	Max
1	1.65	3.60	6.05	1.89	4.82	8.49	1.40	2.38	3.60
+ per each 1000 validators	0.56			0.37			1.11
+ per each 10,000 ETH	0.17			0.12			0.35
100	1.71	3.66	6.10	1.93	4.86	8.53	1.52	2.49	3.71
1000	2.20	4.16	6.60	2.27	5.20	8.86	2.52	3.49	4.71
10000	7.20	9.16	11.60	5.60	8.53	12.19	12.52	13.49	14.71

 

Exit time with exit queue

In case of an exit queue, the waiting time is defined by the network size and how long the queue is. In particular, the exit speed is rate limited to preserve the stability of the Ethereum network.

 

By design, only 1 in every 65k validators can exit each epoch. For the current mainnet network size this means the practical rate limit is 8 validators per epoch, or 1.8k validators per day.

 

In general, the waiting time in an exit queue increases by 0.31 days for every 0.1% of validators in the queue. So, if 1% of validators (5.6k validators, or 180k ETH at current size) are in the queue it can take around 3 additional days for a validator at the back of the queue to exit, whereas if 10% of validators (56k validators, or 1.8M ETH) are already in the queue exiting can take closer to a month.

Adding a withdrawal delay and sweeping time on top of these estimates, when the exit queue is ~10% of the current network size, a withdrawal takes (Exit queue case):

 

~ 32.9 days: for extremely lucky validators (10th percentile) during sweeping.

 

~ 34.9 days: for the average validator (50th percentile ) during sweeping.

 

~ 37.3 days: for unlucky validators (the last to be processed) during sweeping.

 

As noted above, as the network size fluctuates, this estimated time will also change. Here’s a summary table that takes into account three network size scenarios:

 

Time (days) to exit under 3 network size scenarios with 10% exit queue

Exit queue of 10%	Current network			Current network + 50%			Current network - 50%
Validators to exit	Min	Median	Max	Min	Median	Max	Min	Median	Max
1	32.92	34.87	37.31	33.16	36.09	39.75	32.67	33.65	34.87
100	32.97	34.93	37.37	33.20	36.13	39.79	32.78	33.76	34.98
1000	33.47	35.42	37.87	33.53	36.46	40.13	33.78	34.76	35.98
10000	38.47	40.42	42.87	36.87	39.80	43.46	43.78	44.76	45.98

 

Exit time with slashing

While exiting, a validator performs its duties and remains at risk of slashing. If a slashing happens, the slashing delay is defined by EPOCHS_PER_SLAHINGS_VECTOR = 2^13 epochs, or ~ 36 days.

 

On top of this we always have to factor a withdrawal delay and the sweeping time, in addition to a potential exit queue delay. In summary, for the current network size an exit for a slashed validator is expected to take:

 

~ 38 - 42 days when there is no exit queue (Slashing case)

 

~ 38 - 74 days when the exit queue is 10% of the network (Worst case)

 

Putting the above estimates together

Here’s a summary table for exiting a validator that covers all the above scenarios:

 

Time to exit without Lido (days)

	No exit queue	10% exit queue
Validator not slashed	min: 1.7 median: 3.6 max: 6	min: 32.9 median: 34.9 max: 37.3
Validator slashed	min: 38 median: 40 max: 42.4	min: 38 median: 55.6 max: 73.7

 

In sum, at current network size the expected delay for a vanilla withdrawal under normal conditions is 3.6 days. This increases to up to 35 days when the exit queue is 10% of the network, and up to 40 days if the validator in question is slashed after signing the withdrawal message. Under a worst case scenario (validator is slashed and there is an exit queue of 10%) it can take more than 2 months to completely exit and withdraw funds.

 

A good rule of thumb to keep in mind for a vanilla Ethereum withdrawal is the following: the median time to exit, assuming no exit queue, is 3.6 days. Add 3 days to this estimate for every 1% of validators in the exit queue. Add 36 days if your validator gets slashed. If you’d like to learn more about withdrawals, see here for Danny Ryan’s excellent Withdrawals FAQ.

 

Withdrawing using Lido

The Lido protocol adds pooling mechanics to the vanilla withdrawal process described in the previous section. In particular, the Lido protocol buffer should allow for faster exits for most stakers under most conditions.

 

To withdraw funds from the Lido staking pool, the steps are as follows:

1. A staker submits a withdrawal request.
2. Lido Oracle registers the request and puts it in the Lido withdrawal queue: Lido handles withdrawal requests on a first-come-first-served basis.
3. Lido Oracle decides on the protocol mode (turbo/bunker).

 

4a. If the Lido protocol is in turbo mode:

• ETH in the protocol buffer is used to fulfil the requests.
• If the ETH amount is not enough to fulfil all the requests, Lido Oracle registers validators for exit.
• Vanilla exit from the Beacon chain: Lido broadcasts an exit message, each validator gets a withdrawable epoch, after the epoch is reached a validator goes through the sweeping process and funds arrive in Lido Vault.
• Lido Oracle reports back and funds become eligible for claiming.

 

4b. If the Lido protocol is in bunker mode:

• The withdrawal requests are delayed until the consequences of the incident that caused “bunker mode” are resolved, for more details see here.

 

In sum, for a staker using Lido there are three possible outcomes depending on the network demand for staking/unstaking and the Lido protocol mode:

1. Expedited exit via the Lido protocol buffer: exit can be quickly serviced by new demand.
2. Standard exit via network broadcast: exit messages for validators are broadcast to the Ethereum network.
3. Delayed exit due to “bunker mode”.

 

1. Expedited exit (via protocol buffer)

By design, the Lido protocol accumulates ETH, while the off-chain oracle decides on partitioning between completing withdrawals and forwarding staking deposits.

 

The Lido protocol accumulates ETH from three sources:

• Newly staked ETH.
• Withdrawals (full withdrawal when a validator is sent to exit as well as partial, or skimmed rewards).
• Execution Layer rewards.

 

ETH from the buffer outflows as follows:

• The protocol first finalizes the withdrawals requests and allows stakers to redeem their stETH directly from the buffer (no validator exits needed).
• Any remaining ETH is sent to the Beacon chain, spawning new validators.

 

 

Based on the history of ETH staked via Lido, Execution Layer rewards, and our current estimate of Consensus Layer rewards, we conclude that there is a ~97% probability that the protocol buffer has more than 1000 ETH on any given day, a ~40% probability that the buffer exceeds 5,000 ETH, and a ~15% chance that it contains more than 10,000 ETH  (when there is no demand for withdrawals).

 

Importantly, if the requested withdrawal amount is more than the current buffer size it can still be finalized using the inflows that arrive in subsequent days.

 

 

Of particular note, there are important scenarios under which the protocol buffer can be used to shorten the waiting time (compared to vanilla staking) significantly: for example, from a standard waiting time of 33-37 days (when the exit queue is 10% of the current network size) to 3-5 days (for Lido withdrawal requests within the range of 15,000 ETH).

 

The protocol buffer can also be used to expedite an exit when an exiting validator is slashed post withdrawal request. Notably this can save a Lido staker up to a month of waiting time compared to vanilla staking!

 

We can estimate the expected inflows into the buffer as follows:

Estimated waiting time (days) for accumulating funds in the protocol buffer

Probability	Amount that will arrive in the protocol buffer, ETH
	15,000	25,000	50,000	100,000
Low  (25% chance)	2	4	8	16
Median (50% chance)	3	5	9	18
High  (75% chance)	4	6	11	20

 

How much time does it take to withdraw via the protocol buffer?

 

There is a moving 24h window from 1200 PM UTC - X on day T-1 to 1200 PM UTC - X on day T, where X is currently set to 23 epochs (~2.5h). The requests submitted within this window are processed at 1200 PM UTC on day T.

 

For example, suppose day T = ‘2023-06-01’ and there are 5 withdrawal requests:

• WR1 submitted at ‘2023-05-31 11:00:00’
• WR2 submitted at ‘2023-05-31 13:00:00’
• WR3 submitted at ‘2023-06-01 09:00:00’
• WR4 submitted at ‘2023-06-01 11:00:00’
• WR5 submitted at ‘2023-06-01 13:00:00’

 

WR1-3 will be processed on ‘2023-06-01 12:00:00’ (day T), while WR4-5 will be processed a day later on ‘2023-06-02 12:00:00’ (day T+1).

 

In sum, if there is low withdrawal demand and the withdrawal amount is not large (less than 1000 ETH), the protocol buffer can be used to expedite exits. This can take anywhere between 2.5 hours and 26.5 hours depending on when the withdrawal request is made.

 

2. Standard exit (via network broadcast)

In the case that the ETH in the protocol buffer is not enough to fulfil all current withdrawal requests, Lido Oracle sends validators to exit the standard way (vanilla Ethereum withdrawal). The Lido protocol adds to this process a time window for registering a request and an operations delay connected with the validators’ ejection times.

 

As already mentioned, the time window for registering a request can take anywhere between 2.5 hours and 26.5 hours. The operations delay takes between 4 and 24 hours. So, in total, a non-expedited exit via the Lido protocol adds between 6.5 and 50.5 hours to the vanilla withdrawal time.

 

3. Delayed exit due to bunker mode

Bunker mode is a mechanism that protects Lido users who are unstaking during rare but potentially highly adverse network conditions. It is a Protocol mode that is activated when the Consensus Layer penalties might be big enough to have a significant impact on the Protocol's rewards.

 

During bunker mode, withdrawal requests are paused until the negative events are resolved:

• For incidents that result in prolonged downtime spanning across tens/hundreds of thousands of validators, the expected delay is 1 day, with a maximum delay of 7 days.
• For mass slashing events, the expected delay is expected to be 18 days with a maximum delay of 36 days.

 

Taking into account that bunker mode is only triggered in response to chaotic tail-risk events, it should rarely, if ever, be activated (a backwards analysis shows there have been no incidents so far that would have triggered bunker mode). Examples of tail-risk scenarios that could trigger bunker mode include: the 4 biggest Lido Node operators simultaneously going offline for an entire day, a technical issue in a validator client that triggers more than 500 continuous slashings, or simultaneous and widespread outages at AWS, GCP, and Hetzner.

 

More details on this as well as how withdrawal requests are finalized when the Protocol is in bunker mode can be found here.

 

Summary table of the above three scenarios

Time to withdraw (days) via Lido (for 1 validator)

	No exit queue	Exit queue of 10%
Exit via protocol buffer	min: 0.1 median: 0.6 max: 1.1	min: 0.1 median: 0.6 max: 1.1
Exit via sending validators to exit (No slashing/Small slashing event)	min: 2.3 median: 4.7 max: 8.1	min: 4 median: 20-36 max: 39
Mass slashing events	min: 1.6 median: 22.9 max: 44.6	min: 4.8 median: 57 max: 76

 

Summary table: withdrawing without Lido vs withdrawing with Lido

Time to withdraw (days)  Vanilla Ethereum staker (green) <>  Lido Ethereum staker (blue) (for 1 validator)

	No exit queue	Exit queue of 10%
No slashing	min: 2 <> 0.1 median: 4 <> 1-5 max: 6 <> 8.1	min: 33 <> 0.1 median: 35 <> 20-36 max: 37 <> 39
Validator is slashed	min: 38 <> 2.3 median: 40 <> 5 max: 42 <> 45	min: 38 <> 4 median: 56 <>20-36 max: 74 <> 76

 

On quasi-instantaneous exits

If the time to exit is considered too long, a staker using Lido has two other options available to them:

1. Instantly exit via swapping stETH on a DEX or CEX.
2. Instantly exit via selling the NFT received when the withdrawal request was submitted.

 

1. Instantly Exit via swapping stETH on a DEX or CEX

Today, the main stETH liquidity reserves are concentrated in the Curve stETH/ETH pool. Detailed stats on the pool can be found here.

 

If the stETH/ETH rate ≥ 1, the stETH can be swapped for a premium (minus a swap fee). If stETH/ETH rate < 1, the stETH can be swapped at a discount (minus a swap fee).

 

The amount of ETH available for swapping and the associated premium/discount depend on the liquidity reserves and their balance in the relevant pool.

 

For example, at time of writing, there exists 476k stETH and 431k ETH in the Curve pool, which gives a stETH:ETH rate of 0.99714. We assume that when withdrawals go live, the incentives for the pool will be reduced and, as a result, that liquidity reserves will go down. We’ve run several simulations for different sized pools and have found that amounts in the range of 50k-100k stETH can be swapped under every pool size scenario, at a discount of between 0.4 - 0.9% for swaps of size 50k, and between 0.8 - 2.1% for swaps of size 100k.

 

Note that very large swap amounts (more than 100k stETH) can face lack of liquidity reserves or provoke a cascade liquidation in the pool and high discounts of 2% or more. As a result, we recommend withdrawing via standard exit for amounts greater than 100k stETH.

 

 

2. Exit via selling NFT

When a withdrawal request is submitted, a staker receives an NFT, which gives them rights over claiming the withdrawal once it has been processed. The expectation is that this can then be sold on a secondary market (possibly for a discount).

 

Summary

The main takeaway is that there is a time-money type of trade-off for exiting from stETH to ETH.

 

At the end of the day, there are three possible paths:

1. Instantaneous exit via swaps on AMM and CEXes.
2. Expedited exit via the Lido protocol buffer (assuming there is enough ETH to service the request).
3. Standard exit via vanilla Ethereum withdrawal.

 

While stakers can always choose the first path, if they choose to withdraw using Lido the Oracle will pick between the second and third paths. Which path is ultimately chosen depends on four predominant factors: the amount to withdraw, the stETH/ETH rate, the performance of validators, and the net staking demand in the context of the Beacon chain state.

 

There is no simple answer that applies to all stakers under every scenario.

 

Here are some guidelines in table form:

How to exit from stETH

stETH (amount to withdraw)	Exiting via Lido protocol			Exiting via Curve swaps		Exiting via standard Ethereum withdrawal		Lido users (%)
	Time (days)		Discount, %	Time (days)	Discount (%)	Time (days)	Discount (%)
	Protocol buffer	Withdrawals
< 1,000	0.6 - 1.1	4.7 - 8.1	~0	txn time	0.04 - 0.06	3.6 - 6	~0	98.98
1,000 - 5,000	0.6 - 2.1	4.7 - 8.2	~0	txn time	0.05 - 0.12	3.6 - 6.1	~0	0.66
5,000 - 10,000	2.1 - 4	4.8 - 8.3	~0	txn time	0.07 - 0.2	3.7 - 6.2	~0	0.15
10,000 - 50,000	3 - 11	4.9 - 9	~0	txn time	0.11 - 0.89	3.8 - 6.9	~0	0.16
50,000 - 100,000	9 - 20	5.6 - 9.9	~0	txn time	0.38 - 2.08	4.5 - 7.8	~0	0.03
100,000 - 150,000	18 - 30	6.4 - 10.7	~0	txn time	0.74 - 4.54	5.3 - 8.6	~0	0.01
150,000 - 200,000	27 - 40	7.3 - 11.6	~0	txn time	1.15 - 11.39	6.2 - 9.5	~0	0.00
> 200,000	> 40	> 12	~0	txn time	-	> 10	~0	0.01

First choice

Second choice

No objective preference (time-money tradeoff)

Not-recommended

 

N.B these guidelines assume normal conditions. All ranges given are median-max. In the case of high demand for withdrawals, the exit queue will add 3 days of delay for every 1% of the network that is in the queue (e.g. 10% of the network attempting to exit at the same time leads to a month of delay).

 

In the case of a chaotic tail-risk scenario (e.g. mass slashing) you will also need to add up to 36 days to the above time estimates for exiting via the Lido protocol. See the TL;DR at the start of this post for our best attempt at a useful synthesis.