The withdrawal queue length aims to answer this question:

“If an entity or operator were to exit their validator right now, when would their withdrawn ETH land on their withdrawal address?”

To answer this question, we need to first determine the length of the exit queue. We do this by adding the stake of the validators that are currently in the exit queue (exit_epoch > latest_epoch). We divide this by the current churn limit per epoch to get the number of epochs it will take to clear this queue. We then take the minute equivalent of this number of epochs (6.4 minutes per epoch). There is also a minimum 4 epoch wait to fully exit (MAX_SEED_LOOKAHEAD) so this needs to be taken into account as well. These combined then form the part of the queue involved in exiting.

The MAX_SEED_LOOKAHEAD is the minimum delay on validator activations and exits; it basically means that validators strategically activating and exiting can only affect the seed 4 epochs into the future. See here for more information.

Next we need to determine how long it would take to process the current withdrawal processing queue. This is length of time it will take to process all current partial and full withdrawals at a maximum rate of 16 per execution layer block.

For partial withdrawals, these are validators with valid withdrawal credentials (i.e. 0x01) which have balances of more than 32 ETH, and compounding validators (i.e 0x02) with balances of more than 2048 ETH. Their balances above their respective thresholds get withdrawn. This also includes compounding validators who have requested to partially withdraw some of their stake.

Full withdrawals involve validators who have fully exited and have waited 256 epochs afterwards, meaning their exit_epoch and withdrawable_epoch have passed. We also only consider those who have valid withdrawal credentials and compounding validators. Their full stakes and rewards (i.e. any ETH balance above 0) get withdrawn.

We then add the number of partial and full withdrawals waiting to be processed and divide it by 256 to get the withdrawals processed per epoch (16 per block, 32 blocks per epoch). This gives us the number of epochs it will take to clear the withdrawals waiting to be processed. Multiplying this by 6.4 minutes gives us the minute equivalent of the total epochs.

In actuality, there will be some block proposals missed which means no withdrawals will be processed. We are not taking this into account in this calculation as missed blocks have historically been only around 1% and this is only an estimate which is not aiming to be precise up to the second.

Lastly, to get the full withdrawal queue length from exit to actual withdrawal, we add the minutes calculated related to exiting, and the minutes calculated related to processing the partial and full withdrawals_._

The withdrawal queue length aims to answer this question:

“If an entity or operator were to exit their validator right now, when would their withdrawn ETH land on their withdrawal address?”

To answer this question, we need to first determine the length of the exit queue. We do this by adding the stake of the validators that are currently in the exit queue (exit_epoch > latest_epoch). We divide this by the current churn limit per epoch to get the number of epochs it will take to clear this queue. We then take the minute equivalent of this number of epochs (6.4 minutes per epoch). There is also a minimum 4 epoch wait to fully exit (MAX_SEED_LOOKAHEAD) so this needs to be taken into account as well. These combined then form the part of the queue involved in exiting.

The MAX_SEED_LOOKAHEAD is the minimum delay on validator activations and exits; it basically means that validators strategically activating and exiting can only affect the seed 4 epochs into the future. See here for more information.

Next we need to determine how long it would take to process the current withdrawal processing queue. This is length of time it will take to process all current partial and full withdrawals at a maximum rate of 16 per execution layer block.

For partial withdrawals, these are validators with valid withdrawal credentials (i.e. 0x01) which have balances of more than 32 ETH, and compounding validators (i.e 0x02) with balances of more than 2048 ETH. Their balances above their respective thresholds get withdrawn. This also includes compounding validators who have requested to partially withdraw some of their stake.

Full withdrawals involve validators who have fully exited and have waited 256 epochs afterwards, meaning their exit_epoch and withdrawable_epoch have passed. We also only consider those who have valid withdrawal credentials and compounding validators. Their full stakes and rewards (i.e. any ETH balance above 0) get withdrawn.

We then add the number of partial and full withdrawals waiting to be processed and divide it by 256 to get the withdrawals processed per epoch (16 per block, 32 blocks per epoch). This gives us the number of epochs it will take to clear the withdrawals waiting to be processed. Multiplying this by 6.4 minutes gives us the minute equivalent of the total epochs.

In actuality, there will be some block proposals missed which means no withdrawals will be processed. We are not taking this into account in this calculation as missed blocks have historically been only around 1% and this is only an estimate which is not aiming to be precise up to the second.

Lastly, to get the full withdrawal queue length from exit to actual withdrawal, we add the minutes calculated related to exiting, and the minutes calculated related to processing the partial and full withdrawals_._