Ethereum Improvement Proposal: Update Credentials Without Mnemonic

This 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

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:

  1. The validator signing key, and
  2. 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 prework for that transition by:

  1. Establishing a robust recovery mechanism for currently inaccessible 0x00 validators.
  2. Defining a standard pattern for validator credential updates outside of the original mnemonic flow.
  3. 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.

Solo Stakers (Non-Custodial Validators)

Proof-of-Ownership Flow
A validator can request a credential update by submitting two cryptographic signatures:

  1. Validator Key Signature
    2. The validator signs a standard message (e.g., CLWP_CREDENTIAL_UPDATE:) using their validator private key.
  2. Deposit Address Signature
    3. The original deposit address (the address that funded the validator via the deposit contract) signs a matching message. 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 known validator registry and deposit data.
  • A challenge period (e.g., 7 days) 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.

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)
    2. The depositor (owner of the funding address) signs a message 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.
  2. Operator Review & Stake Pool Coordination
    • A trusted multisig, DAO, or community body reviews the declaration.
    • They verify the deposit origin and validator status.
    • They contact the stake pool to confirm the depositor’s relationship.
  3. Stake Pool Signature
    4. The stake pool, upon verification, signs the same CLWP_CREDENTIAL_UPDATE: message using the validator private key.
  4. 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.

    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.

    This proposal does not affect validators with 0x01 credentials or those who still possess their mnemonic.