EIP-8433: Retire 0x00 validators

Abstract

This EIP retires the remaining validators whose withdrawal credentials carry the BLS_WITHDRAWAL_PREFIX (0x00). Starting at a fixed epoch after fork activation, a standing rule in epoch processing initiates the exit of active 0x00 validators at a capped rate through the standard exit churn. The BLSToExecutionChange operation is unchanged: a retired validator's full balance remains recoverable at any time by rotating to 0x01 execution credentials, after which the standard withdrawal sweep pays it out.

This is the second stage of a staged deprecation of the 0x00 credential type. EIP-8365 closes the inflow by rejecting deposits that would create new 0x00 validators. This EIP removes the existing population from duty participation. A companion balance sunset EIP gradually reduces retired 0x00 balances to zero ahead of the post-quantum transition, and a final-stage EIP at the post-quantum fork removes the remaining 0x00 machinery (BLSToExecutionChange, its gossip topic and operation pool, and the zero-balance registry entries) from the consensus layer entirely.

Motivation

The 0x00 credential type is the original genesis-era withdrawal format: 0x00 || sha256(withdrawal_bls_pubkey)[1:], with withdrawal controlled by a BLS key and no execution address. Since Capella opened one-way conversion to 0x01, the population has fallen from roughly 600,000 to about 9,200 validators (mainnet, August 2026), but the decline has stalled. Conversion inclusions have decayed to double digits per month, and of the still-active 0x00 validators, several hundred have not attested for over six months. These are, with high likelihood, validators whose keys are lost.

The stalled tail creates costs that grow with time rather than shrink:

• Un-removable validators. No party can exit a 0x00 validator with a lost key. Voluntary exit requires the signing key, and execution-layer triggerable exits (EIP-7002) require an execution address that 0x00 credentials do not have. At measured penalty rates (~0.55 ETH/year), natural ejection at EJECTION_BALANCE takes roughly 28 years. Being offline is a transient state for execution-credentialed validators, whose owners can always exit and recover funds, but a terminal state for 0x00 validators with lost keys.
• Permanent protocol surface. While any 0x00 validator exists, every fork must carry process_bls_to_execution_change, its gossip topic, its operation pool, and the 0x00 branch of every credential check.
• Post-quantum transition burden. BLS signatures are not post-quantum secure. Every post-quantum key registry design under discussion requires a per-validator registration action, and validators that cannot act (lost keys) cannot register. Force-exiting non-registrants at the signature switch is clean for execution-credentialed validators, whose funds sweep to their execution address, but strands 0x00 balances on the consensus layer. BLSToExecutionChange itself becomes insecure once BLS is broken: the message reveals the withdrawal public key, allowing a quantum adversary to derive the key and race a competing change. Any plan that carries 0x00 validators into the post-quantum era must design and maintain hardened credential-change machinery indefinitely, solely for this population.

EIP-8365 stops the population from growing but leaves the existing validators in place. This EIP removes them from duty participation. It deliberately does not touch balances: retired validators are frozen (no rewards, no penalties) awaiting credential rotation. Without the companion balance sunset, the frozen entries would persist in the registry indefinitely and the final-stage removal would have to delete entries with non-zero balances, which is a materially harder decision. The staged path (close the inflow, retire, drain, remove) is designed to be evaluated as a whole, with the stages activating in consecutive forks so that holders have a documented timeline to act against.

Specification

Constants

RETIREMENT_START_EPOCH is an absolute epoch, not an offset from fork activation, so the grace period is unaffected by fork timing and can be published as a date well in advance.

Consensus layer

Epoch processing

A new per-epoch step, process_bls_validator_retirement, is added to process_epoch after process_registry_updates:

def process_bls_validator_retirement(state: BeaconState) -> None:
    current_epoch = get_current_epoch(state)
    if current_epoch < RETIREMENT_START_EPOCH:
        return
    retirements = 0
    for index, validator in enumerate(state.validators):
        if retirements >= MAX_RETIREMENTS_PER_EPOCH:
            break
        if (
            is_active_validator(validator, current_epoch)
            and validator.withdrawal_credentials[:1] == BLS_WITHDRAWAL_PREFIX
            and validator.exit_epoch == FAR_FUTURE_EPOCH
        ):
            initiate_validator_exit(state, ValidatorIndex(index))
            retirements += 1

This is a standing rule, not a one-time transition: from RETIREMENT_START_EPOCH onward it enforces the invariant that 0x00 is not a valid credential for an active validator. Up to MAX_RETIREMENTS_PER_EPOCH retirements are initiated per epoch transition, in validator index order, until the active 0x00 population is exhausted. Any validator that subsequently surfaces from the activation queue with 0x00 credentials is retired by the same rule.

Exits flow through the standard exit churn via initiate_validator_exit.

Unchanged operations

process_bls_to_execution_change is unchanged and remains available. A retired (exited) 0x00 validator that rotates to 0x01 credentials becomes fully withdrawable once its withdrawable_epoch has passed, and the withdrawal sweep transfers its entire remaining balance to the execution address in the change message.

process_voluntary_exit is unchanged. Voluntary exits of 0x00 validators before RETIREMENT_START_EPOCH have the same effect as retirement.

Deposit processing is unchanged by this EIP. Under EIP-8365, deposits that would create new 0x00 validators are already rejected, and top-ups to existing validators, including retired 0x00 validators, continue to be applied.

Rationale

Exit as the retirement mechanism

Exiting a validator natively removes it from all duty selection (proposer, attester, sync committee and any future committees) and ends both reward accrual and penalty exposure. No new exclusion machinery is required, and the frozen state ("no rewards, no penalties, balance intact") is exactly the intended holding pattern while awaiting credential rotation. Excluding validators from duties without exiting them was considered and rejected: it would introduce a new validator state that every committee selection, reward path and effective-balance computation would need to handle.

