# Post-Quantum Ethereum — Full Content > Securing the Ethereum protocol for the post-quantum era. > Website: https://pq.ethereum.org > Organization: Ethereum Foundation — Post-Quantum Team --- ## 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. --- ## Protocol Layers ### 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*) --- ## 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. | 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. Final protocol direction is determined through Ethereum's open governance processes (e.g., All Core Devs). Full roadmap: https://strawmap.org --- ## Resources All post-quantum work is developed as open-source public goods. - leanEthereum GitHub org: https://github.com/leanEthereum - leanSpec: https://github.com/leanEthereum/leanSpec - leanSig: https://github.com/leanEthereum/leanSig - leanMultisig: https://github.com/leanEthereum/leanMultisig - leanSig paper: https://eprint.iacr.org/2025/055.pdf - lean Consensus Roadmap: https://leanroadmap.org - EF Protocol L1 Roadmap: https://strawmap.org --- ## Frequently Asked Questions ### Understanding the Threat **What cryptographic risk does quantum computing introduce for blockchains?** 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. **When is a cryptographically relevant quantum computer likely to arrive?** 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. From a protocol perspective, the critical point is lead time. Upgrading decentralized global infrastructure takes many years. **How should we think about "harvest now, decrypt later" in the blockchain context?** 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. For signatures and user funds, the risk is forward-looking. ### Ethereum's Approach **Is quantum risk primarily a cryptography problem or a systems-design challenge?** 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. The harder parts include safely upgrading hundreds of millions of accounts, preventing the migration from introducing new bugs, and coordinating ecosystem-wide adoption. The Protocol Snarkification team is responsible for the zkEVM Formal Verification Project — a $20M initiative dedicated to formally verifying critical cryptographic components. **Why prioritize cryptographic agility over committing to a specific scheme now?** 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. **How is work prioritized between execution layer and consensus layer?** 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 minimal zkVM for aggregation (leanMultisig), and an executable Python specification (leanSpec). ### Attack Surface & Risk **Which risk surfaces are most concerning under future quantum capability?** In order of priority: (1) User accounts (EOAs), (2) High-value operational keys, (3) Governance and upgrade keys, (4) Validator keys. The quantum threat does not place all ETH at equal risk — severity depends on migration progress when quantum hardware becomes available. **What about long-dormant funds and abandoned wallets?** Accounts that have never revealed a public key are not directly exposed. Ethereum's exposure is closer to 0.1%, significantly smaller than Bitcoin's ~5%. The team's focus is on making migration paths as easy, inexpensive, and widely supported as possible. ### Implementation & Timeline **What is the expected timeline for a post-quantum transition?** 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. Detailed milestones: https://strawmap.org **What are the main technical constraints limiting PQ deployment onchain?** Larger signatures increase bandwidth/storage. Verification is more computationally intensive. BLS's native aggregation has no post-quantum equivalent. Current work focuses on aggregation, proof-based compression, and specialized precompiles. **What are the economic trade-offs of migrating to post-quantum cryptography?** Larger signatures could increase gas costs. However, SNARK-based aggregation and more efficient networking can offset heavier primitives and potentially improve decentralization. ### Ecosystem & Broader Context **How do L2s and rollups need to upgrade for post-quantum security?** L2 preparedness means securing operational keys, bridges, user accounts (via account abstraction), and for zk-rollups, the proof system itself. **How important is cross-chain coordination on post-quantum standards?** Coordination matters most at chain interfaces. Shared standards for signatures, verification, and key management reduce friction. The most effective approach is layered coordination. **Does quantum computing create new opportunities for blockchains?** Yes. Moving to PQ cryptography forces cryptographic agility, reducing dependence on any single assumption. It accelerates research into aggregation and proof-based compression, and encourages redesigning networking and validation paths. --- ## 2nd Annual Post-Quantum Research Workshop - Location: Cambridge, UK - Dates: October 10–12, 2026 - Agenda: https://pq.ethereum.org/cambridge/ - Contact: will@ethereum.org Building on the success of the inaugural workshop, we are convening researchers, developers, and institutional stakeholders for a focused week of collaboration on post-quantum cryptography and its implications for decentralized systems. --- ## Contact - Ethereum Foundation Post-Quantum Team - Email: will@ethereum.org - Website: https://pq.ethereum.org - GitHub: https://github.com/leanEthereum