Ethereum researchers Kevaundray Wedderburn, Tom Wambsgans, and Thomas Coratger filed a draft improvement proposal on August 24 for a validator deposit contract that would accept post-quantum keys and include a switch capable of permanently disabling new BLS deposits once activated.
Building the Socket Before Choosing the Plug
Ethereum validators currently deposit using BLS public keys and signatures of fixed length, a structure hard-coded into the deposit contract. The draft replaces that with variable-length public keys, signatures, and credential metadata, paired with a scheme identifier that records which cryptographic system a validator uses.
Scheme 0 is reserved for the existing BLS format. Later identifiers would accommodate other systems, and the metadata field can carry scheme-specific information rather than forcing every signature type into one fixed shape.
The proposal names no post-quantum algorithm. That decision, along with how validators verify, aggregate, and process signatures under each scheme, would fall to a separate consensus-layer change. The contract is described as post-quantum-ready rather than quantum-resistant—the distinction being that it can accept keys for a scheme Ethereum has not yet adopted.
That sequencing matches the direction Vitalik Buterin set out in February, when he identified consensus-layer BLS signatures as one of four quantum-vulnerable components and pointed toward hash-based replacements.
Moving Deposits Onto Execution-Layer Requests
The draft would retire the deposit contract’s Merkle-tree mechanism in favor of execution-layer requests, using EIP-7685, the general framework for passing data from the execution layer to the consensus layer.
Ethereum already runs several validator operations through that framework: EIP-6110 delivers deposits as requests, EIP-7002 handles execution-triggered withdrawals, and EIP-7251 covers consolidations. The new contract extends the same architecture to deposits carrying flexible cryptographic payloads.
The Off-Switch
The migration is staged. The contract would deploy with BLS deposits enabled and additional schemes able to register later. A subsequent protocol decision could then permanently disable new Scheme 0 deposits, and under the proposed design, retirement could not be reversed.
Existing BLS validators would not disappear when the switch fires. Separate rules would still be required to handle existing keys, exits, credential changes, and migration into a post-quantum scheme—the harder half of the problem, and one this proposal does not address.
The authors have asked for feedback on how the design should interact with EIP-7002, EIP-7251, and EIP-8282. Wedderburn, who opened the pull request, said the topic had been raised at an All Core Developers Execution call.
Where It Sits
Ethereum’s post-quantum work runs on several tracks. The Ethereum Foundation established a dedicated post-quantum team in January, and in June a team including Coratger, one of this proposal’s three authors, published the design for a dedicated XMSS public-key registry as the first protocol fork before validators move off BLS signatures. A separate execution-layer track covers account signatures, including an EF researcher’s proposal to add quantum-resistant protection to existing accounts for around seven cents without a hard fork.
Buterin’s Lean Ethereum roadmap, published in July, treats quantum-resistant cryptography as a first-class protocol priority across a three-to-four-year redesign, and an August update moved quantum safety and privacy further up the agenda. Full post-quantum consensus is described as a longer-term goal stretching toward 2030.
Status
The pull request is a draft. It carries labels marking it a new core proposal awaiting editor consensus, formal review, and passing automated checks, which were failing when examined. The file is named with a placeholder number; an editor suggested EIP-8394 and requested a separate Ethereum Magicians discussion, and that number is not yet published on the canonical EIP site.
The EIP repository states that documents not published on the official site should be treated as working papers. Publication as a draft would not indicate approval. The proposal would still require specification work, security analysis, client implementations, and testing before core developers could select it for a hard fork. No target fork, testnet activation, or mainnet date has been announced.
Also Read: How the Top Blockchains Are Racing to Survive Q-Day
