[go: up one dir, main page]
Skip to content
Start

Post-Quantum
Ethereum

Securing the protocol for the next century and beyond.

Overview

Ethereum is designed to serve as resilient, self-sovereign infrastructure — not for decades, but for centuries. Security is one of its non-negotiable properties: things must do what they claim to do, no more and no less. That commitment extends to ensuring Ethereum can withstand fundamental shifts in how the universe processes information.

Quantum computing will eventually break the public-key cryptography that secures ownership, authentication, and consensus across all digital systems. We do not believe a cryptographically relevant quantum computer is imminent. But migrating a decentralized, global protocol takes years of coordination, engineering, and formal verification. The work must begin well before the threat arrives.

Ethereum's approach is grounded in cryptographic agility — the ability to upgrade core primitives without destabilizing the network — and in treating this transition as an opportunity to strengthen the protocol's security, simplicity, and decentralization.

This page outlines the post-quantum work underway across the Ethereum protocol, maintained by the Post-Quantum team within the Ethereum Foundation's Protocol cluster.

View Roadmap Explore FAQ

Protocol Layers

Post-quantum considerations touch every layer of the Ethereum protocol. The transition is not a single event — it is a coordinated, multi-layer migration that will unfold over years.

Execution Layer

Enabling users to transition to quantum-safe authentication through account abstraction, without a disruptive 'flag day.' This includes standardizing post-quantum signature verification via a vector math precompile and supporting gradual, opt-in migration paths.

Roadmap: PQ sig precompiles (J*) → PQ transactions → PQ sig aggregation (M*)

Consensus Layer

Replacing the validator signature scheme (BLS) with post-quantum alternatives — specifically hash-based signatures (leanXMSS) — while preserving block production, gossip efficiency, and finality under increasingly tight timing constraints. Because post-quantum signatures are larger and lack BLS's native aggregation properties, a SNARK-based aggregation approach using a minimal zkVM (leanVM) is being developed to restore scalability.

Roadmap: PQ key registry (I*) → PQ attestations + real-time CL proofs (L*) → full PQ consensus (longer term)

Data Layer

Securing data availability with post-quantum cryptography for post-quantum blob handling. The role of aggregation at the data layer is still being explored.

Roadmap: leanVM (L*) → PQ blobs (M*)

View Full Roadmap →

Roadmap

The EF Protocol Architecture team maintains a living roadmap reflecting rough directional consensus across EF Architecture. Post-quantum milestones are integrated across all three protocol layers — consensus, data, and execution.

I* J* L* M* Future PQ key registry PQ sig precompiles PQ attestations + leanVM PQ aggregation + PQ blobs Full PQ consensus CONSENSUS EXECUTION CONSENSUS + DATA EXECUTION + DATA ALL LAYERS
Fork Milestone Layer
I* PQ key registry Consensus
J* PQ sig precompiles Execution
L* PQ attestations, real-time CL proofs, leanVM Consensus + Data
M* PQ sig aggregation, PQ blobs Execution + Data
Longer term Full PQ consensus, PQ transactions, PQ sampling All layers

The roadmap reflects rough consensus within EF Architecture and is subject to change as research, implementation, and community governance evolve. Final protocol direction is determined through Ethereum's open governance processes (e.g., All Core Devs). For the full roadmap, visit strawmap.org.

View Full Roadmap at strawmap.org →

Resources

Ethereum's Post-Quantum Future

All post-quantum work is developed as open-source public goods.

leanEthereum GitHub org github.com/leanEthereum
leanSpec github.com/leanEthereum/leanSpec
leanSig github.com/leanEthereum/leanSig
leanMultisig github.com/leanEthereum/leanMultisig
leanSig paper eprint.iacr.org/2025/055.pdf
PQ transaction signatures YouTube playlist
PQ interop YouTube playlist
lean Ethereum YouTube playlist
lean Consensus Roadmap leanroadmap.org
EF Protocol L1 Roadmap strawmap.org

Frequently Asked Questions

Disclaimer

