Widely deployed public-key cryptography — specifically the Elliptic Curve Digital Signature Algorithm (ECDSA) and Schnorr signatures on the secp256k1 curve — is built on the mathematical hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP). Shor’s algorithm, running on sufficiently powerful quantum hardware, can solve the ECDLP in polynomial time, reconstructing a private key from a public key. This renders every wallet whose public key is visible on-chain theoretically vulnerable.

1.1  The Harvest Now, Decrypt Later Mode

Adversaries do not need a CRQC to begin exploiting blockchains today. Under the Harvest Now, Decrypt Later (HNDL) model, on-chain public key data is permanently recorded and available for future decryption. Unlike encrypted communications that can be re-secured, blockchain public keys that have ever been exposed cannot be retroactively hidden.

1.2  Threat Classification by Attack Profil

Quantum attacks on blockchain assets fall into two distinct profiles with different urgency and mitigation requirements:

• At-Rest Attacks (Exposed Public Keys): The most severe and immediate category. On blockchains, a public key is permanently recorded when a transaction is broadcast. Vulnerable outputs include early Satoshi-era Pay-to-Public-Key (P2PK) addresses, modern Taproot (P2TR) keypath spends, and any address where keys have been reused. A CRQC could derive private keys from these at leisure, with no time pressure.
• On-Spend Attacks (In-Transit Transactions): A narrower window attack targeting transactions in the mempool. An attacker must derive the private key and broadcast a competing transaction before block confirmation — roughly 10 minutes on Bitcoin and 12 seconds on Ethereum. This requires far more powerful quantum hardware and real-time operation.

2. Bitcoin’s Quantum Exposure: Updated Supply Analysis

Quantifying exactly how much Bitcoin is at risk requires distinguishing between structural exposure (address formats that expose public keys by design) and operational exposure (user behaviour such as key reuse). A recent Glassnode analysis provides the following mapping.

3. NIST Post-Quantum Cryptography Standards: Feasibility and Trade-off

In 2024, the U.S. National Institute of Standards and Technology (NIST) finalised its first set of Post-Quantum Cryptography (PQC) standards. These represent the cryptographic schemes blockchains must migrate to if they are to resist Shor’s algorithm. The standards include:

• ML-DSA (formerly CRYSTALS-Dilithium): A lattice-based digital signature scheme. The primary candidate for blockchain signature migration.
• SLH-DSA (formerly SPHINCS+): A hash-based signature scheme offering extremely conservative, well-understood security assumptions.
• FN-DSA (Falcon): A more compact lattice-based scheme under consideration for Ethereum precompiles.

3.1  Computational Performance

Benchmarking studies (Schemitt et al., October 2025) indicate PQC signature schemes introduce only minor computational overhead at Security Level 1 and can outperform ECDSA at higher security levels. On an ARM-based laptop, ML-DSA achieves signature verification of 0.14ms at Security Level 5, versus 0.88ms for ECDSA. Execution time is not the binding constraint.

3.2  The Critical Bottleneck: On-Chain Size

The binding architectural constraint is the dramatic increase in public key and signature sizes, which cascades into fundamental trade-offs across every layer of blockchain design.

4. Bitcoin’s Post-Quantum Roadmap

The Bitcoin development community has produced two distinct but complementary proposals that together form a two-stage quantum migration roadmap. Critically, these are separate Bitcoin Improvement Proposals (BIPs) and should not be conflated.

4.1  BIP-360: Pay-to-Merkle-Root (P2MR)

BIP-360 was introduced in December 2025, as a first step in advancing Bitcoin quantum resistance. it addresses the at-rest vulnerability by eliminating the keypath spend mechanism that currently exposes public keys on-chain in Taproot outputs.

