ELI5: Ethereum Validator Exits

^{^{^for a relatively crypto-native five-year-old…}}

Image Not Showing Possible Reasons

The image was uploaded to a note which you don't have access to
The note which the image was originally uploaded to has been deleted

by mike neuder & mallesh pai – march 17, 2025 🍀🇮🇪☘️

many thanks to Paul Harris, Mikhail Kalinin, Lucas Saldanha, and Alex Stokes for comments and discussions.

Section 1 – How exits work today
1.1 – Terminology
1.2 – The exit process
1.3 – Aside: Why have an exit queue?

Section 2 – What changes in the Pectra hardfork
2.1 – New terminology
2.2 – Exit queue churn limit changes
2.3 – Validator sweep changes

This article has two parts.

First, we clarify how the exit process for validators currently restricts withdrawal rates in the Ethereum consensus mechanism (and the rationale for rate limiting).
Second, we explain how this will change in the upcoming Prague/Electra hardfork (specifically, based on EIPs 7002 and 7251).

In a subsequent article, we will propose various ways to improve the exit queue while preserving the safety properties of Ethereum.

Validatorqueue.com: presents real-time data for the current validator set.
Opitmizing Exit Queues for Proof-of-Stake Blockchains by Neuder, Pai, and Resnick: formalizes the exit queue problem and studies potential improvements.
EIP-7251: EIP to increase the MAX_EFFECTIVE_BALANCE of validators. Discussed in detail below.
EIP-7002: EIP to allow execution layer-triggered partial withdrawals. Discussed below.
Beacon Chain Specs: the Prague/Electra consensus specification.
Validator consolidation in EIP-7251: explains the details of the consolidation mechanism.
Electra Effective Balance: descriptions and worked examples for EIP-7251.

Section 1 – How exits work today

We first present the validator exit flow as it exists today to help contextualize the changes under the upcoming Prague/Electra hardfork.

1.1 – Terminology

Validator exit – A validator exit is a process by which a validator signals intent to leave the consensus set and reclaim their staked ETH. Validator exits can be voluntary or forced (if the validator is slashed). For this document, we focus on the voluntary exit flow.
Full withdrawal – A full withdrawal occurs as part of a validator exit. The entire principal of 32 ETH and any remaining consensus rewards are withdrawn and sent to a validator-defined address.
Partial withdrawal – A partial withdrawal removes some ETH from the validator without removing them from the consensus set. Partial withdrawals do not allow the validator balance to fall below the minimum 32 ETH threshold. Partial withdrawals are automated as of today (pre-Prague/Electra).
Withdrawal credential – An execution layer address (can be either an EOA or a contract) that serves as the destination for withdrawn ETH from the consensus layer (both partial and full withdrawals are sent to the same withdrawal credential).
Active validator – An active validator is part of the consensus protocol and is expected to continue proposing and attesting to blocks. Active validators earn consensus rewards.
Slashable validator – A slashable validator has ETH that is still subject to the standard slashing rules of the protocol, regardless of whether they are active or inactive (no longer in the consensus set).

1.2 - The exit process

We describe how exits and withdrawals are processed in the Ethereum protocol as of March 2025, before the Prague/Electra (abbr. Pectra) hardfork. The image below demonstrates the three stages of a voluntary validator exit. Each phase is detailed below.

Image Not Showing Possible Reasons

The image was uploaded to a note which you don't have access to
The note which the image was originally uploaded to has been deleted

Learn More →