The following FAQ reflects the perspective of the Post-Quantum team within the Ethereum Foundation's Protocol cluster. The answers represent the team's current research, analysis, and assessment as of early 2026. The Ethereum Foundation is a non-profit steward supporting the Ethereum ecosystem — it is not Ethereum itself, nor a central authority within the network. The Foundation does not set protocol direction; it coordinates, provides substrate, and offers context that helps anyone who shares its purpose to work together. There is a healthy diversity of views across EF teams and the wider Ethereum community. Protocol direction and upgrades are determined through open community governance processes (e.g., All Core Devs), not by any single team or organization. For more on the Foundation's role and principles, see the EF Mandate.

Understanding the Threat

The risk is concentrated in public-key cryptography — specifically digital signatures (ECDSA, BLS). A sufficiently powerful quantum computer running Shor's algorithm could recover private keys from public keys, enabling forged signatures — meaning theft and impersonation. For Ethereum, this primarily affects EOA keys (secp256k1/ECDSA) and validator keys (BLS). The realistic failure mode is stolen funds and impersonation, not rewriting finalized history. Past transactions and finalized blocks remain valid. Common misconceptions include confusing confidentiality risks with authentication risks. "Harvest now, decrypt later" mainly affects encrypted data, not blockchain signatures. Another frequent misunderstanding is that immediate migration to any post-quantum scheme is obviously safer — rushed deployment of immature cryptography can introduce more risk than it removes.

Most engineering roadmaps place cryptographic relevance in the early-to-mid 2030s, assuming continued progress in error correction, qubit scaling, and manufacturing. Breaking elliptic-curve cryptography would require thousands of stable logical qubits and sustained fault-tolerant operation, far beyond current machines. Two factors make precise timelines uncertain. First, quantum computing is now increasingly an engineering challenge rather than a scientific one. Second, capability will likely emerge gradually: early machines may target a small number of high-value keys rather than break all encryption simultaneously. From a protocol perspective, the critical point is lead time. Upgrading decentralized global infrastructure takes many years. Even if a cryptographically relevant machine is 8–12 years away, preparation must happen now.

In blockchains, this risk mainly affects confidentiality, not ownership. Blockchains are primarily integrity systems built on digital signatures, so recording transactions today does not enable retroactive theft of funds. Where this risk clearly applies is to encrypted data surrounding the ecosystem: private communications, privacy-preserving transaction systems, custody infrastructure, and sensitive off-chain data. For signatures and user funds, the risk is forward-looking. Once a cryptographically relevant quantum computer exists, exposed public keys could be used to derive private keys and authorize new transactions — but past transactions remain unaffected.

Ethereum's Approach

For our team, this has never been framed purely as a problem but more as an opportunity to advance the state of the art in protocol design. Choosing a post-quantum algorithm is only part of the challenge. The harder parts include safely upgrading hundreds of millions of accounts, preventing the migration from introducing new bugs, avoiding new attack surfaces, maintaining performance, and coordinating ecosystem-wide adoption. This is why a parallel formal verification effort is critical. The Protocol Snarkification team at the Ethereum Foundation, led by Alex Hicks, is responsible for the zkEVM Formal Verification Project — a $20M initiative dedicated to formally verifying critical cryptographic components, including the SNARK primitives that underpin post-quantum signature aggregation. This work ensures that the machinery we build behaves exactly as mathematically defined, with no room for deviant execution.

Cryptographic agility avoids premature lock-in while uncertainty remains about which post-quantum schemes will prove secure, efficient, and deployable at global scale. Risks of committing too early include choosing a scheme later weakened by cryptanalysis, performance and DoS issues from large keys, implementation bugs in immature libraries, and lacking a safe rollback path. At the execution layer, account abstraction enables this agility: smart accounts can upgrade signature verification logic without protocol-level intervention. At the consensus layer, the situation is different — validator signature schemes must be far more stable and changed only when clearly necessary.

