Ethereum researchers have submitted a draft Ethereum Improvement Proposal that would overhaul the network’s validator deposit contract, making it ready for post-quantum signature schemes while creating a permanent pathway to retire the current BLS system.

The proposal, filed as a pull request in the ethereum/EIPs repository on August 24, 2026, was authored by Kevaundray Wedderburn with co-authors Thomas Coratger and Tom Wambsgans. It remains a draft awaiting editor review and has not been assigned a final number or selected for any network upgrade.

Flexible Design for Future Signature Schemes

Under the current system, Ethereum validators deposit fixed-length BLS public keys and signatures. The new contract would accept variable-length public keys, signatures and credential metadata instead. Each deposit would carry a scheme identifier. Scheme 0 would preserve the existing BLS format during a transition period, while later identifiers could support alternative cryptographic systems, including post-quantum options.

The design does not select or implement any specific post-quantum algorithm. A separate consensus-layer change would still be required to define how the network verifies, aggregates and processes signatures under any new scheme. The contract is described as post-quantum-ready rather than quantum-resistant on its own.

The proposal would replace the legacy Merkle-tree mechanism with execution-layer requests built on EIP-7685. That framework already carries deposit, withdrawal and consolidation information between the execution and consensus layers through EIPs such as 6110, 7002 and 7251. The new contract would extend the same architecture to deposits containing flexible cryptographic data.

Irreversible BLS Retirement Mode

A key feature is a staged migration switch. Developers could deploy the contract with BLS deposits still enabled while allowing additional schemes to be added later. A subsequent protocol decision could then permanently disable new Scheme 0 deposits. Once activated, the BLS retirement mode could not be reversed under the proposed design.

Existing BLS validators would not automatically be removed. Separate rules would be needed for key migration, exits, credential changes and the handling of already-active validators.

Authors noted that further work is required to integrate the draft with existing validator-related proposals, including EIP-7002, EIP-7251 and EIP-8282. The topic has been raised in an All Core Developers Execution meeting.

Part of Broader Quantum-Readiness Efforts

The draft fits into a wider Ethereum Foundation initiative that began in January 2026 with the formation of a dedicated post-quantum team. Coratger serves as a leader on that team. Foundation priorities include replacing BLS validator signatures, KZG commitments for data availability, ECDSA account signatures and zero-knowledge proof systems used by rollups.

Core Layer 1 quantum upgrades are currently targeted for around 2029, though that timeline remains a planning goal subject to change. Parallel efforts have examined hash-based schemes such as leanXMSS, which would replace BLS’s compact 96-byte signatures with far larger ones, creating the need for variable-length fields in the deposit contract.

The push responds to advances in quantum computing research, including work that has lowered the estimated cost of attacking 256-bit elliptic-curve cryptography. NIST plans to deprecate ECDSA by 2030 and disallow it by 2035. No quantum computer currently poses a practical threat to Ethereum’s cryptography, and only a small fraction of network funds sit in accounts considered quantum-vulnerable today.

Current Status and Next Steps

The pull request carries draft and core-proposal labels. An editor has suggested assigning the number EIP-8394 and requested a separate discussion thread. Documents not yet published on the official EIP website are treated as working papers. Even after formal draft status, the proposal would still require technical discussion, security analysis, client implementations, testing and selection for a future hard fork before it could reach mainnet.

No target fork, testnet schedule or mainnet deadline has been announced. Early market reaction has been measured, consistent with a technical draft still in early discussion rather than an imminent protocol change.

The deposit-contract proposal addresses only one piece of Ethereum’s staking infrastructure. Broader post-quantum work continues across multiple cryptographic components that underpins the network’s long-term security.