Ethereum developers have opened an early proposal to make the staking deposit system flexible enough to accept future quantum-resistant validator keys. The draft, pull request #12235, would give a later network upgrade a one-way switch to stop new deposits using today's BLS format. It's still a draft — unmerged as of Aug. 26 — and hasn't been assigned an EIP number yet.
What the draft changes
The current staking deposit contract expects public keys and signatures in fixed BLS12-381 formats. The draft specification adds a scheme identifier and variable-length fields for the public key and credential metadata, each capped at 8,192 bytes. Under the proposal, the contract would carry non-BLS credentials as opaque data, transporting bytes without checking the new cryptography.
The draft defines three contract modes: disabled, BLS enabled, and BLS retired. Transitions only move forward — once retired mode is activated, BLS deposits are rejected permanently. Deposits that entered the pending queue before the retirement boundary would remain eligible for normal processing under the current consensus framework.
Ethereum says no quantum computer can threaten its cryptography today, and its approximately 2029 target is a planning goal. But the deposit contract is a bottleneck: if a future validator key scheme needs to be adopted, the contract has to be ready to accept it. This proposal creates an entry path for future credential formats, though those formats and verification rules still need to be designed and adopted separately.
The post-quantum roadmap pairs the hash-based validator signature scheme leanXMSS with leanVM, which is intended to aggregate much larger post-quantum signatures efficiently. It separates key registration, signature verification, attestations, and full aggregation into staged milestones.
What's still missing
The proposal does not migrate existing validators; it only affects new deposits. A future credential-scheme proposal would still need to define signature validation, validator-state representation, top-ups, duplicate handling, uniqueness, and key replacement. Activating the deposit path would require a coordinated execution- and consensus-layer fork.
That's a lot of work left. The draft is just the first step — a way to make the deposit contract flexible enough to even consider these changes.
Next steps
Pull request #12235 was opened Aug. 24 and remained an unmerged Draft as of Aug. 26, with its working file still using the placeholder number 9999. An Ethereum EIPs editor suggested assigning EIP-8394, but the proposal has not been published or accepted as EIP-8394. The next concrete move is for the draft to be revised, merged, and formally proposed as an EIP — then the real design work on the credential scheme begins.