A grace period as a constant

The retirement rule starts at RETIREMENT_START_EPOCH rather than at fork activation. Together with the fork that activates EIP-8365 one fork earlier, this gives holders a documented, multi-stage timeline: the inflow closes, then a published date arrives at which remaining validators are retired. Expressing the grace period as an absolute epoch rather than as a separate fork keeps the schedule predictable for holders without spending an additional fork on it, and lets the date be tuned during review rather than renegotiated at a later fork.

A standing rule rather than a one-time sweep

A one-shot mass exit at RETIREMENT_START_EPOCH misses validators still in the deposit and activation pipeline, which can surface weeks later, and would require a second special-case event to catch them. A per-epoch rule expresses the actual invariant, drains the existing population and catches stragglers with the same code path, and requires no transition-specific logic.

Capped initiation rate

Initiating all remaining exits in a single epoch would assign the entire population staggered exit epochs immediately, backing up the exit queue by several days at current churn, and any ordinary validator submitting a voluntary exit during that window would wait behind the full backlog. Capping initiation with MAX_RETIREMENTS_PER_EPOCH spreads the load so that the retirement stream consumes a bounded share of the per-epoch exit churn and other validators' exit times are essentially unaffected. Capped per-epoch processing is an established pattern in epoch processing (pending deposits, pending consolidations).

The constant's value trades drain time against churn share, and is left TBD. Indicative values for a population of ~9,000: a value of 8 matches the exit churn throughput exactly (MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT / MIN_ACTIVATION_BALANCE = 256 ETH / 32 ETH), completing retirement in about five days while never exceeding the queue's drain rate, and a value of 1 consumes 12.5% of churn capacity and completes in about six weeks. The total time for the population to pass through the exit queue cannot go below the churn-imposed five days regardless of the value.

Notice and the conversion path

A 0x00 validator that rotates credentials before RETIREMENT_START_EPOCH keeps validating uninterrupted. One that rotates afterward recovers its full balance via the sweep and may re-enter as a new 0x01 or 0x02 validator. No balance is reduced by this EIP at any point.

Voluntary exit requires the signing key while credential rotation requires the withdrawal key, so a holder of only the signing key can exit but not rotate. Such validators are in the same position as the 0x00 validators already exited and awaiting rotation on mainnet today, all of which this EIP leaves untouched (they are already exited) and the companion balance sunset covers.

Staged deprecation precedent

The SELFDESTRUCT deprecation followed the same arc across multiple EIPs and forks: EIP-6049 (deprecation notice), EIP-6780 (behavioral restriction), and EIP-4758 (full deactivation). Close the inflow, retire, drain, remove is the same pattern applied to a credential type, with the same motivation: maintaining legacy functionality indefinitely carries a cost for every subsequent upgrade, and a clear deprecation schedule serves both the network and the remaining users better than an open-ended wait.

Credible neutrality

Rescue proposals for 0x00 validators with lost keys have been rejected in the past on credible-neutrality grounds: a rescue adjudicates off-chain ownership claims and selects beneficiaries. This EIP is the opposite shape: a uniform rule over a class defined by an objective on-chain property, announced well in advance, with a permissionless compliance path (BLSToExecutionChange) open to every member throughout. It takes no position on any ownership claim. Rule-based deprecations with forward notice that disadvantage specific users are an established and accepted category: opcode repricings (EIP-2929), SELFDESTRUCT neutering (EIP-6780), and the inactivity leak all share this shape.

Interaction with the post-quantum key registry

Every post-quantum key registry design under discussion requires a per-validator registration action, and validators that never register cannot remain active past the signature switch, whichever design is chosen. Force-exiting non-registrants is clean for execution-credentialed validators (funds sweep to their execution address) but strands 0x00 balances on the consensus layer. This EIP resolves that asymmetry ahead of time, independently of which registry design is adopted: by the time a registry fork activates, no active validator carries 0x00 credentials, and the registry does not need to consider them.

Backwards Compatibility

This EIP introduces backward-incompatible changes to consensus-layer state transition and must be scheduled with a hard fork. No execution-layer changes are required.

Test Cases

TBD. Reference tests will be provided with the consensus-specs implementation, covering: no retirements before RETIREMENT_START_EPOCH, the per-epoch cap respected from RETIREMENT_START_EPOCH onward, index-order draining, activation-queue stragglers retired on activation, and credential rotation after retirement releasing the full balance.

Security Considerations

Validator set reduction

Retiring the full current population removes at most roughly 300,000 ETH of effective balance (about 1% of total stake at time of writing, and shrinking as conversions occur) from the active set. This is well within normal validator-set churn and does not meaningfully affect finality safety margins or weak-subjectivity periods.

No change to fund ownership

This EIP moves no balances. Every retired validator's balance remains in the beacon state, recoverable in full at any time through the unchanged BLSToExecutionChange path. The population unable to use that path (lost withdrawal keys) is unable to use it today, and this EIP does not change their position.

Exit queue impact

Retirement initiation is capped at MAX_RETIREMENTS_PER_EPOCH, bounding the retirement stream's churn consumption per epoch. With the cap at or below the churn-matched value, no backlog accumulates from retirement and the exit time of ordinary voluntary exits is essentially unaffected throughout the drain window. Ordinary exits initiated during the window share churn with the retirement stream, so combined demand can transiently exceed throughput, but the worst case is mild queueing comparable to any busy exit period, not a multi-day wall.

Copyright

Copyright and related rights waived via CC0.