Phase 1: Exit queue: When a validator initiates a voluntary exit, the protocol calculates the exit_epoch (when the validator is officially removed from the active consensus set) based on a rate-limited FIFO exit queue. If the queue is empty, the exit could occur as early as five epochs in the future (see compute_activation_exit_epoch), but if the queue has many pending exits, the newly exiting validator may have to wait. The "churn" limit is calculated to determine how many validators can exit in a given epoch as
$max (8, ⌊ # validators / 2^{16} ⌋)$ (see get_validator_activation_churn_limit); as of March 2025, this corresponds to
$⌊ 1, 051, 723 / 2^{16} ⌋ = 16$ exits per epoch (e.g., if there are 160 validators in the queue, a newly enqueued validator will be exited 10 epochs, about an hour, later). In this phase, exiting validators are still active (participating in consensus) and slashable (accountable for equivocations).
Phase 2: Withdrawalability delay: Once the validator's exit_epoch has passed, a fixed-length delay of 256 epochs (27 hours) (see MIN_VALIDATOR_WITHDRAWABILITY_DELAY) is used to calculate their withdrawable_epoch (at which point the validator is no longer slashable). This fixed delay is a safety buffer to provide ample time for the protocol to include any slashing proof onchain, even if the exit queue is empty. During this time, the validator is no longer active (to prevent them from committing a slashing violation immediately before the withdrawal), but they remain slashable for any prior signatures.
Phase 3: Validator sweep: Once the validator's withdrawable_epoch is past, they are no longer slashable, and their ETH is ready to be sent to the address specified in their withdrawal credential. These full withdrawals are processed sequentially with partial withdrawals (see get_expected_withdrawals), which significantly increases their latency. All withdrawals are processed by iterating through the validator set in order of validator index. As of today, all validators with a balance over 32 ETH have an automatic partial withdrawal created on their behalf.^[1] Since this validator "sweep" can only process 16 withdrawals per block (see MAX_WITHDRAWALS_PER_PAYLOAD), this corresponds to a 9.1-day^[2] cycle through the entire validator set (thus an average 4.55-day additional delay to a full withdrawal).

The minimum time to exit the system is 27 hours (if the exit queue is empty and the validator index is timed correctly with the sweep). If the validator doesn't strategically time their exit request, the withdrawal will take about 5.7 days on average to fully clear, even if the exit queue is empty.

1.3 – Aside: Why have an exit queue?

The exit queue ensures the economic security of transactions finalized by the validator set. Suppose a malicious validator could immediately exit the set without any delay. In that case, they may attempt to execute a double spend attack by publishing a block while withholding a conflicting block, which they release after their stake has exited the protocol. In this case, the slashing mechanism can no longer hold the malicious validator accountable, and two conflicting finalized transactions may exist (if the attacker has

1 / 3

of the total stake and successfully splits the

2 / 3

honest majority in half).

Observation: Economic security decreases over time! A strange artifact about staking with dynamic validator sets is that the economic security of a finalized transaction decreases over time. Once a transaction is finalized,
$1 / 3$ of the validator set will be slashable if a conflicting finalized block is immediately detected. However, some validators who double-signed on both conflicting blocks can exit the system as time passes. The validators that exit and withdraw their ETH are no longer slashable; thus, the
$1 / 3$ stake is not fully accountable. Ethereum recognizes this by specifying a "weak subjectivity period" to limit the fraction of the validator set that can exit within a fixed amount of time. Of course, as time passes, the canonical chain becomes harder to reorg (because the fork-choice rule dictates the chain with the highest number of votes becomes canonical), giving higher settlement assurances to finalized transactions despite the raw economic security of their finality decreasing.

The CHURN_LIMIT_QUOTIENT

= 2^{16}

was selected according to the rough heuristic that it should take approximately one month for

10 %

of the stake to exit^[3] (or equivalently three months for

1 / 3

of the stake to exit). We can interpret this as "the economic security of a finalized transaction decreases by no more than
$10 %$ within one month."

To reiterate: given any withdrawal rate, a transaction's economic security decreases over time! This (somewhat counter-intuitive) fact implies that the protocol must trade-off between quicker validator exits (which are more convenient) and slower validator exits (which provide better accountable safety guarantees). See "Optimizing Exit Queues" for more context and related work on this topic.

Section 2 – What changes in the Pectra hardfork

tl;dr; very little.

The exit queue (Phase 1 above) is rate-limited to 256 ETH per epoch (equivalent to eight 32 ETH validators).
Validator consolidations (defined below) are rate-limited depending on the total staked ETH; at one million 32 ETH validators (approximately where we are today), 232 ETH of consolidations can be processed per epoch.
Pending execution-layer (abbr. EL) triggered partial withdrawals are processed in each block before incrementing the validator sweep (Phase 3 above). These EL partial withdrawals are rate-limited as part of the exit queue churn.
Validators can opt out of the validator sweep (Phase 3 above), choosing instead to compound their stake by reinvesting their consensus rewards into their validator balance. Validators signal this to the protocol by updating their withdrawal credential to have a 0x02 prefix – see COMPOUNDING_WITHDRAWAL_PREFIX. This may shorten the sweep duration as fewer automatic partial withdrawals are triggered.

Points 1 & 2 above are detailed in 2.2; points 3 & 4 are expanded in 2.3.

2.1 – New terminology

Increasing the MAX_EFFECTIVE_BALANCE (MaxEB) - The Pectra hardfork includes EIP-7251, which enables validator balances to be in the range
$[32, 2048]$ ETH (rather than being capped at 32 ETH exactly). See "a modest proposal" for more context on the motivation of this EIP.
Consolidation – EIP-7251 also allows for entities that control multiple validators to consolidate their balances directly (as opposed to triggering a validator exit for some of their validators and then depositing in others) (see "Validator consolidation in EIP-7251" for documentation on this process). This avoids the potential inefficiency of extensive periods where the validators' ETH is inactive and not earning rewards.
Execution layer triggered exits/partial withdrawals – EIP-7002 allows validators to trigger exits/partial withdrawals directly from the execution layer. A validator has two identities – a validating key (used for consensus duties) and a withdrawal credential (specifying the address to which withdrawals are sent).^[4] Until now, only the validating key could trigger an exit by sending a consensus-layer message. With this EIP, both withdrawals and exits can be triggered by the EOA or contract specified in the withdrawal credential.
Compounding validator credential – Previously, validators were limited to exactly 32 ETH. All consensus rewards earned were automatically withdrawn to the user's specified withdrawal credential during the validator sweep (Phase 3 above). With EIP-7251 allowing validators to have a higher balance, they can now choose to mark themselves as "compounding" (see switch_to_compounding_validator) meaning their balance is not automatically removed during the validator sweep. The automatic partial withdrawals only kick in when the validator's effective balance reaches the new maximum of 2048 ETH.

2.2 – Exit queue churn limit changes

Previously, with each validator having exactly 32 ETH, the churn limit (i.e., the rate of change of the validator set) was denominated in "number of validators" (e.g., 16 validator exits per epoch). This no longer works with validators that have heterogeneous balances. Thus, the churn calculation must be denominated in ETH terms – see get_balance_churn_limit, which defines the limit as

⌊ ETH staked / 2^{16} ⌋

. With one million 32 ETH validators,

⌊ 32, 000, 000 / 2^{16} ⌋ = 488

ETH can cycle out per epoch. This churnable ETH is divided into two parts.

Exits – Voluntary exits can be triggered either through the consensus layer or the execution layer. These exits can consume at most 256 ETH of the total churn limit (see MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT).
Consolidations – Consolidations provide an in-protocol feature to merge multiple validators without fully exiting the consensus mechanism. This aims to reduce friction, allowing large staking pools to combine many 32 ETH validators into fewer with higher balances. The consolidations consume a portion of the total allowable churned ETH per epoch. In particular, they consume any balance from get_balance_churn_limit that is not used by exits (see get_consolidation_churn_limit). Using the one million validator example above, we have a maximum of
$488 - 256 = 232$ ETH of churn consumed by consolidations per epoch.

Aside: Why do we need to rate limit consolidations? Consider the following scenario: Validator A & Validator B each have 2000 ETH. Let Validator B consolidate into Validator A. Now Validator A has 4000 ETH, which exceeds the new MAX_EFFECTIVE_BALANCE of 2048 ETH. The validator sweep detects this and removes 1952 ETH as an automatic partial withdrawal. These partial withdrawals are not rate-limited (historically, that stake was inactive); thus, the 1952 ETH just bypassed the exit queue. The process of rate-limiting consolidations as part of the overall validator set churn is necessary to preserve accountable safety.

Aside: Consolidations are a temporary band-aid. In a steady state, there is no reason a staking pool would deposit ETH into a new validator only to consolidate it into a different one. Instead, they would deposit directly into existing validators with
$> 32$ ETH balances. The in-protocol consolidation mechanism is only a stop-gap to speed up the process of reducing the validator set size (denominated in the number of validators). Removing the consolidation mechanism in the future may reduce tech debt and simplify the specification.

2.3 – Validator sweep changes

Today, any validator balance above 32 ETH is automatically withdrawn as part of the validator sweep (Phase 3 above). These automated withdrawals are processed in the same queue as full withdrawals by iterating linearly through the validator indices and checking whether each validator is fully or partially withdrawable. Recall there are currently 16 withdrawals per block (see MAX_WITHDRAWALS_PER_PAYLOAD). In Pectra, non-automated partial withdrawals can be initiated by sending an execution layer request from the validator withdrawal credential. A maximum of eight EL partial withdrawals are processed per block (see MAX_PENDING_PARTIALS_PER_WITHDRAWALS_SWEEP), while the remaining eight withdrawals are filled with the validator sweep (whether automatic partials or full withdrawals) (see get_expected_withdrawals).

Note that the above doesn't slow down the validator sweep, as each validator can have an EL or automated partial withdrawal, but not both. Validators signal if they want the normal 32 ETH hard cap with automatic withdrawals or if they prefer to stop the automatic withdrawals by updating to a "compounding" withdrawal credential. They choose between:

Continuing with automatic withdrawals above 32 ETH – This maintains today's behavior.
Opting-in to compounding rewards – This allows validators to reinvest their rewards into their validator effective balance and increase their stake above 32 ETH. The automatic partial withdrawals resume only when a validator balance of 2048 ETH is reached.

The compounding credentials are relevant for the exit procedure as they may change the length of the validator sweep. Suppose many validators switch to compounding withdrawal credentials. In that case, they effectively opt out of the validator sweep (Phase 3 above) (they are skipped until they reach 2048 ETH) and thus do not count against the maximum of 16 withdrawals processed per block.

–
thanks for reading ❦

This is slightly inaccurate; if validators have not specified a withdrawal credential, they are skipped in the sweep. Since this is a tiny fraction of the validators (those who have not opted into receiving any withdrawals since Capella in April 2023), we ignore it for the context of this article. ↩︎
$16$ per-slot
$⟹ 80$ per-minute
$⟹ 4800$ per-hour
$⟹ 115, 200$ per-day. With
$1, 053, 742$ validators, we arrive at
$\approx 9.1$ days. ↩︎
With
$1, 053, 742$ validators, we have a churn limit of
$16$ exits per epoch.
$225$ epochs per day
$⟹ 3600$ exits per day
$⟹ 108, 000$ exits per 30 days. Then
$108, 000 / 1, 053, 742 \approx 0.10$ . ↩︎
In cases of institutional staking/Staking-as-a-Service, the entity providing the principal (or their custodian) held the withdrawal credential, while the service provider only held the validator key (used to sign consensus messages). In such arrangements, the possessor of the withdrawal credentials cannot independently choose to exit and begin the withdrawal process, leading to insecure workarounds such as pre-signed exits. These workarounds will no longer be needed as exits can be triggered directly from the execution layer. ↩︎