Key highlights:
- Ethereum’s EIP-8450 draft now offers a way for validators to register post-quantum public keys, which helps get prepared for possible security issues caused by quantum computers.
- The new design lets validators use their current BLS signing keys to register or replace keys.
- There’s a minimum replacement delay of 256 epochs, plus replay protection, which together boost the security of these updates.
- EIP-8450 is still just a draft and hasn’t rolled out yet, so these changes aren’t live on Ethereum.
The Ethereum community has posted an updated version of EIP-8450, a proposal that aims to make post-quantum public key registration simpler for validators. The update came out on October 29, 2026 (UTC+8) and brings in a way to manage quantum-resistant public keys as part of Ethereum’s consensus system. The new design uses hash-based cryptography, including leanXMSS keys and a VRF tree root, to help register and handle these keys.
The updated draft also affects how validators authorize key changes. It drops the old system that relied on withdrawal-address paths, execution-layer contracts, and separate authorization queues. Now, it just uses the validator’s regular BLS signing keys for this. Validators need to wait at least 256 epochs before their new key takes effect, and the draft adds replay protection too. Even with these updates, EIP-8450 is still only a draft, and the system isn’t live yet.
EIP-8450 Revises the Process for Registering Post-Quantum Keys
This updated proposal is all about making it easier to register public keys that can handle attacks from quantum computers. Since validator keys are at the centre of how Ethereum keeps its consensus, making sure these keys are ready for quantum threats is a big deal.
In the new design, validators have to provide a new post-quantum public key along with proof when they register. Again, the proposal sticks with hash-based cryptography, leanXMSS keys and a VRF tree root to handle the keys.
The idea is to avoid making validators deal with too many technical details or jump through hoops to register keys. Instead, simplified interface calls do the main work, so the registration process is easier to manage but still keeps the important information needed to check submitted keys.
It’s important to note this proposal is about making space for post-quantum keys in the current validator setup. It doesn’t mean Ethereum has already switched over to signatures that are resistant to quantum attacks.
Existing BLS Keys Will Authorize Registration and Replacement
One of the biggest changes here is how authorization works. The update removes withdrawal-address paths, execution-layer request contracts, and authorization queues. Now, validators can use their regular BLS signing keys to authorize both the registration and replacement of post-quantum public keys.
So, instead of more complicated steps, the process leans on the keys validators are already using today. This should make it simpler for them to update their keys.
There are new safeguards as well. For any key replacement to go through, there’s a minimum waiting period of 256 epochs, which works out to roughly 27 hours. This means that key changes can’t happen instantly. Plus, the proposal adds replay protection, which prevents old messages from being reused in a harmful way.
All these updates work together to set clear rules for registering and updating post-quantum keys. With authorization handled by existing signing keys, a waiting period, and replay protection, the process is more secure and straightforward.
Proposal Remains in Draft Status Without Deployment
Even though these updates cover improvements in registration, authorization, and replacement, EIP-8450 hasn’t gone live. It’s still just a draft, and that means none of these features are actually running on the Ethereum network yet.
Just because it’s published as a draft doesn’t mean there’s been any change to how Ethereum works. The proposal shows one way to handle post-quantum validator keys, but it’s not the finished product or a live change to consensus right now.
The proposal stays focused on how keys are registered and managed, using leanXMSS keys, a VRF tree root, and existing BLS signing keys, plus a simplified interface. But as of now, there’s no sign that validators have actually started using any of this in practice.
