EIP-8450 is the first concrete protocol proposal for preparing Ethereum’s validators for quantum computers. The idea: every validator stores an additional, quantum-safe key in the beacon state today, and that key stays unused for now. Only a later fork would switch actual validator duties to these keys. Since October 28, 2026, a revised version has also been up for review as a pull request, and it simplifies the draft considerably.
One thing up front: EIP-8450 is a draft and has not been assigned to any network upgrade yet. It is still worth a look for stakers, pool operators and client developers, because it shows how the migration could work in practice.
Key Takeaways
- EIP-8450 (“Post-Quantum Validator Key Registry”) was created on October 15, 2026; its authors include Ethereum Foundation researcher Justin Drake.
- Validators register a hash-based leanXMSS key that stays dormant: it signs no duties in this fork, and BLS remains in use.
- Registration is meant to show how much stake is ready for the switch and to create a trusted fallback if BLS breaks earlier than expected.
- The October 28 revision drops the withdrawal-address path, adds builders and limits key changes to once every 256 epochs.
- No date is set. The Ethereum Foundation is aiming for full L1 quantum resistance by December 2029.
Why Ethereum needs new validator keys
According to the EIP text, every consensus-layer signature today is a BLS12-381 signature: attestations, block proposals, RANDAO reveals, sync committee messages, voluntary exits and more. BLS relies on the hardness of discrete logarithms in pairing-friendly groups, which is exactly what Shor’s algorithm breaks on a large enough quantum computer. Such a “cryptographically relevant quantum computer” (CRQC) could derive a secret key from a public key, and every validator’s public key sits in the beacon state.
No such machine exists today, and when or whether one will arrive is uncertain. The problem for a decentralized network is lead time: generating new keys requires new tooling and, for staking pools, coordination between node operators and stake owners. We covered the wider debate around quantum risk for Ethereum and Bitcoin in our piece on Justin Drake’s view on ECDSA and quantum computers.
What EIP-8450 actually proposes
EIP-8450 splits the move away from BLS into two forks. In the first fork, the one this proposal describes, each validator registers a hash-based key bound to its existing validator index. The scheme is leanXMSS, a two-layer variant of the stateful signature scheme XMSS (RFC 8391): a top tree of 216 one-time keys certifies bottom trees of another 216 one-time keys each, for a total of about 4.29 billion (232) leaf indices. Hashing uses Keccak-256.
Each registration carries a proof of possession, a signature made with the new key. That lets clients exercise the verification logic before any duty depends on it, and it stops anyone from copying another validator’s published key. The authors list four benefits of the two-fork approach:
- Preparation: validators generate and register keys with tooling tested on mainnet while BLS stays in force.
- A readiness signal: the share of registered stake can be read from the state, so the switch can be scheduled against an observed threshold.
- A recovery anchor: keys registered while BLS is secure are authentic. If BLS breaks before the switch, the chain can move to them.
- Early implementation: client teams work with the hash function, the verifier and the data structures before they become critical.
The draft sets clear limits for the network and the state: at most eight registrations per block, adding about 20 KiB per block. At full capacity, one million validators would need 125,000 blocks, or about 17 days. The security claim is 127 bits of classical security, proven formally in Lean 4, with a target of 64 bits of quantum security (NIST level 1), which the authors explicitly note is not a proven bound.
The EIP-8450 revision in detail
The version published on eips.ethereum.org offers two registration paths: through the validator’s BLS signing key (register only, no replacement) or through the withdrawal address via a new execution-layer request (register and replace). Pull request #12592, opened on October 28, changes this fundamentally:
- The withdrawal-address path is gone. Only the BLS signing key authorizes registrations, and it can replace registered keys at most once every 256 epochs (roughly 27 hours). A field recording the epoch of the last change protects against replay.
- According to the new text, the proposal therefore no longer needs any execution-layer change; registration becomes a consensus-layer operation only.
- Besides validators, builders (from EIP-7732) would also register a leanXMSS key, because their bids are signed with BLS as well.
- Validators additionally commit to the root of a hash-based VRF tree for verifiable randomness.
- The draft now specifies the cryptography only through an interface; leanXMSS, with 32-byte public keys and 2,404-byte signatures, points to an external implementation.
The pull request is still open (as of October 29), and so is a companion draft in the consensus-specs repository. A lot can still change before it is merged.
Where EIP-8450 sits on the roadmap
According to the Ethereum Foundation’s protocol priorities published in September, Ethereum L1 should be quantum-resistant across all three layers, execution, consensus and data, by December 2029. The post-quantum public-key registry is slotted into the fork labeled “I*”, and a “minimum viable” post-quantum milestone is planned for the following fork, “J*”. The Foundation itself calls the schedule “quite aggressive” and plans to reassess quantum progress with outside experts in January 2027. For planning purposes it deliberately assumes a CRQC could exist as early as 2030, while acknowledging that most credible estimates are later.
What stakers and operators should know now
There is no need to act yet: EIP-8450 is a draft, and even after activation existing BLS keys would keep signing every duty. According to the EIP, validators that never register are unaffected by this fork. The logic for later is worth noting, though: the text recommends registering early, because a registration is only as trustworthy as the BLS signature that authorizes it. A registered key also does not prove that a validator will operate correctly on switch day, so the switch should be scheduled with a margin above the two-thirds threshold needed for finality.
Key management becomes more demanding for operators. With stateful schemes like XMSS, each leaf index may sign only one message; signing two different messages with the same index enables forgeries. The seed should not be derived from the BLS key, and losing the signer state is a risk. We looked at how fragile cryptographic assumptions can become in our article on the “bunker mode” for Bitcoin and Ethereum.
Bottom line
EIP-8450 is a sober, technical step: Ethereum wants to collect quantum-safe keys long before they are needed and make the eventual switch plannable. The October 28 revision makes the draft leaner, but it moves control entirely to the operator’s BLS key. Whether and when the proposal ships depends on reviews, client implementations and the fork roadmap. For stakers, that means watching, not acting, for now.
