# ELI5: Ethereum Validator Exits
^{^{^for a relatively crypto-native five-year-old...}}

by [mike neuder](https://x.com/mikeneuder) & [mallesh pai](https://x.com/malleshpai) – *march 17, 2025* 🍀🇮🇪☘️

*many thanks to [Paul Harris](https://github.com/rolfyone), [Mikhail Kalinin](https://x.com/mkalinin2), [Lucas Saldanha](https://x.com/lucascrsaldanha), and [Alex Stokes](https://x.com/ralexstokes) for comments and discussions.*

---

### Contents
[`Section 1 – How exits work today`](#Section-1-–-How-exits-work-today)
[`1.1 – Terminology`](#11-–-Terminology)
[`1.2 – The exit process`](#12---The-exit-process)
[`1.3 – Aside: Why have an exit queue?`](#13-–-Aside-Why-have-an-exit-queue)

[`Section 2 – What changes in the Pectra hardfork`](#Section-2-–-What-changes-in-the-Pectra-hardfork)
[`2.1 – New terminology`](#21-–-New-terminology)
[`2.2 – Exit queue churn limit changes`](#22-–-Exit-queue-churn-limit-changes)
[`2.3 – Validator sweep changes`](#23-–-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.

---
### Related Work:

- [Validatorqueue.com](https://www.validatorqueue.com): presents real-time data for the current validator set.
- [Opitmizing Exit Queues for Proof-of-Stake Blockchains by Neuder, Pai, and Resnick](https://arxiv.org/pdf/2406.05124): formalizes the exit queue problem and studies potential improvements.
- [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251): EIP to increase the `MAX_EFFECTIVE_BALANCE` of validators. Discussed in detail below.
- [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002): EIP to allow execution layer-triggered partial withdrawals. Discussed below.
- [Beacon Chain Specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md): the Prague/Electra consensus specification.
- [Validator consolidation in EIP-7251](https://notes.ethereum.org/@fradamt/maxeb-consolidation): explains the details of the consolidation mechanism.
- [Electra Effective Balance](https://hackmd.io/@rolfyone/Hy2sfv7nkl): 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.


1. **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`](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#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, \lfloor \# \text{ validators} / 2^{16} \rfloor)$ ([see `get_validator_activation_churn_limit`](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#get_validator_churn_limit)); as of March 2025, this corresponds to $\lfloor 1,051,723/2^{16} \rfloor=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).
2. **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`](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#time-parameters-1)) 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.
3. **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`](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#new-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.[^3] Since this validator "sweep" can only process 16 withdrawals per block ([see `MAX_WITHDRAWALS_PER_PAYLOAD`](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#execution)), this corresponds to a 9.1-day[^1] cycle through the entire validator set (thus an average 4.55-day additional delay to a full withdrawal).

[^1]: $16$ per-slot $\implies 80$ per-minute $\implies 4800$ per-hour $\implies 115,200$ per-day. With $1,053,742$ validators, we arrive at $\approx 9.1$ days.

[^3]: 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.

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[^4] (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*."

[^4]: With $1,053,742$ validators, we have a churn limit of $16$ exits per epoch. $225$ epochs per day $\implies 3600$ exits per day $\implies 108,000$ exits per 30 days. Then $108,000/1,053,742 \approx 0.10$.

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"](https://arxiv.org/pdf/2406.05124) for more context and related work on this topic.

## Section 2 – What changes in the Pectra hardfork

**tl;dr; very little.**
1. The exit queue (Phase 1 above) is rate-limited to 256 `ETH` per epoch (equivalent to eight 32 `ETH` validators).
2. 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.
3. 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.
4. 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`](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#withdrawal-prefixes). This may shorten the sweep duration as fewer automatic partial withdrawals are triggered.

Points 1 & 2 above are detailed in [2.2](#22-–-Exit-queue-churn-limit-changes); points 3 & 4 are expanded in [2.3](#23-–-Validator-sweep-changes).

### 2.1 – New terminology
> **Increasing the `MAX_EFFECTIVE_BALANCE` (`MaxEB`)** - The Pectra hardfork includes [EIP-7251](https://eips.ethereum.org/EIPS/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"](https://ethresear.ch/t/increase-the-max-effective-balance-a-modest-proposal/15801) 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"](https://notes.ethereum.org/@fradamt/maxeb-consolidation) 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](https://eips.ethereum.org/EIPS/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).[^2] 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`](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#new-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]: 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.

### 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`](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#new-get_balance_churn_limit), which defines the limit as $\lfloor \text{ETH staked}/2^{16} \rfloor$. With one million 32 `ETH` validators, $\lfloor 32,000,000 / 2^{16} \rfloor = 488$ `ETH` can cycle out per epoch. This churnable `ETH` is divided into two parts.
1. **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`](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#validator-cycle)).
2. **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`](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#new-get_balance_churn_limit) that is not used by exits ([see `get_consolidation_churn_limit`](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#new-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`](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#execution)). 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`](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#withdrawals-processing)), while the remaining eight withdrawals are filled with the validator sweep (whether automatic partials or full withdrawals) ([see `get_expected_withdrawals`](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#modified-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:
1. **Continuing with automatic withdrawals above 32 `ETH`** – This maintains today's behavior.
2. **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.

--
<span style="color:red;">*thanks for reading ❦*</span>