---
eip: 8365
title: Disallow new 0x00 validators
description: Reject deposits that would create new validators with 0x00 withdrawal credentials, leaving existing validators untouched
author: NC (@ensi321), Kevaundray Wedderburn (@kevaundray)
discussions-to: https://ethereum-magicians.org/t/eip-8365-bls-withdrawal-credential-retirement/29284
status: Draft
type: Standards Track
category: Core
created: 2026-07-18
requires: 6110, 7251, 7732
---

## 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](./eip-7002.md)), 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:

```python
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](./eip-7732.md)), 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](./eip-6110.md) invalid-signature deposits), and [EIP-8205](./eip-8205.md) 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](./eip-7732.md).

## 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](../LICENSE.md).