Share
Ethereum researcher Kevaundray Wedderburn opened a draft Ethereum Improvement Proposal (EIP) on GitHub on August 24, 2026, proposing a new validator deposit contract designed to support post-quantum cryptographic keys alongside today’s Boneh–Lynn–Shacham (BLS) signatures eventually.
New EIP!
Post-quantum-ready deposit contract
Highlights:
– Introduces a new validator deposit contract that supports variable-length `pubkey` and `credential_metadata` fields (each capped at 8192 bytes) plus an explicit `scheme` identifier; scheme 0…— ethresearchbot (@ethresearchbot) August 24, 2026
The proposal is an early step in a question the Ethereum protocol has not yet had to answer under real pressure: what happens to billions of dollars in staked ETH if BLS signatures, the cryptography securing every validator on the network, become breakable?
The design replaces the current Merkle-tree deposit mechanism with execution-layer requests under EIP-7685, the same request framework already used elsewhere in the Ethereum protocol. It introduces a scheme identifier so different cryptographic key types can coexist within the same contract, with scheme 0 reserved permanently for today’s BLS deposits. New schemes could be added later without redesigning the contract again, which is the proposal’s forward-compatibility goal.
The contract also defines an irreversible, one-way switch. Deposits start disabled, then become BLS-enabled at a set activation timestamp, then permanently retire BLS deposits at a second, later timestamp that cannot be reversed once triggered.
Consensus-layer processing for existing BLS deposits stays completely unchanged under the proposal, meaning current validators and staking infrastructure aren’t affected by anything in this EIP at its current stage.
What the GitHub page itself makes clear is worth stating plainly: this is a draft pull request, not an accepted or scheduled protocol upgrade. It’s awaiting review from four named EIP editors, carries labels marking it as waiting on both editor consensus and continuous-integration checks, and the automated build currently reports errors in the commit.
Wedderburn’s description calls much of the content boilerplate explaining the underlying mechanics, consistent with a proposal at the earliest stage of Ethereum’s improvement process rather than an imminent change.
That distinction matters for how readers should weigh this. Ethereum EIPs typically move through months or years of discussion, editor review, and testnet activity before any activation on mainnet. This one has no assigned hard fork and no activation timeline. It’s a first formal step, not a countdown.
The forward-compatibility framing is deliberate. No working quantum computer currently threatens BLS signatures, and credible estimates for when one might place Ethereum’s cryptography at real risk generally run years into the future, if not longer.
The point of proposing a deposit contract that can hold multiple key schemes now is that Ethereum’s validator set is large, expensive to migrate, and difficult to change quickly once billions of dollars in stake depend on a fixed cryptographic scheme. Building the container years before the contents exist is the more tractable engineering problem.
Ethereum isn’t alone in treating this as a live design question rather than a distant hypothetical. National Institute of Standards and Technology (NIST) finalized its first post-quantum cryptographic standards in 2024, and major blockchain networks have increasingly discussed migration paths as part of longer-term protocol roadmaps rather than emergency responses. This EIP fits that pattern: a technical foundation laid well ahead of need, not a reaction to an active threat.
The proposal still needs to clear editor review, pass its own Continuous Integration (CI) checks, and survive the broader community discussion that shapes which EIPs make it into an actual upgrade. Wedderburn opened it as a draft on August 24. The next milestone worth watching is whether it moves to Review status at all.
Share
preferred on
