Skip to main content
Ethereum never lets stake enter or leave all at once. Every deposit, exit, partial withdrawal and consolidation waits its turn, so the validator set changes slowly and predictably. This page explains each step in plain terms: what you are waiting for, how long it takes, and where to see it.

See the queues live

Current wait times, history charts, and which staking entities are in each queue.

Track them with the API

Every number on this page is available from the beaconcha.in API, for the whole network and for your own validators.

​
The big picture

Flow from deposit to payout: deposits and top-ups go through the deposit queue to an active validator; full exits and partial withdrawal requests share the exit queue, consolidations use their own queue, all three then wait the 256-epoch withdrawability delay; the withdrawal sweep pays full exits and automatic withdrawals, partial withdrawals are paid in the next blocks, and consolidated balances move to the target validator.Flow from deposit to payout: deposits and top-ups go through the deposit queue to an active validator; full exits and partial withdrawal requests share the exit queue, consolidations use their own queue, all three then wait the 256-epoch withdrawability delay; the withdrawal sweep pays full exits and automatic withdrawals, partial withdrawals are paid in the next blocks, and consolidated balances move to the target validator.

From deposit to payout. Click the diagram to zoom in.

Three ideas explain almost everything on this page:
  1. Churn is a speed limit, measured in ETH per epoch. One epoch is 6.4 minutes, so 225 epochs make a day. The deposit queue and the exit queue each let through 256 ETH per epoch, which is 57,600 ETH per day. Consolidations have their own, separate limit.
  2. Your place is fixed when your request is processed. The chain books the epoch your exit (or partial withdrawal, or consolidation) takes effect at the moment it processes the request. Later requests queue behind you.
  3. After the queue comes a fixed delay. ETH that leaves through the exit or consolidation queue waits another 256 epochs (about 27 hours) before it can move. This delay does not depend on the queue. The only exception is a slashed validator, which waits at least 8,192 epochs (about 36 days).

​
How long will it take?

Each journey is a variable wait (the queue) plus fixed delays. The last column names the API field that gives you the live value. All fields come from the Network Queue Overview. For your own validators, the Validator Queue ETA endpoint returns the same queues with each validator’s own estimate. You can select validators by index, public key or dashboard, and by public key even before a new validator has an index. On Scale and Enterprise plans you can also select a whole fleet by withdrawal credential, deposit address or staking entity. The Estimate Queue Wait Times guide walks through both endpoints with examples.

​
The deposit queue

Every deposit goes through the deposit queue: new validators and top-ups of existing ones alike.
  1. You send a deposit of at least 1 ETH to the deposit contract, with any withdrawal credential type (0x00, 0x01 or 0x02). Since the Pectra upgrade the beacon chain sees the deposit in the same block, so there is no longer a delay of several hours before it is queued.
  2. The deposit waits until its block is finalized, usually 15 to 20 minutes.
  3. The queue is processed once per epoch, oldest deposit first. Each epoch adds 256 ETH of room and processes at most 16 deposits, whichever limit is reached first. Many small deposits therefore move more slowly than a few large ones. When the next deposit does not fit, the unused room carries over to the next epoch, so a deposit larger than 256 ETH, such as a 2048 ETH top-up, goes through after a few epochs.
  4. A new validator is created when its first deposit is processed. Its deposit signature is checked at this point. A deposit with an invalid signature (for example, one signed for a testnet) is dropped and never creates a validator.
  5. The validator activates once its effective balance reaches 32 ETH. It becomes eligible in the next epoch. Once that epoch is finalized, activation is scheduled 5 epochs ahead, so with normal finality the validator is active about 8 epochs (50 minutes) after its deposit was processed.
