--- eip: 8433 title: Retire 0x00 validators description: Exit remaining validators with 0x00 withdrawal credentials at a capped rate after a grace period, keeping the credential change path open author: NC (@ensi321) discussions-to: https://ethereum-magicians.org/t/eip-8433-retire-0x00-validators/29808 status: Draft type: Standards Track category: Core created: 2026-09-28 requires: 7251, 8365 --- ## 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](./eip-8365.md) 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](./eip-7002.md)) 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](./eip-8365.md) 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 | Name | Value | Comment | | --------------------------- | ----- | ------------------------------------------------------------------- | | `RETIREMENT_START_EPOCH` | TBD | First epoch at which retirements are initiated | | `MAX_RETIREMENTS_PER_EPOCH` | TBD | Maximum retirements initiated per epoch transition | `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`: ```python 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](./eip-8365.md), 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](./eip-8365.md) 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](./eip-6049.md) (deprecation notice), [EIP-6780](./eip-6780.md) (behavioral restriction), and [EIP-4758](./eip-4758.md) (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](./eip-2929.md)), `SELFDESTRUCT` neutering ([EIP-6780](./eip-6780.md)), 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](../LICENSE.md).