Work advances on both fronts in parallel. At the execution layer: staged migration roadmap, account abstraction as the central upgrade strategy, evaluation of candidate schemes (Falcon, Dilithium, SPHINCS+), and emergency preparedness. On the consensus side: a new XMSS-based signature scheme (leanXMSS), a Rust implementation (leanSig), a minimal zkVM for aggregation (leanMultisig), and an executable Python specification (leanSpec) currently used by approximately ten client teams building post-quantum consensus clients.

Attack Surface & Risk

In order of priority: (1) User accounts (EOAs) — largest pool of value, public keys exposed after first transaction. (2) High-value operational keys — exchanges, bridges, custody hot wallets. (3) Governance and upgrade keys — admin multisigs controlling protocols. (4) Validator keys — affect consensus participation rather than directly holding assets. The common pattern is concentration of value or control behind exposed, long-lived public keys. The quantum threat does not place all ETH at equal risk — severity depends on migration progress when quantum hardware becomes available.

Accounts that have never revealed a public key are not directly exposed. However, the question of what should be done about funds that cannot or will not migrate is ultimately a community governance question. Two natural scenarios exist: do nothing, or freeze vulnerable coins. Unlike Bitcoin, where roughly 5% of the supply is associated with early address formats widely believed to be abandoned (including Satoshi's ~1M BTC), Ethereum's exposure is closer to 0.1%. This significantly smaller proportion makes the "do nothing" option much more viable for Ethereum than it would be for Bitcoin. Views vary widely within the community. The team's focus is on making migration paths as easy, inexpensive, and widely supported as possible — minimizing the pool of funds that remain unmigrated regardless of which governance path is ultimately chosen.

Implementation & Timeline

No single fixed date. Based on our team's current assessment, L1 protocol upgrades could be completed by 2029, with full execution-layer migration taking additional years beyond that. The transition unfolds across three phases: (1) readiness and infrastructure, (2) gradual adoption, and (3) protocol-level consolidation. For detailed milestone placement, see strawmap.org.

Larger signatures increase bandwidth/storage. Verification is more computationally intensive. BLS's native aggregation has no post-quantum equivalent — SNARK-based methods are being developed. Implementation maturity requires careful auditing and formal verification. Current work focuses on aggregation, proof-based compression, and specialized precompiles to keep the effective onchain footprint manageable.

Larger signatures could increase gas costs. Heavier verification could raise validator operating costs. However, the transition is also an opportunity: SNARK-based aggregation and more efficient networking can offset heavier primitives and potentially improve decentralization. Early preparation is what enables this positive outcome.

Ecosystem & Broader Context

L2 preparedness means securing high-leverage trust points: operational keys (sequencer, admin), bridges and cross-chain messaging, user accounts (via account abstraction), and for zk-rollups, the proof system itself. L2 preparedness relies on upgrading every place where a small number of keys control large amounts of value, while preserving interoperability.

Coordination matters most at chain interfaces — bridges, wallets, custodians, infrastructure providers. Incompatible mechanisms make shared components weak points. Shared standards for signatures, verification, and key management reduce friction. Protocol-level evolution will remain chain-specific. The most effective approach is layered coordination: shared standards where interoperability matters, independent implementation where protocol details differ.

Yes. Moving to PQ cryptography forces cryptographic agility, reducing dependence on any single assumption. The need for efficient handling of larger objects is accelerating research into aggregation and proof-based compression — developed as open-source public goods. Integrating PQ cryptography also encourages redesigning networking and validation paths, creating opportunities to reduce protocol complexity rather than simply replacing one primitive with a heavier one.

Retreat

2nd Annual Post-Quantum
Research Retreat

Cambridge, UK  ·  October 9–12, 2026

Building on the success of the inaugural retreat, we are convening researchers, developers, and institutional stakeholders for a focused week of collaboration on post-quantum cryptography and its implications for decentralized systems.

Researcher Track

Cryptographic foundations, new signature schemes, formal verification, and open research problems

Developer Track

Implementation challenges, multi-client interoperability, devnet engineering, and aggregation systems

Institutional Track

Threat modeling, migration planning, and post-quantum risk assessment for organizations building on or investing in decentralized infrastructure

Space is limited. For questions or to discuss the retreat, contact will@ethereum.org.