May 7, 2026 – Project Eleven, the post-quantum cryptography startup led by CEO Alex Pruden and CTO Conor Deegan, today published “The Quantum Threat to Blockchains — 2026 Report,” a 110-page analysis covering the full landscape of quantum risk to digital assets. The report spans quantum hardware modalities, error correction, resource estimation trends, chain-specific vulnerability profiles, NIST post-quantum cryptography standards, and a detailed blockchain migration framework.
The timing is great. Two days ago, I published an analysis of how pseudoscience and denial have colonized Bitcoin’s quantum security discourse, from a 222-page unreferenced paper claiming Bitcoin’s block interval disproves quantum mechanics, to a panel at Bitcoin 2026 where half the participants dismissed the threat outright. Pruden himself sat on that panel, making the case for urgency while his co-panelists called quantum computing “science fiction.”
This report is the full version of that case. A disclosure before I continue: Project Eleven asked me to review the report before publication, and the report cites my CRQC Quantum Capability Framework as a reference. Separately, Project Eleven sells post-quantum solutions for blockchain systems, so they have a commercial interest in the threat being taken seriously. With both of those on the table: the analytical work here is serious, well-sourced, and in several places genuinely original. For anyone who sat through the Bitcoin 2026 panels and wondered what the science actually says when stripped of ideology, this is a good place to start.
The report’s strongest contribution is its structured framework for thinking about quantum computing progress. It organizes the path to a cryptographically relevant quantum computer (CRQC) into a four-layer stack: physics (qubit quality), error correction (physical-to-logical qubit ratio), system integration (decoder, feed-forward, stability), and algorithm demand (the requirements Shor’s algorithm imposes). This is a useful simplification. Readers familiar with my work will recognize the structure as conceptually aligned with my CRQC Quantum Capability Framework, which the report cites directly. The key insight both frameworks share: progress toward a CRQC is not measured by physical qubit count alone. It is measured across multiple capability dimensions that interact multiplicatively.
The resource estimation analysis is particularly well done. The report traces the dramatic collapse in estimated qubit requirements: from Gidney and Ekerå’s 20 million physical qubits for RSA-2048 in 2021 to Gidney’s under one million in 2025, then to Pinnacle’s 100,000 with qLDPC codes, and finally to the two March 2026 papers that changed the conversation: Google/Babbush’s estimate of fewer than 500,000 superconducting qubits for ECC-256 in approximately nine minutes, and Oratomic’s proposal of just 10,000 neutral atom qubits with runtimes measured in days. The report correctly identifies that these two architectures represent different threat profiles: fast-clock superconducting systems enable “on-spend” attacks against active transactions, while slow-clock neutral atom systems are limited to “at-rest” attacks against dormant wallets and exposed keys. Both paths are credible. Both lead to the same conclusion.
The blockchain-specific vulnerability analysis is thorough. Project Eleven’s own Bitcoin Risq List puts approximately 6.9 million BTC (roughly 33% of circulating supply) in quantum-vulnerable addresses, categorized by exposure mechanism: address reuse (72.3%), Taproot outputs with embedded x-only public keys (24.8%), and legacy P2PK outputs (under 0.01% by count but holding early Satoshi-era coins). For Ethereum, the report cites Deloitte’s finding that over 65% of all Ether sits in quantum-exposed addresses — a broader exposure surface than Bitcoin’s, compounded by the fact that Ethereum’s consensus layer (BLS12-381 signatures) and its data availability sampling commitments (KZG/EIP-4844) are both independently quantum-vulnerable.
The stablecoin analysis deserves separate attention. The report makes a point I have not seen emphasized this clearly elsewhere: a quantum attack on a major stablecoin would not require draining individual wallets. It would target the contract’s admin keys. A compromised minting authority can create unbacked tokens. A compromised proxy admin can rewrite the contract’s logic entirely. Because stablecoin contracts concentrate control in a small number of privileged ECDSA keys that have signed on-chain transactions (and therefore have exposed public keys), the blast radius of a single key compromise is the entire token supply. That is a qualitatively different risk profile from attacking a base-layer protocol.
Two technical contributions stand out as genuinely original.
First, the report highlights an asymmetry in migration prospects between EdDSA and ECDSA chains that deserves wider attention. EdDSA chains (Solana, Sui, Aptos, Near, Stellar) use RFC-8032 key derivation, which computes the signing scalar from a seed via a hash function. If Shor’s algorithm recovers the signing scalar, it cannot reverse the hash to obtain the underlying seed. This structural property could enable post-quantum zero-knowledge proofs of seed ownership, allowing accounts to bind their existing address to a new PQ key without moving funds. ECDSA chains generally lack this property — wallets typically sample the private scalar directly, so Shor’s recovers the complete secret. The practical implication: EdDSA chains may have a meaningfully cleaner migration path. This distinction is sourced to a 2025 IACR ePrint by Baldimtsi et al. and merits closer examination.
Second, PQC Suite B (detailed in Appendix F) is a proposal co-authored by JP Aumasson, Conor Deegan, Alex Pruden, and Zooko Wilcox-O’Hearn to replace the internal hash functions in ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) with BLAKE3. The claimed speedup is 20–30% for signing and verification, with no change to key or signature sizes. For blockchains, where every signature operation sits in the critical path and verification is performed at scale, a pure performance improvement with no size trade-off is worth tracking. Whether NIST engages with this proposal remains to be seen.
The report’s Q-Day model (Appendix E) is transparent about its methodology but should be consumed carefully. It works backwards from a fixed target logical error rate (10⁻¹⁵), calculates the required code distance, and then projects when hardware will reach that distance. The authors acknowledge that this approach inflates code distance relative to published resource estimates, forcing them to compensate with artificially high error suppression factors (5–10, compared to the ~2 observed in recent Google and Quantinuum experiments). This is a modeling choice, not an error, but it means the resulting Q-Day estimates (baseline 2033, optimistic 2030, pessimistic 2042) are less rigorous than bottom-up resource estimates from groups like Google Quantum AI. The sensitivity analysis is informative — physical qubit count and quality dominate, followed by error correction efficiency — but the model’s acknowledged departure from physics at the suppression factor level limits how much weight these specific year estimates should carry. My own CRQC Readiness Benchmark methodology takes a different approach that avoids this particular inflation problem.
I want to return to why the timing of this report matters. Two days ago, I described three archetypes in Bitcoin’s quantum debate: the Deniers, the Grifters, and the Engineers. The Deniers produce sophisticated-sounding arguments for why the threat isn’t real. The Grifters exploit the panic or sell false solutions. The Engineers do the actual work: writing BIPs, benchmarking PQC algorithms, analyzing migration throughput, building the tools the ecosystem will need.
This report is Engineer work. One hundred and ten pages of it. The kind of work that gets drowned out when conference stages are given over to arguments that Bitcoin’s block interval disproves quantum mechanics.
Is it perfect? No. I’ve noted the disclosure above, and the Q-Day model has the methodological limitations I’ve described.
But within its scope — a blockchain-focused audience that needs to understand what quantum computing means for their assets, their protocols, and their migration timelines — this is one of the best single-document summaries I have seen. It synthesizes the key resource estimation papers (Gidney, Pinnacle, Babbush/Google, Oratomic/Cain, Chevignard), contextualizes them within a structured capability framework, applies them to specific blockchain vulnerability profiles, and produces a concrete migration framework with realistic throughput analysis. The appendices, particularly the treatment of Shor’s algorithm variants and the quantum error correction formalism, are detailed enough to serve as reference material.
The blockchain industry has a choice to make. It can listen to people with no physics credentials explain why quantum mechanics is wrong. Or it can engage with the work being done by teams that understand both the cryptography and the engineering.
The deadlines are already set. NIST targets deprecation of all quantum-vulnerable public-key algorithms after 2035. NSA’s CNSA 2.0 sets milestones through 2033. And migration timelines for decentralized protocols are measured in years, not months. The work described in this report is the work that needs to happen. Whether the community chooses to do it is a different question — but at least they can no longer claim they weren’t given the analysis.
The full report is available as a PDF from Project Eleven.
My company - Applied Quantum - helps governments, enterprises, and investors prepare for both the upside and the risk of quantum technologies. We deliver concise board and investor briefings; demystify quantum computing, sensing, and communications; craft national and corporate strategies to capture advantage; and turn plans into delivery. We help you mitigate the quantum risk by executing crypto‑inventory, crypto‑agility implementation, PQC migration, and broader defenses against the quantum threat. We run vendor due diligence, proof‑of‑value pilots, standards and policy alignment, workforce training, and procurement support, then oversee implementation across your organization. Contact me if you want help.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。