Top-ups and effective balance. A top-up raises the balance right away, but the effective balance, which counts for activation and rewards, only changes once the balance is more than 1.25 ETH above it. It then jumps to the balance rounded down to whole ETH, up to the maximum. For example, 31 ETH effective balance plus a 1 ETH top-up gives a 32 ETH balance, but the effective balance stays at 31 ETH. A 0x02 validator at 32 ETH that tops up 10 ETH goes straight to 42 ETH.
A deposit to a validator that is already exiting does not use the 256 ETH limit. It is moved to the back of the queue each epoch until the validator is withdrawable, and is then paid out by the sweep. Each time it is moved, it still uses one of the 16 deposit slots of that epoch.
API: deposit_queue in the Network Queue Overview splits the queue into new validators (deposit_count, deposit_balance) and top-ups (topup_count, topup_balance). Its estimated_processed_at simulates the protocol rules above, including the 16-deposit limit, but treats every deposit as already finalized: for a deposit made in the last few minutes, add the wait for finality. To look up individual deposits, use Deposit Slots for your validators or Deposits for one slot.

​
The exit queue

The exit queue lets up to 256 ETH of stake leave per epoch. Everything that takes ETH out of staking shares it:
  • Voluntary exits signed with the validator key (free).
  • Full exit requests sent from the withdrawal address on the execution layer (EIP-7002, 0x01 and 0x02 credentials, costs a small fee).
  • Partial withdrawal requests sent from the withdrawal address (EIP-7002, 0x02 credentials only, costs a small fee). See Partial withdrawal requests.
  • Forced exits: validators whose effective balance falls to 16 ETH, and slashed validators.
Consolidations do not use the exit queue. They have their own.

​
How your exit epoch is set

When the chain processes your exit, it books the first epoch that still has room under the 256 ETH limit, counting your validator’s effective balance, and never earlier than 5 epochs (about 32 minutes) from now. An exit larger than the room left also uses the room of the next epochs, and its exit epoch is the last of them: a 2048 ETH 0x02 validator uses the room of about 8 epochs. Your exit epoch does not change afterwards. So a new exit lands on the latest exit epoch the chain has already booked, for anyone, or a little after it when the room left is smaller than the exit.
Why “ETH waiting to exit ÷ 256” gives the wrong wait. Some sites estimate the exit wait by dividing the ETH of exiting validators by 256 ETH per epoch. That can be wrong in both directions:
  • Too short: partial withdrawal requests use the same 256 ETH per epoch, but they are not exiting validators, so they are not in the exiting ETH.
  • Too long: consolidation sources show as “exiting” but use the separate consolidation limit, not the exit queue.
  • Slightly off: the queue counts effective balance, not balance.
exit_queue.estimated_processed_at avoids all three: it reads the latest exit epoch the chain has booked, for validator exits and partial withdrawal requests alike.

​
Rules worth knowing

  • A validator must have been active for 256 epochs (about 27 hours) before it can exit, request a partial withdrawal or be a consolidation source.
  • Keep your validator online until its exit epoch. It still has duties and earns rewards or penalties until then.
  • A validator with partial withdrawals queued cannot exit. Both a full exit request from the execution layer and a voluntary exit are rejected until all its queued partial withdrawals are paid.
  • After the exit epoch comes the withdrawability delay: 256 epochs (about 27 hours), then the withdrawal sweep pays out the balance. For a slashed validator the delay is at least 8,192 epochs (about 36 days) from the slashing.
API: exit_queue.estimated_processed_at in the Network Queue Overview is where a new exit joins the queue right now; a large exit can land a few epochs later. exit_queue.count and exit_queue.balance count the validators waiting for the exit epoch the exit queue gave them, at their current balance. Consolidation sources are in consolidation_queue and partial withdrawal requests are in manual_withdrawal_queue. Partial withdrawal requests take the same 256 ETH per epoch, so do not divide exit_queue.balance by 256 to get the wait: use estimated_processed_at. For your own validators, the Validator Queue ETA endpoint returns each validator’s exit epoch, and Staking Queues History shows how the wait has moved over time.