• The Problem: P2TR (Taproot) outputs include a tweaked public key in plaintext, exposing it to long-range quantum attack via Shor’s algorithm.
• The Solution: BIP-360 introduces a new SegWit version 2 output type (P2MR) that commits directly to the Merkle root of the script tree, with no public key appearing on-chain until a specific script branch executes. Addresses use the bc1z prefix with bech32m encoding.
• Preserved functionality: Lightning Network, BitVM, Ark, and time-lock contracts all remain operational through the P2MR tapscript path.
• Limitation: BIP-360 addresses long-exposure at-rest attacks. It does not protect against short-exposure on-spend attacks, where a quantum computer would need to break a signature within the transaction confirmation window. Full protection requires the future adoption of PQC signature opcodes (Dilithium is implemented in the testnet but not yet formalised in a mainnet BIP).

4.3  Live Testnet: Bitcoin Quantum v0.3.0 

BTQ Technologies launched Bitcoin Quantum testnet v0.3.0 in March 2026 — the first working implementation of BIP-360. As of release:

• Full P2MR consensus with SegWit v2 outputs and bc1z address encoding (bech32m).
• All five Dilithium post-quantum signature opcodes enabled in P2MR tapscript context.
• End-to-end CLI wallet tooling covering address creation, funding, transaction construction, signing, mempool acceptance, broadcast, and confirmation.
• Over 50 miners participating; more than 100,000 blocks processed.

5. Ethereum’s Post-Quantum Roadmap: The Strawmap

In February 2026, Vitalik Buterin published Ethereum’s post-quantum roadmap — rebranded as the Strawmap — identifying four distinct cryptographic layers requiring post-quantum upgrades. The approach is more structured than Bitcoin’s, targeting core infrastructure completion by 2029 across approximately seven hard forks.

The four vulnerable layers are: (1) consensus-level BLS validator signatures; (2) KZG-based data availability commitments; (3) ECDSA account signatures (the execution layer); and (4) ZK-proof systems relying on elliptic curve pairings.

5.1  Execution Layer: Signature Agility via Native Account Abstraction

Rather than a mandatory wallet-replacement hard fork, Ethereum’s execution-layer strategy relies on account abstraction to enable voluntary, gradual migration:

• EIP-7702 (deployed in Pectra, May 2025): Allows externally owned accounts (EOAs) to temporarily execute smart contract code, unlocking transaction batching, gas sponsorship, and social recovery — a stepping stone to full account abstraction.
• EIP-8141 (Frame Transactions): Under consideration for the Hegotá hard fork (planned H2 2026). Introduces native protocol-level account abstraction, splitting transaction execution into VERIFY, SENDER, and DEFAULT stages. This allows users to swap signature schemes from ECDSA to ML-DSA or Falcon without abandoning their accounts.
• Gas precompiles: EIP-8051 (ML-DSA) and EIP-8052 (Falcon-512) propose precompiled contracts to reduce PQC verification from ~1.8M gas to ~3,000 gas — a prerequisite for economically viable PQC transactions.

5.2  Consensus Layer: leanXMSS and leanV

Ethereum’s 500,000+ validators currently use BLS signatures, whose native mathematical aggregation compresses thousands of signatures into a single compact object. Post-quantum schemes lack this property. Without aggregation, un-aggregated PQC validator signatures would increase network bandwidth requirements to megabytes per slot, pricing out home validators.

• leanXMSS: Ethereum will replace BLS with leanXMSS, an optimised hash-based signature scheme for validators. Hash-based security relies on the security of hash functions rather than mathematical problems quantum computers are expected to solve.
• leanVM: A minimal zero-knowledge virtual machine (zkVM) generating SNARK-based proofs of ML-DSA and leanXMSS batch verifications, achieving approximately 250× compression of PQC validator signatures into a single compact proof. Preserves home-validator decentralisation.
• A leanSig Rust implementation and executable Python specification (leanSpec) are currently being used by approximately ten client teams building post-quantum consensus clients on dedicated devnets (pq-devnet-3, pq-devnet-4).

5.3  Emergency Hard Fork Contingency

In the event of an unexpected Q-Day event ahead of the migration schedule, Ethereum maintains a documented emergency contingency plan:

1. Revert the blockchain to a pre-attack block height.
2. Suspend all traditional EOA transactions.
3. Force all unmigrated accounts to transition to smart contract wallets using hash-based signature verification.

