Ethereum withdrawal credentials identify how a validator's ETH can be withdrawn and which execution-layer address receives it. The prefix matters: 0x00 is the legacy BLS form, 0x01 uses an execution address with a 32 ETH effective-balance cap, and 0x02 uses an execution address with compounding up to a 2,048 ETH effective-balance cap. Changing the prefix and changing the recipient are different operations.
What 0x00, 0x01 and 0x02 mean
A withdrawal credential is a public 32-byte record in the validator's consensus-layer state. It is not a private key. For execution-address credentials, the encoding is one prefix byte, eleven zero bytes and a twenty-byte address. The final twenty bytes identify the recipient; the prefix identifies the applicable withdrawal rules.
| Type | Recipient and control | Balance treatment |
|---|---|---|
| 0x00: BLS | A hash derived from the BLS withdrawal public key; no execution recipient set | An execution address must be set before ETH can be paid out |
| 0x01: execution | A recorded execution-layer address | Effective balance capped at 32 ETH; eligible excess is automatically swept |
| 0x02: compounding | A recorded execution-layer address | Effective balance can grow to 2,048 ETH; requested partial withdrawals can remove eligible excess |
Effective balance is the protocol's accounting balance for validator duties and rewards. It differs from actual balance. A validator with more than 32 ETH does not automatically earn rewards on all of it under 0x01. Under 0x02, balance above 32 ETH can contribute to effective balance, subject to the protocol's update rules and cap.
The versioned Electra specification defines those caps and the withdrawal eligibility tests. The prefix alone does not tell you whether a validator is active, exiting, slashed or ready for payout.
Which credential changes are possible?
The first transition sets a recipient. The second preserves that recipient while changing balance treatment. Neither arrow represents a payout or an estimate of how long an operation takes.
From 0x00 to 0x01: the Capella specification requires a valid BLS-to-execution change signed with the matching withdrawal key. It checks that the validator still has a BLS credential, then records the chosen execution address. The validator signing key alone cannot authorize this address assignment.
From 0x01 to 0x02: Electra permits a valid same-validator consolidation request to switch to compounding. The conversion retains the existing address bytes. It is not an address editor, and these cited rules do not provide a reverse conversion to 0x01. Balance eligibility and processing remain separate from the credential change.
Can I change the withdrawal address?
Once execution credentials are recorded, the cited credential-change mechanisms do not let you replace their address. This is a narrower statement than saying funds can never move to a different recipient.
Cross-validator consolidation is a separate operation: it can move an eligible source validator's balance into a different, eligible compounding target. The target has its own credentials. Electra checks source authorization and validator eligibility; it does not make a same-address requirement the definition of consolidation. Inspect the target validator and its recipient before interpreting a consolidation as a harmless prefix upgrade.
That distinction matters for custody: same-validator conversion preserves the address; consolidation into another validator moves balance to a different validator's control arrangement. To assess a particular validator, check its credentials, status and pending operations against the intended operation.
Signing key, withdrawal key and recipient address
| Authority | What it controls |
|---|---|
| Validator signing key | Consensus duties and eligible voluntary-exit messages |
| BLS withdrawal key for 0x00 | The signed change assigning an execution recipient |
| Recorded execution address | Receipt of payouts and authorization of applicable execution-layer requests |
An execution recipient can be a wallet or a contract. A displayed address does not prove that you control it. For a contract, the contract's own permissions determine who can cause it to make a request; possession of a validator signing key does not replace that check.
EIP-7002 introduces execution-layer requests for exits and partial withdrawals. The consensus-layer rules determine whether a request is applicable. A successful submission at the execution layer is therefore not proof that a validator has exited or that ETH has arrived.
Partial withdrawal, exit and payout are separate
Automatic partial withdrawal: an eligible 0x01 validator can have excess balance swept to its recorded address while continuing to validate. Automatic sweeps also exist for compounding validators above their higher cap; 0x02 does not mean that every withdrawal is manual.
Requested partial withdrawal: Electra permits eligible compounding validators to request available excess above the minimum balance. The processor checks active status, exit status, effective balance and amounts already pending. It can limit the amount to eligible excess; a submitted amount is not an unconditional claim on that amount.
Full exit: ending validator participation precedes final withdrawal. A voluntary exit can be signed by the validator key; applicable execution-layer requests offer another path. Eligibility, exit scheduling, withdrawability and payout processing are distinct stages. Changing credentials alone neither exits a validator nor bypasses those stages.
The Electra request processor makes these distinctions explicit. It also reserves zero in the request's amount field for a full-exit request. That field convention is not a zero-value payout.
The eligibility checks include a matching recipient address, an active validator that has served long enough, and no exit already initiated. A full-exit request also requires no pending partial withdrawal balance. Requested partial withdrawals require compounding credentials and eligible excess after pending amounts are deducted. A request that fails these checks schedules no withdrawal. Passing the execution-layer transaction does not bypass them.
How to verify a validator's withdrawal setup
- Confirm the network and validator public key or index. Read the full credential from its consensus state or a reputable explorer.
- Identify the prefix. For
0x01or0x02, compare the final twenty bytes with the expected recipient address. Do not interpret the tail of a BLS hash as an execution address. - Check who controls the relevant withdrawal key, wallet or contract. Public credentials do not establish access to those authorities.
- Identify the intended operation: address assignment, same-validator conversion, cross-validator consolidation, partial withdrawal or exit. They have different authorization and eligibility rules.
- For progress, check the validator's current status and pending operations, then verify the eventual execution-layer receipt. A request transaction alone establishes neither completion nor timing.
Never provide a seed phrase or private key to inspect public withdrawal credentials. Live status and waiting times require a separate current-state check; this article does not estimate them.
Sources and methodology
Rules checked Oct 11, 2026 against consensus-specs revision v1.6.0:
- Capella beacon-chain specification: BLS-to-execution changes and credential encoding.
- Electra beacon-chain specification: compounding, request eligibility and consolidation.
- EIP-7002: execution-layer request mechanism.
- EIP-7251: increased effective-balance design.
This is a versioned protocol explanation, not a sampled dataset, wallet assessment or validator simulation. Source-code review does not verify every client's implementation or any particular validator's current state. Protocol changes require a new rules review; there is no numerical refresh schedule for this page.
Share note
Share this research note.
Keep the explanation, sources and limitations together in one link.