Disallow new 0x00 validators

Abstract

This EIP closes the inflow of the BLS_WITHDRAWAL_PREFIX (0x00) withdrawal credential type. Deposits that would create new validators with 0x00 credentials are not processed. Existing 0x00 validators are unaffected. They continue to validate, earn rewards, and accrue penalties. The BLSToExecutionChange operation remains available for conversion to 0x01 execution credentials.

This is the first stage of a staged deprecation of 0x00, and it is intended as the notice step of a documented timeline. With the inflow closed, the 0x00 population cannot grow. A companion retirement EIP, targeting the fork after this one, exits the remaining 0x00 validators at a capped rate starting from a published epoch, and a companion balance sunset EIP gradually reduces retired balances to zero ahead of the post-quantum transition. A final-stage EIP at the post-quantum fork removes the remaining 0x00 machinery (BLSToExecutionChange, its gossip topic, and its operation pool) from the consensus layer.

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 several hundred of the remaining validators have not attested for over six months, which suggests lost keys.

Despite this, deposits can still create new 0x00 validators, and they still do. Mainnet data shows 58 validators created with 0x00 credentials in 2026, including one batch of 50 by a single entity in March. These validators have no execution address, so they cannot use execution-layer triggerable exits (EIP-7002), and a lost withdrawal key leaves their balance permanently stranded on the consensus layer. Every 0x00 validator also extends the protocol's dependence on process_bls_to_execution_change, its gossip topic, its operation pool, and the 0x00 branch of every credential check, all of which must be carried into and hardened for the post-quantum transition as long as the population exists.

Disallowing new registrations prevents the legacy population from growing while the remaining stages of the deprecation are scheduled, and it signals the planned deprecation of 0x00 credentials in consensus code rather than in announcements alone.

This EIP does not exit, penalize, or otherwise change existing 0x00 validators. They continue to validate, and their balances remain unchanged.

Specification

Consensus layer

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. They are silently skipped, and the deposited ETH is not recoverable. Top-ups to existing validators, including 0x00 validators, are processed normally.

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

The guard applies when a pending deposit is processed, not when it is submitted. Fork activation does not grandfather pending deposits. Thus, a pre-fork 0x00 deposit that would create a validator is rejected if it is processed after activation.

Rationale

Deposit guard only

Stopping new registrations is the first stage of deprecation. The guard prevents the 0x00 validator population from growing. Existing validators can reduce the population by changing credentials. The guard does not change their duties, rewards, penalties, exits, or balances.

The consensus layer has no mechanism to refund a rejected deposit. Therefore, an 0x00 deposit that would create a validator is skipped, and its ETH remains in the deposit contract. Silently skipping a 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 maintained deposit tooling has produced 0x00 credentials since Capella, so this branch exists to close the inflow, not to adjudicate marginal cases.

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

The following cases define the required behavior:

• A valid 0x00 pending deposit for an unknown public key is skipped.
• An invalidly signed 0x00 pending deposit for an unknown public key is skipped.
• A pre-fork 0x00 deposit is skipped if it is still pending when this EIP activates.
• A top-up to an existing 0x00 validator is applied.
• Valid deposits that create 0x01 or 0x02 validators are applied.
• A valid 0x03 deposit follows the builder-routing rules in EIP-7732.

Security Considerations

Pending deposit loss

Submitting a deposit before activation does not guarantee registration. A deposit with 0x00 credentials can remain queued until after activation. The consensus layer then rejects it, and the deposited ETH is not recoverable.

Deposit contract griefing

A third party cannot use the guard to burn someone else's funds. Constructing a deposit that creates a 0x00 validator 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.

Copyright

Copyright and related rights waived via CC0.