6. Comparative Roadmap and Broader Ecosystem

6.2  Other Blockchains: Who Is Already Ahead

Bitcoin and Ethereum are not alone in facing the quantum transition — nor are they the fastest movers:

• QRL (Quantum Resistant Ledger): Has used hash-based signatures (XMSS) since its genesis block in 2018. Never used elliptic curve cryptography. The reference implementation for a fully quantum-resistant Layer 1.
• Algorand: Successfully implemented Falcon-512 in production in its September 2024 (v4.3.0) consensus upgrade, adding falcon_verify as a native AVM opcode. The strongest proof point that PQC signature verification can operate efficiently at scale on a production Layer 1.
• QANplatform and Hedera: Running NIST-approved Dilithium signatures in live environments.
• Zcash: Committed to a concrete 2027 timeline for quantum-proof wallets.
• XRPL: Assessed in May 2026 as potentially the furthest along of any top-10 blockchain in concrete post-quantum implementation, with native credential and identity features designed for compliance and institutional adoption.

The existence of these production deployments is significant: it demonstrates that PQC blockchain operation is not theoretical. The constraint for Bitcoin and Ethereum is not technical feasibility — it is governance coordination and migration scale.

8. Key Risks and Open Questions

Despite significant progress, several fundamental challenges remain unresolved:

• The Satoshi coin problem: Approximately 1.1M BTC in Satoshi-era P2PK addresses cannot be voluntarily migrated. Any protocol-level decision about these coins (freezing, burning, or preserving)  will be one of the most contested governance decisions in Bitcoin’s history.
• Bitcoin’s upgrade velocity: BIP-360 is a draft. Bitcoin Core has made no implementation progress toward mainnet. Given historical upgrade timelines of 7–8+ years for SegWit and Taproot, the window for orderly migration before Q-Day may be tight even if hardware timelines slip.
• Ethereum L2 coverage: The Strawmap does not currently address L2 wallet security. Most Ethereum users transact on L2s, meaning the base-layer PQC migration may secure settlement without securing user funds.
• Economic viability of PQC transactions: Even with precompiles, PQC transactions will be larger and more expensive than ECDSA transactions. User incentives to migrate voluntarily are unclear without regulatory pressure or visible quantum threat.
• ZK-proof system vulnerability: Many popular ZK-proof systems (SNARKs using elliptic curve pairings) rely on quantum-vulnerable mathematical assumptions. The migration of rollup proof systems — not just signatures — is a separate, complex engineering challenge.
• Supply chain attacks during migration: The migration period itself introduces risk. Hybrid systems (supporting both ECDSA and PQC) expand the attack surface and must be carefully designed to avoid downgrade attacks.

9. Conclusion

The quantum threat to blockchain cryptography is real, but the timeline remains measured in years rather than months. The Google whitepaper should be read as a precise calibration of the threat — not a declaration of imminent attack. The gap between demonstrated quantum hardware (approximately 28 logical qubits) and the attack threshold (1,200–1,450 logical qubits) remains enormous and involves challenging engineering problems.

What has fundamentally changed is the planning calculus. The 20× compression in resource estimates converts Q-Day from a generational concern into a medium-term institutional risk. Organisations holding significant Bitcoin or Ethereum (such as exchanges, custodians, sovereign wealth funds, tokenized asset platforms) should now treat PQC migration readiness as part of their risk management frameworks.

Both Bitcoin and Ethereum have technically credible migration paths. Bitcoin’s path (BIP-360 + BIP-361) is architecturally elegant but faces severe governance and adoption obstacles. Ethereum’s Strawmap is more structured and centrally coordinated, targeting 2029 for core infrastructure completion, but leaves the L2 ecosystem, where most value transacts, without a clear PQC plan.

The broader lesson from blockchains that are already quantum-resistant (Algorand’s Falcon-512 in production, QRL’s XMSS from genesis) is that the technology works at scale. The remaining challenges are human, not cryptographic: governance consensus, user migration incentives, and the politically charged question of what to do with the legacy coins of those who cannot or will not migrate.