An Ethereum validator exit removes the validator from the active set at its scheduled exit epoch. A full withdrawal transfers the remaining balance to its withdrawal address once the withdrawable epoch is reached and a sweep includes it. An accepted exit request, an exited validator and spendable ETH are different states. Track each state separately instead of treating an exit queue estimate as a payout deadline.
Read the lifecycle as separate evidence
The native validator balance lives in Ethereum's consensus accounting. The withdrawal address receives ETH in execution-layer accounting. An exit changes the validator's participation status; the later withdrawal moves the balance between those systems. A staking provider can add its own processing before or after this native lifecycle.
Keep a ledger with these observations:
| Stage | Evidence to save | What remains unresolved |
|---|---|---|
| Request submitted | Signed exit message or execution transaction reference | Whether consensus accepted an eligible request |
| Exit scheduled | Validator record with a finite exit epoch | The validator is still active before that epoch |
| Exited | Observed epoch has reached the exit epoch | Withdrawability and payout |
| Withdrawable | Recorded withdrawable epoch reached, with suitable credentials and a positive balance | Inclusion in a withdrawal sweep |
| Withdrawal included | Withdrawal record names the validator, address and amount | Settlement evidence and any provider's accounting |
The consensus active-validator predicate uses the exit epoch as the boundary: a validator remains active while the current epoch is below it. Sending a request does not end duties. Keep the operator's service running through the active period and verify the on-chain boundary.
Before shutting down, also check existing sync-committee assignments. These committees are selected in advance and persist for their assigned period; exit does not rewrite their membership. The Altair validator rules require participation throughout an assigned period. An active-set exit therefore need not end every already assigned duty immediately.
The queue before exit is a rate limit on changing the active stake, not a payment service. EIP-7251 changes exit rate limiting to use balance rather than a count of identical validators. With variable validator sizes, “this many validators ahead” is insufficient to calculate an individual wait. Use the assigned exit epoch once it is available, and retain the observation time behind any estimate made earlier.
This article follows Ethereum mainnet's withdrawal mechanics introduced by Capella and modified by Electra, including execution-triggered requests and compounding credentials. It does not present a live queue reading or a fixed current exit duration.
Confirm that the request became an exit
There are two relevant authorization routes. An operator can submit a voluntary exit signed with the validator's signing key. EIP-7002 also enables execution-layer withdrawal credentials to trigger an exit, allowing the withdrawal-address controller to act without depending on the operator's hot signing key. That route has a request transaction, gas and a separate protocol request fee.
The EIP-7002 contract has its own message queue before requests reach consensus processing. Its queue is different from the stake exit queue and the later payout sweep. A transaction being included successfully proves that an execution-layer action occurred; it does not by itself prove the validator now has an assigned exit epoch.
The Electra request-processing rules check the validator, withdrawal credentials, source address and eligibility. A request can be ignored when those checks fail. A full exit can also be blocked by that validator's pending partial withdrawals. Inspect the validator record after processing rather than diagnosing every unchanged status as congestion.
Record which key or address authorized the request and which validator public key it targets. Several validators can share one withdrawal address; an address alone does not identify the validator that was asked to exit. Do not put signing keys or seed phrases in the ledger. It needs public identifiers and accepted state, not signing secrets.
A provider's “unstake requested” status may precede any native validator request. Selling a liquid staking token takes a different route again. The liquid staking token discount guide compares a market sale with provider redemption; a sale is not evidence that the backing validator has exited.
Follow a hypothetical 281-epoch exit
Consider an invented unslashed validator with 0x01 execution withdrawal credentials and no outstanding sync-committee assignment. Assume an eligible exit has been accepted at the start of epoch 1,000,000, the assigned exit epoch is 1,000,020, and a full sweep reaches it at the start of epoch 1,000,281. These are constructed observations, not current mainnet estimates or a forecast of how quickly a new request will complete.
The inspected mainnet configuration sets slot duration to 12 seconds and the minimum validator withdrawability delay to 256 epochs. The mainnet preset sets 32 slots per epoch. One epoch therefore spans 384 seconds, or 6 minutes 24 seconds.
Under the unslashed exit rule, the Electra exit function assigns the withdrawable epoch as the exit epoch plus that delay. Here, 1,000,020 + 256 = 1,000,276.
| Hypothetical observation | Epoch | Elapsed from accepted request | Interpretation |
|---|---|---|---|
| Eligible request accepted | 1,000,000 | 0 | Exit scheduled; duties continue |
| Exit boundary reached | 1,000,020 | 2 hours 8 minutes | Active-set membership ends |
| Withdrawable boundary reached | 1,000,276 | 29 hours 26 minutes 24 seconds | Full balance eligible for sweep |
| Full withdrawal included | 1,000,281 | 29 hours 58 minutes 24 seconds | Execution address receives the recorded amount |
The waiting components are 20 epochs before exit, 256 epochs from exit to withdrawability, and five epochs from eligibility to the assumed sweep. Their sum is 281 epochs. Multiplying 281 by 384 gives 107,904 seconds: 29 hours 58 minutes 24 seconds. The fixed 256-epoch component alone is 98,304 seconds, or 27 hours 18 minutes 24 seconds.
At epoch 1,000,275, this validator has already exited but is not yet withdrawable. At epoch 1,000,276, the eligibility boundary has been crossed but no payout has occurred in the constructed path. Those two observations explain why an “exited” or “withdrawable” label can coexist with an unchanged wallet balance.
Suppose the validator balance immediately before the modeled full withdrawal is 32.0800 ETH, and the withdrawal wallet contains 1.5000 ETH. Assume no other wallet activity. The withdrawal adds 32.0800 ETH, producing 33.5800 ETH in the wallet. This is an accounting reconciliation, not a reward forecast. A balance recorded when the request was created could differ because of later rewards, penalties or earlier partial payouts.
Do not add 32.0800 ETH to a portfolio's validator balance and also count it as wallet ETH after the transfer. Reconcile the decrease on one side and the increase on the other. The effective versus total validator balance guide explains why the balance used for consensus weight and the amount remaining to withdraw need separate fields.
Eligibility does not reserve an immediate payout
The sweep visits validator indexes in sequence, carrying its position forward between blocks. The Capella sweep specification bounds both the accounts examined and the withdrawal records emitted. It pays the remaining balance when a fully withdrawable validator is encountered. The Electra update also processes eligible pending partial withdrawals before the index sweep.
Consequently, reaching an eligibility epoch does not mean receiving a reserved place in the very next block. An estimate needs the sweep's position and current processing conditions. Simply dividing a total validator count by a headline payout rate cannot establish the particular validator's receipt time. A missed block can also leave no withdrawal payload to advance processing in that slot.
The actual payout is a system operation. EIP-4895 increases the specified recipient's balance without charging gas for that withdrawal operation. It is not an ordinary user transfer requiring a new claim transaction. The earlier EIP-7002 request can still have costs; “gasless payout” does not mean “costless request.”
For reconciliation, save the withdrawal index, validator index, recipient, amount and containing block. EIP-4895 expresses withdrawal amounts in Gwei, so convert units before comparing them with an ETH wallet display. A wallet's normal transaction list may not be the best place to find this system record. Then check the containing block's settlement evidence; the confirmations versus finality guide explains that separate check.
Credential type and slashing change the diagnosis
A partial payout does not prove a full exit. Ethereum's withdrawal-credential documentation distinguishes 0x01 credentials, which support automatic excess withdrawals above the 32 ETH threshold, from 0x02 compounding credentials, whose automatic excess threshold is 2,048 ETH and which support requested partial withdrawals. The automatic mechanism also has effective-balance eligibility conditions. An active validator can therefore send ETH to its withdrawal address without leaving the active set.
Both execution credential types support full exits. A 0x00 credential has no execution withdrawal address, so exiting alone does not supply a payout destination; the credential change must be handled through the documented process. Check the actual prefix before concluding that a quiet wallet means the sweep failed.
Slashing is another boundary. Ending active duties does not immediately erase exposure to evidence of slashable conduct. For a validator not already slashed, the slashable-validator predicate remains true before its withdrawable epoch; it becomes false at that epoch. Slashing before that boundary can extend the withdrawable epoch. The ordinary 256-epoch illustration above is for an unslashed exit. If the validator is slashed, inspect its recorded withdrawable epoch and balance rather than reusing that illustration's deadline or amount.
For restaked positions, native Ethereum withdrawal evidence may still leave another system's release condition unresolved. The restaking versus staking guide addresses that additional layer. Record it separately so a provider's pending claim is not confused with native ETH already received.
Find the first unmet stage
Use one dated record per validator. Start with network, validator index and public key, credential prefix, withdrawal address, request route and request reference. Add the observed chain head, exit epoch, withdrawable epoch, slashed flag and current balance. Refresh these fields from a consistent chain view before acting on an old estimate.
Then make the next action depend on evidence:
- No assigned exit epoch: check whether the request reached consensus processing and met eligibility requirements. Separate a provider's internal request from a native request.
- Current epoch below exit epoch: continue the required validator operation and monitor the assigned boundary. Do not shut down because a front end says “unstaking.”
- Exited but below withdrawable epoch: record the remaining epoch difference, with the slashing status attached. This is not a sweep problem yet.
- Withdrawable but no payout record: check execution credentials and sweep progress. Keep the payout time unresolved until a containing block is observed.
- Payout recorded: reconcile the exact address and units, verify settlement, and then investigate any remaining provider or wallet-display discrepancy.
The useful status is a complete statement: this validator has reached this epoch boundary, the next required event is this one, and this public record will prove it happened. That is more actionable than a single “unstaking time” counter.