​
Partial withdrawal requests

A validator with 0x02 (compounding) credentials can withdraw part of its balance and stay active. You send the request from the withdrawal address; the amount can never take the balance below 32 ETH. Each request goes through two phases, then the payout:
  1. Phase 1: the requested amount takes its place in the exit queue, exactly like an exit. This is why partial withdrawals make exits slower.
  2. Phase 2: once its exit epoch has passed, the request no longer holds up anyone in the exit queue, but it waits another 256 epochs before it can be paid.
  3. Payout: requests that are due are paid first in each block, up to 8 per block, before the withdrawal sweep. They do not wait for the sweep to come around. If the validator is slashed before then, its queued requests are dropped, and the sweep pays out the whole balance after the slashing delay.
API: manual_withdrawal_queue in the Network Queue Overview counts every queued request in both phases, and its estimated_processed_at is when the last of them will be paid. Because requests in phase 2 no longer use the exit queue, manual_withdrawal_queue.balance is not all ahead of a new exit; exit_queue.estimated_processed_at already accounts for the part that is. The Validator Queue ETA endpoint gives each validator’s own estimate.

​
Before the queue: request contracts and fees

Exit requests, partial withdrawal requests and consolidation requests sent from the execution layer pass through a system contract first, which forwards a limited number per block: If more requests arrive than that, they wait in the contract and are forwarded in later blocks. The fee starts at 1 wei and rises exponentially while more than 2 withdrawal requests (or 1 consolidation request) per block are submitted, then falls back once demand drops. Voluntary exits signed with the validator key and deposits do not pay this fee.
API: Request Fees (Current) returns the fee for the next block, and Request Fees its history per block. Check it before you submit a request so you do not overpay during a spike.

​
The consolidation queue

A consolidation moves the balance of one validator (the source) into another (the target), so you run fewer validators for the same stake. The target needs 0x02 credentials, both must be active, and the source must have been active for 256 epochs and have no partial withdrawals queued.
  • Its own speed limit. Consolidations do not use the exit queue. Their limit is whatever the network’s total churn leaves after the 256 ETH of the exit queue: the total active stake divided by 65,536, minus 256 ETH. It grows as more ETH is staked.
  • The source exits right away. When the request is processed, the source gets its exit epoch from the consolidation queue, so it shows as “exiting” from then on.
  • The balance moves 256 epochs later. Once the source is withdrawable, its balance up to its effective balance moves to the target, which stays active throughout. Anything above that is paid to the source’s withdrawal address by the withdrawal sweep. If the source is slashed before then, the consolidation is skipped: the balance stays with the source, and the sweep pays it out after the slashing delay (at least 8,192 epochs).
Switching to compounding uses the same request with the same validator as source and target. It does not use the consolidation queue: the credentials change to 0x02 as soon as the request reaches the beacon chain. It only waits in the EIP-7251 request contract, which forwards up to 2 requests per block (see request contracts and fees). Any balance above 32 ETH goes back through the deposit queue, which is why you may see a system deposit and withdrawal on that validator.
API: consolidation_queue in the Network Queue Overview returns the current consolidation limit (churn), when the last queued source exits (estimated_exit_at) and when its balance moves (estimated_processed_at). compounding_switch_queue counts pending switches and estimates when the request contract’s backlog is cleared. Per validator, use Validator Queue Consolidation Details and Validator Queue Compounding Switch Details. Consolidations lists the consolidations processed in a slot.

​
The withdrawal sweep

The sweep is not a queue but a pointer that moves through all validators in index order, again and again. Each block pays at most 16 withdrawals in total: first any partial withdrawal requests that are due (up to 8), then the sweep fills the rest, checking up to 16,384 validators per block. When it reaches your validator, it pays:
  • The full balance if the validator is withdrawable (exited, and the withdrawability delay has passed).
  • The excess above the maximum effective balance once the effective balance has reached that maximum: anything above 32 ETH for 0x01 credentials, or above 2048 ETH for 0x02 credentials. A 0x01 validator whose effective balance is below 32 ETH gets nothing skimmed. Below 2048 ETH, a 0x02 validator uses a partial withdrawal request instead.
