Abstract

This draft EIP introduces a mechanism for Ethereum validators with BLS (0x00) withdrawal credentials who have lost access to their withdrawal mnemonic to securely update their credentials to execution-layer (0x01) credentials. The mechanism, inspired by the Consensus Layer Withdrawal Proposal (CLWP) concept, uses cryptographic proofs of validator control and deposit origin. Additionally, it defines a pathway for validators operated by custodial stake pools to achieve the same update through cooperative validation, enabling recovery for a wide range of affected participants.

Motivation (Updated)

After Ethereum’s transition to proof-of-stake, validators registered with BLS-based (0x00) withdrawal credentials must migrate to execution-layer (0x01) credentials to access and withdraw their staked ETH. However, many validators have not completed this migration — and some have lost access to the mnemonic needed to authorize the credential change, leaving their ETH effectively locked.

This proposal enables such validators to recover access in a secure, verifiable way using cryptographic proofs of control over both:

• The validator signing key, and
• The original deposit address.

Additionally, a large number of validators are operated through custodial staking providers (stake pools), where the validator signing key is held by the provider. This proposal outlines a controlled, consent-based process where the depositor can initiate the recovery, and the stake pool cooperates by producing the required validator signature — but only with explicit depositor authorization.

Long-Term Motivation: BLS Deprecation & Quantum Risk

BLS withdrawal credentials (0x00) rely on BLS12-381 elliptic curve cryptography, which is not quantum-safe. In the presence of a sufficiently powerful quantum computer, it would be possible to derive private keys from public keys using Shor’s algorithm, making BLS credentials vulnerable to theft.

In contrast, execution-layer credentials (0x01) leverage Ethereum account-based cryptography, which can more easily migrate to quantum-resistant schemes as part of future protocol upgrades.

As a result, the Ethereum ecosystem will likely need to deprecate BLS credentials entirely in the future. This proposal serves as important pre work for that transition by:

• Establishing a robust recovery mechanism for currently inaccessible 0x00 validators.
• Defining a standard pattern for validator credential updates outside of the original mnemonic flow.
• Preparing the validator set for future migrations to post-quantum withdrawal formats.

This ensures that Ethereum can maintain a healthy validator set, prevent permanent ETH loss, and reduce the eventual coordination burden of a network-wide BLS deprecation.

Specification

Scope

This mechanism applies only to:

• Validators with 0x00 BLS withdrawal credentials.
• Validators that have not exited or withdrawn their funds.
• Cases where the mnemonic (withdrawal key) is lost or inaccessible.

1. Non-Custodial Validators (Self-Operated)

Proof-of-Ownership Flow

A validator can request a credential update by submitting two cryptographic signatures. This process is outlined on https://github.com/eth-educators/update-credentials-without-mnemonic and https://ucwm.xyz

1. Validator Key Store Signature
   The validator creates a key store signature by using their validator key and the Ethereum deposit-cli.
2. Deposit Address Signature
   The original deposit address (the address that funded the validator via the deposit contract) signs a message through Beaconcha.in.

These signatures, along with metadata (validator index, target execution address), are submitted to an on-chain credential update contract or recognized off-chain protocol.

Verification and Update

• Both signatures are verified against the list of validators with BLS credentials and the deposit address is also validated manually.
• A challenge period (e.g., XX-XX months) allows the community to dispute any fraudulent claim.
• If successful, the validator’s withdrawal credentials are updated from 0x00 to 0x01, with the specified execution address.
• These validators will be added to the exit queue, adhering to the existing exit rate limits to avoid destabilizing the network.

2. Custodial Stake Pool Validators

Problem Context

For validators run via custodial staking providers, the validator private key is held by the stake pool, not the depositor. This makes it impossible for the depositor to produce the validator key signature themselves.

Proposed Custodial Flow

1. Depositor Declaration (On-Chain Intent)
   The depositor (owner of the funding address) signs a message through Beaconcha.in and submits it on-chain, stating:

• Their control over a specific validator (by index or public key).
• Their request to update withdrawal credentials.
• Their target execution address.

1. Operator Review & Stake Pool Coordination

• A trusted multisig, DAO, or ETH Staker community body reviews the declaration.
• They verify the deposit origin and validator status.
• They contact the stake pool to confirm the depositor’s relationship.

1. Stake Pool Signature
   The stake pool, upon verification, follows the same process as above to create a validator key store signature.
2. Final Submission and Challenge Period

• The pool’s validator signature, linked to the depositor’s on-chain declaration, is submitted.
• Challenge period begins.
• Upon approval, withdrawal credentials are updated.
• Lastly, these validators are added to the exit queue.

Rationale

• Minimizes ETH loss: Enables recovery for validators whose funds are otherwise permanently locked.
• Dual-authentication: Using both the validator key and deposit key ensures strong identity guarantees.
• Stake pool path: Provides a collaborative, secure, and consent-driven path for custodial validators.