EIP-8365 Ban on registering new 0x00 validators (Disallow new 0x00 validators)

Hegota Considered for Inclusion · Consensus & staking · EIP status Draft · created 2026-07-18

Deposits that create new validators with 0x00 (BLS) withdrawal credentials are no longer processed. Existing 0x00 validators are left as they are, and the path for converting them to 0x01 stays open.

Why it is needed

0x00 is the original withdrawal address format from the beacon chain genesis era. Withdrawals are controlled by a BLS key and there is no execution layer address. After the Capella upgrade made conversion to 0x01 possible, the number of 0x00 validators fell from about 600,000 to about 9,200 as of August 2026. However, conversions have slowed to the low double digits per month, and several hundred have not attested for more than six months and appear to have lost their keys. Even so, new 0x00 validators are still being created today. 58 were created in 2026 alone, and in March one entity created 50 at once. Such validators have no execution address, so they cannot use the execution layer exit request feature (EIP-7002), and if the withdrawal key is lost the balance is locked in the consensus layer forever. Also, as long as even one 0x00 validator remains, the conversion operation, its gossip topic, the operation pool, and even the 0x00 branch of the credential check must all be maintained and hardened until the quantum-resistant transition. This EIP blocks new inflow so that this group does not grow any larger. The deprecation plan is communicated through consensus code, not an announcement.

What changes

Today

After EIP-8365

Who is affected

In depth

The first step of a staged deprecation

This EIP only closes the inflow of the BLS_WITHDRAWAL_PREFIX (0x00) withdrawal credential type. Deposits that would create a new validator with 0x00 credentials are not processed. Existing 0x00 validators keep validating and continue to receive rewards and penalties as before. The BLSToExecutionChange operation that switches to 0x01 execution credentials can still be used as well. The source document describes this as the notice phase of a documented schedule. From the epoch published by a companion EIP (retirement) targeting the next fork, the remaining 0x00 validators are exited at a capped rate. Another companion EIP (balance sunset) gradually reduces the exited balances to zero before the post-quantum transition. The final-stage EIP removes BLSToExecutionChange, its gossip topic, and its operation pool from the consensus layer at the post-quantum fork.

Changes to apply_pending_deposit

Adds one branch to apply_pending_deposit, which applies pending deposits. When the deposit's pubkey is not in state.validators, that is, when it would create a new validator, and the first byte of withdrawal_credentials is BLS_WITHDRAWAL_PREFIX, the function returns immediately before signature verification. If the first byte is different, it checks proof of possession with is_valid_deposit_signature as before and then calls add_validator_to_registry. If the pubkey is already registered, the deposit is a top-up, so the balance is increased with increase_balance regardless of the credential type. Top-ups to 0x00 validators are also processed normally. A rejected deposit is treated the same as a deposit with an invalid signature. It is silently skipped and the deposited ETH cannot be recovered. Where the 0x03 builder credential routing of EIP-7732 applies, the 0x00 check comes before it.

Applied at processing time, not at submission time

The guard applies when a pending deposit is processed, not when it is submitted. Fork activation does not exempt pending deposits that are already in the queue. So a 0x00 deposit submitted before the fork is still rejected if it is processed after activation. The source document treats this separately as "pending deposit loss" in its Security Considerations. Submitting a deposit before activation does not guarantee registration. If a 0x00 credential deposit remains in the queue past activation, the consensus layer rejects it and the deposited ETH cannot be recovered. The test cases also include "a pre-fork 0x00 deposit that is still pending at activation is skipped."

Why there is no refund

The consensus layer has no mechanism to refund a rejected deposit. So 0x00 deposits that would create a new validator are skipped, and the ETH stays in the deposit contract. The source document explains that this is not a new treatment. Silently skipping a deposit and leaving the ETH in the deposit contract is the established way EIP-6110 handles deposits with invalid signatures. EIP-8205 also deliberately adopted the same permanent rejection semantics for deposits with mismatched credentials. Among deposit tools maintained since Capella, none creates 0x00 credentials. The source document states that this branch is meant to close the inflow, not to rule on edge cases.

Can someone burn another person's deposit?

A third party cannot use this guard to burn another person's funds. To construct a deposit that creates a 0x00 validator, one must produce a valid proof-of-possession signature over the 0x00 credentials with the depositing key. So only the key holder can burn their own deposit. The only deposits the guard rejects are ones where the depositor chose 0x00 credentials and signed them. This is the same as the existing treatment of deposits with invalid signatures.

Test cases and compatibility

The source document specifies six required behaviors. A valid 0x00 pending deposit for an unknown public key is skipped. A 0x00 pending deposit with an invalid signature under the same conditions is also skipped. A pre-fork 0x00 deposit that is still pending at activation is skipped. A top-up to an existing 0x00 validator is applied. A valid deposit that creates a 0x01 or 0x02 validator is applied. A valid 0x03 deposit follows the builder routing rules of EIP-7732. On compatibility, this EIP changes the consensus layer state transition, so it must be scheduled as a hard fork, and there is no execution layer change. Existing deposit tools are not affected unless they try to create a new 0x00 validator. None of the maintained tools do.

Source status and fork schedule

The source status is Draft, so the specification and explanation may still change. According to the call records, ACDC #184 on 08.06 accepted EIP-8365/8367 (deprecating BLS withdrawal credentials and sunsetting balances) as Hegotá candidates (PFI). At ACDC #187 on 09.17, a reduced proposal that drops forced exits and keeps only the block on new 0x00 deposits became the likely CFI, and exits were postponed to the I-Star fork. At ACDC #188 on 10.01, EIP-8365 with only the deposit guard was moved to Hegotá CFI, and forced exits were split into a separate EIP to be handled in a future fork. At ACDT #100 on 10.12, it was confirmed that heze-devnet-2 would include EIP-8365 together with EIP-7805, EIP-8015, and EIP-8198. ACDC #189 on 10.15 only had discussion and no decision. At ACDC #190 on 10.29, the decision on whether to burn the ETH from post-fork 0x00 deposits or re-queue the balance as a 0x01 deposit (a proposal by Barnabas) was postponed by two weeks, to be discussed at Devcon and finalized on the next call. The current source document says the ETH cannot be recovered, so this part may change.

Original EIP · ← EIPs