How long you wait depends on how far the pointer is from your validator, at most one full cycle. Validators with 0x00 credentials are skipped: they receive nothing until their credentials are changed to 0x01.
API: withdrawal_sweep.estimated_sweep_delay in the Network Queue Overview is how long a full cycle currently takes, and last_swept_validator_index is where the pointer is. The Validator Queue ETA endpoint estimates when the sweep reaches each of your validators, and Withdrawal Slots lists the withdrawals they received. Withdrawals lists every withdrawal paid in a slot. See How withdrawals work for the payout itself.

​
Validator statuses on beaconcha.in

The validator page shows a status label and a timeline with five steps: Deposited, Pending, Active, Exited and Withdrawn. This is what each stage looks like:

​
Deposited

The deposit is on chain. The Deposited step turns green once the deposit has reached the beacon chain’s deposit queue. Until beaconcha.in has seen a deposit for the public key, the page shows “Validator not found”. A red ✗ on the Deposited step means the deposit’s signature is invalid, often because it was signed for another network. The deposit is dropped when it reaches the front of the deposit queue and no validator is created. The status label still reads Deposited.

​
Pending

The Pending step has two phases, named under it:
  • Deposit queue: the deposit is waiting in the deposit queue. The page shows the epoch it is expected to be processed.
  • Activation queue: the deposit has been processed and the validator has at least 32 ETH effective balance. It is waiting for its activation epoch, usually about 50 minutes. Start your validator client now so it is ready when the countdown ends.

​
Active

The validator attests every epoch, may be chosen to propose blocks or join a sync committee, and earns rewards. A green dot means it is online. A red dot means offline: none of its attestations from the last two epochs were included on chain, so it is missing rewards and paying small penalties. The same dot appears on the Exiting and Slashing statuses.

​
Exiting

An exit has been booked and the validator is waiting for its exit epoch in the exit queue. It must keep performing its duties until then. A consolidation source shows as Exiting too, waiting in the consolidation queue; its page shows when the consolidation completes, and the Consolidations tab names the target.

​
Slashing

The validator broke a protocol rule, for example by signing two conflicting blocks, and was slashed. It loses part of its stake and is forced out through the exit queue. Until its exit epoch it still has duties, so keep it online.

​
Exited

The validator has left the active set and gets no new duties (in rare cases it still finishes a sync committee period). It still holds its balance: exiting and withdrawing are two separate steps. A validator with 0x00 credentials stays Exited until its credentials are changed to 0x01, because the sweep cannot pay it.

​
Withdrawing

The validator has exited, has 0x01 or 0x02 credentials and still holds a balance. This covers the withdrawability delay of 256 epochs (about 27 hours) and the wait for the withdrawal sweep. The page shows the withdrawable epoch and an estimate of when the sweep pays out.

​
Withdrawn

The sweep has paid out the balance and the validator’s lifecycle is complete.

​
Slashed

A slashed validator that has exited shows as Slashed, then Slashed [Withdrawing] and Slashed [Withdrawn]. Its balance becomes withdrawable at least 8,192 epochs (about 36 days) after the slashing, much later than after a normal exit.
API: the Validator endpoint returns each validator’s status, whether it is slashed and whether it is online, so you can follow a whole fleet through these steps, for example to alert when a validator goes offline or becomes active. It uses the standard beacon node status names: pending_initialized and pending_queued for Pending, active_ongoing, active_exiting and active_slashed for Active, Exiting and Slashing, exited_unslashed and exited_slashed for Exited and Slashed, and withdrawal_possible and withdrawal_done for Withdrawing and Withdrawn. Validator Statuses counts the validators of the whole network in each status.