EIP-8365: BLS withdrawal credential retirement

Exit validators with 0x00 withdrawal credentials and stop creating new ones, keeping the credential change path open

Abstract

This EIP retires the BLS_WITHDRAWAL_PREFIX (0x00) withdrawal credential type. A standing rule in epoch processing initiates the exit of every active validator whose withdrawal credentials carry the 0x00 prefix, and deposits that would create new validators with 0x00 credentials are no longer processed. 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 first stage of a staged deprecation. A companion EIP (balance sunset) 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 9,290 validators (mainnet, July 2026: 9,119 active plus 171 exited awaiting credential rotation), but the decline has stalled. Conversion inclusions have decayed to double digits per month, and of the 9,119 still-active 0x00 validators, 374 have not attested for over six months and 253 have never attested in a 14-month observation window. 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. Offline rates confirm the asymmetry: 4.45% of active 0x00 validators have been offline for 30+ days, versus 0.10% for 0x01 and 0.05% for 0x02. 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. The post-quantum roadmap has validators registering post-quantum keys ahead of a signature-switch fork, but validators that cannot act (lost keys) cannot register. 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. Retiring the credential type before the transition removes a design question from any post-quantum key registry (how a validator with no execution address authorizes its registration), and lets the signature-switch fork start from a clean validator set.

This EIP alone stops duty participation and closes the inflow. It deliberately does not touch balances: retired validators are frozen (no rewards, no penalties) awaiting credential rotation. Without the companion balance sunset EIP, 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 (retire, drain, remove) is designed to be evaluated as a whole, while allowing the stages to activate in the same fork or in consecutive forks.

Specification

Constants

Consensus layer

Epoch processing

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

def process_bls_credential_retirement(state: BeaconState) -> None:
    current_epoch = get_current_epoch(state)
    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: it enforces the invariant that 0x00 is not a valid credential for an active validator after the fork. Starting from the first epoch after activation, 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.

Deposit processing

apply_pending_deposit is modified so that deposits which would create a new validator with 0x00 withdrawal credentials are not applied:

def apply_pending_deposit(state: BeaconState, deposit: PendingDeposit) -> None:
    validator_pubkeys = [v.pubkey for v in state.validators]
    if deposit.pubkey not in validator_pubkeys:
        # [New in this EIP] Do not create validators with BLS withdrawal credentials
        if deposit.withdrawal_credentials[:1] == BLS_WITHDRAWAL_PREFIX:
            return
        # Verify the deposit signature (proof of possession)
        if is_valid_deposit_signature(
            deposit.pubkey,
            deposit.withdrawal_credentials,
            deposit.amount,
            deposit.signature,
        ):
            add_validator_to_registry(
                state,
                deposit.pubkey,
                deposit.withdrawal_credentials,
                deposit.amount,
            )
    else:
        # Top-ups are unaffected
        index = ValidatorIndex(validator_pubkeys.index(deposit.pubkey))
        increase_balance(state, index, deposit.amount)

Rejected deposits receive the same treatment as deposits with invalid signatures today: they are silently skipped and the deposited ETH is not recoverable. Top-up deposits to existing validators, including retired 0x00 validators, are processed normally.

Where builder credential routing applies (0x03, EIP-7732), the 0x00 check precedes it.

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 the fork have the same effect as retirement.

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.

A standing rule rather than a one-time sweep

A one-shot mass exit at the fork transition 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 ~9,000 exits in a single epoch would assign the entire population staggered exit epochs immediately, backing up the exit queue by roughly five 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 the current population of ~9,100: 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

The grace period runs from the publication of this EIP to fork activation, roughly six months on current fork cadence. A 0x00 validator that rotates credentials before activation keeps validating uninterrupted. One that rotates after activation recovers its full balance via the sweep and may re-enter as a new 0x01/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 171 0x00 validators already exited and awaiting rotation on mainnet today, all of which this EIP leaves untouched (they are already exited) and the companion EIP covers.

Deposit rejection semantics

Silently skipping the deposit while the ETH remains in the deposit contract is the established treatment of invalid deposits (EIP-6110 invalid-signature deposits), and EIP-8205 adopts the same permanent-rejection semantics for credential-mismatched deposits by deliberate design. No new deposit ought to carry 0x00 credentials (every deposit tool has defaulted to execution credentials since Capella), so this branch exists to close the inflow, not to adjudicate marginal cases.

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). 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. Existing deposit tooling is unaffected unless it attempts to create new 0x00-credentialed validators, which no maintained tooling does.

Test Cases

TBD. Reference tests will be provided with the consensus-specs implementation, covering the retirement rule (per-epoch cap respected, index-order draining, activation-queue stragglers), the deposit guard (new 0x00 deposit skipped, top-up applied), and credential rotation after retirement.

Security Considerations

Validator set reduction

Retiring the full current population removes at most ~297,000 ETH of effective balance (~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.

Deposit contract griefing

The deposit guard burns deposits that create 0x00 validators. A third party cannot grief anyone with this: constructing such a deposit requires a valid proof-of-possession signature over the 0x00 credentials from the depositing key, so only the key holder can burn their own deposit. This matches the existing invalid-signature deposit semantics.

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.

Citation

Please cite this document as:

NC (@ensi321), "EIP-8365: BLS withdrawal credential retirement [DRAFT]," Ethereum Improvement Proposals, no. 8365, July 2026. Available: https://eips.ethereum.org/EIPS/eip-8365.