PQC for Blockchain 2026: How Bitcoin and Ethereum Are Preparing for Quantum Threats
Every major blockchain in production relies on the same elliptic curve that Google’s March 2026 whitepaper put directly in the quantum crosshairs. Bitcoin, Ethereum, Solana, and 22 of the top 26 blockchain networks by market capitalization use ECDSA or related elliptic curve signature schemes — the same mathematical structure that the Google Quantum AI team demonstrated can be broken with fewer than 500,000 physical qubits, a 20-fold reduction from prior estimates. [1]
The quantum threat to blockchain is not a new concern, but it became a compliance-grade planning issue in March 2026. This article explains the specific vulnerability, the unique risk factor that makes blockchain more exposed than conventional cryptographic infrastructure, and the migration proposals — BIP-360, BIP-361, and EIP-8141 — that the Bitcoin and Ethereum developer communities have advanced in response to PQC for blockchain readiness.
TECHNICAL DISCLAIMER: This article is for educational and informational purposes only. It does not constitute financial, investment, legal, or cybersecurity advice. Cryptocurrency holdings carry substantial risk. Protocol proposals discussed (BIP-360, BIP-361, EIP-8141) are active drafts and have not achieved consensus or mainnet activation as of May 2026. Readers should not make financial decisions based on protocol proposals that may change or fail to activate.
How the Quantum Threat Reaches Blockchain Directly
Bitcoin and Ethereum use secp256k1 ECDSA — a specific elliptic curve digital signature algorithm — to secure every wallet transaction. When a holder sends cryptocurrency, their wallet uses a private key to create a cryptographic signature that proves ownership without revealing the private key itself. The security of this system depends entirely on the computational hardness of the elliptic curve discrete logarithm problem (ECDLP): deriving a private key from its corresponding public key is computationally infeasible for classical computers. [2] Shor’s algorithm running on a sufficiently powerful quantum computer solves the ECDLP efficiently — and Google’s March 2026 paper, co-authored with the Ethereum Foundation and Stanford University, showed that the qubit threshold for that attack is lower than any prior estimate.
The Bitcoin quantum threat has a dimension that no conventional cryptographic system shares: the public ledger problem. Unlike enterprise TLS sessions, where encrypted traffic is captured by an adversary and stored for later decryption, blockchain networks publish every transaction — including the public keys used to authorize them — on a globally replicated, permanently available ledger.
There is no capture required. Any address that has ever broadcast a public key on-chain is permanently exposed to quantum risk. Project Eleven, a security group focused on digital asset quantum risk, estimates that approximately 7 million BTC — roughly $470 billion at March 2026 prices — sits in addresses whose public keys are already permanently exposed on-chain. [3] As of March 1, 2026, addresses with exposed public keys represent more than 34 percent of all Bitcoin in circulation. [4]
Grover’s algorithm presents a secondary, lower-urgency threat. It provides a quadratic speedup for brute-force search operations, effectively halving the bit-security of hash functions. For SHA-256 — Bitcoin’s proof-of-work and transaction commitment algorithm — this reduces 256-bit security to approximately 128-bit security against a quantum attacker. [5] While 128-bit symmetric security remains practically unbreakable under current analysis, the mining centralization implications of asymmetric quantum speedups in proof-of-work competition raise separate governance concerns beyond the scope of this article.
Table 1: Quantum Vulnerability Profile of Major Blockchain Networks — May 2026
| Network | Signature Scheme | Quantum Attack Vector | Exposed Address Estimate | PQC Migration Status |
| Bitcoin | secp256k1 ECDSA + Schnorr | Shor’s algorithm — private key derivation | ~34% of BTC in exposed addresses | BIP-360 testnet (BTQ Technologies, early 2026); BIP-361 draft |
| Ethereum | secp256k1 ECDSA (accounts); BLS (consensus) | Shor’s algorithm — account + validator key theft | All accounts with prior transactions | Glamsterdam fork H1 2026; EIP-8141 targeting Hegotá H2 2026 |
| Solana | Ed25519 | Shor’s algorithm — variant elliptic curve attack | All wallet public keys on-chain | No published mainnet PQC roadmap as of May 2026 |
| XRP Ledger | secp256k1 ECDSA / Ed25519 | Shor’s algorithm | All accounts with prior transactions | ML-DSA running on AlphaNet; full transition targeted 2028 |
| Bitcoin derivatives (LTC, BCH) | secp256k1 ECDSA (inherited) | Shor’s algorithm | Proportional to address reuse rate | Dependent on Bitcoin upstream changes |
| Hedera (HBAR) | ECDSA secp256k1 + Ed25519 | Shor’s algorithm | All accounts with prior transactions | Active PQC roadmap; NIST PQC standard alignment confirmed |
Bitcoin’s Quantum Migration Proposals: BIP-360 and BIP-361
Bitcoin’s governance model — deliberate, conservative, and requiring broad community consensus before any protocol change — both protects the network from hasty modifications and constrains how quickly PQC for blockchain can be deployed. Historical precedent is instructive: SegWit took approximately four years from proposal to activation; Taproot required three years of discussion before lock-in. BIP-360 co-author Ethan Heilman has estimated that a complete Bitcoin migration to quantum resilience would take seven years from the day consensus forms — a timeline that does not yet have a start date.
BIP-360: Quantum-Resistant Address Format (P2MR)
BIP-360 proposes a new address type — Pay-to-Multiple-Algorithms (P2MR), identifiable by the bc1z address prefix — that supports quantum-resistant signature verification. [6] BTQ Technologies deployed a testnet implementation in early 2026, demonstrating that the technical mechanism functions. Three critical constraints apply. First, BIP-360 has not been activated on the Bitcoin mainnet and requires a soft fork consensus process. Second, it does not protect existing addresses automatically — holders must actively move funds into new P2MR addresses to gain quantum resistance.
Coins in legacy address types remain exposed until moved. Third, the proposal does not specify which post-quantum signature algorithm to use, leaving that selection for subsequent BIPs. Several candidates are under discussion, with hash-based signature schemes and ML-DSA both being evaluated against Bitcoin’s signature size and transaction throughput constraints.
BIP-361: Phased Migration and Legacy Signature Sunset
BIP-361, formally assigned on February 11, 2026, and co-authored by Casa CTO Jameson Lopp among five others, proposes a three-phase Bitcoin quantum threat migration with defined timelines and a controversial enforcement mechanism. [7] Under the proposal’s draft structure: Phase A would block new sends to quantum-vulnerable address types after a defined period following the availability of quantum-resistant outputs. Phase B would block spending from existing quantum-vulnerable addresses after an additional window. Phase C provides a potential recovery mechanism for addresses whose holders failed to migrate.
The enforcement mechanism — effectively freezing unmigrated coins — is the most contentious element. Critics argue it punishes holders who cannot be reached, including those who have lost access to keys, deceased holders, and those unaware of the migration requirement. Proponents argue that without a sunset mechanism, vulnerable addresses represent a permanent systemic risk that cannot be eliminated voluntarily.
Ethereum’s Post-Quantum Roadmap: The Strawmap and EIP-8141
Ethereum’s approach to PQC for blockchain is architecturally more complex and more explicitly planned than Bitcoin’s. Vitalik Buterin’s February 2026 roadmap document — informally called the Strawmap — identified four distinct cryptographic layers requiring migration: consensus-level BLS signatures used by validators; KZG polynomial commitments underpinning data availability; ECDSA-based account signatures; and zero-knowledge proof systems, many of which rely on pairing-friendly elliptic curves that carry their own quantum vulnerability profile. [8] Replacing all four layers simultaneously without disrupting a network with more than $200 billion in locked value requires extraordinary coordination — and the Ethereum Foundation’s explicit strategy is phased, incremental migration through sequential hard forks rather than a single cutover event.
The Ethereum Foundation launched pq.ethereum.org in March 2026 as a dedicated hub consolidating more than eight years of post-quantum research into a public roadmap, with more than ten client teams running weekly post-quantum interoperability development networks. [9] Two 2026 hard forks are confirmed as early migration steps. The Glamsterdam fork, targeting H1 2026, introduced initial PQC-compatible infrastructure. The Hegotá fork, planned for H2 2026, is the primary vehicle for EIP-8141 — the account abstraction proposal that enables the Ethereum post-quantum migration at the account level without requiring a single protocol-wide cutover.
EIP-8141, building on the account abstraction framework established by ERC-4337 and EIP-7702, allows individual Ethereum accounts to define their own signature verification logic through smart contracts. [10] Under this model, a holder can migrate their account from secp256k1 ECDSA to an ML-DSA or hash-based signature scheme without waiting for the entire network to switch simultaneously. Each account migrates on its own schedule. The consensus-layer migration — replacing BLS validator signatures with hash-based alternatives, specifically leanXMSS — runs on a separate track and is targeted for completion as part of the broader seven-fork Strawmap program, with core post-quantum infrastructure completion targeting approximately 2029. These are planning targets, not guaranteed commitments.
Table 2: Ethereum Post-Quantum Migration Roadmap — 2026 to 2029
| Layer | Current Algorithm | Quantum Vulnerability | Proposed Replacement | Target Fork / Timeline |
| Account signatures | secp256k1 ECDSA | Private key derivation via Shor | ML-DSA or hash-based via EIP-8141 | Hegotá fork, H2 2026 |
| Consensus (validators) | BLS-12-381 signatures | Pairing-based — Shor variant | leanXMSS (hash-based) | Post-Hegotá forks, 2027–2028 |
| Data availability | KZG polynomial commitments | Discrete log — Shor variant | STARKs (hash-based proofs) | Multi-fork, 2027–2029 |
| ZK proof systems | Pairing-based elliptic curves (BLS12-381) | Short variant attack on pairings | Recursive STARKs / leanVM | Later Strawmap forks, 2028–2029 |
| TLS / P2P network layer | ECDHE / TLS 1.3 | Key exchange — Shor | ML-KEM hybrid (infrastructure config) | Configuration update — no hard fork required |
What Institutional Holders and Blockchain Operators Need to Know in 2026
For institutional holders, custodians, and blockchain application operators, the quantum-resistant cryptocurrency migration creates three categories of near-term obligation independent of when protocol upgrades activate.
Address Reuse Risk
The most immediate, actionable risk for any holder is address reuse. Addresses that have never broadcast a public key — that is, addresses that have received funds but have never been used to send — are protected by an additional hash layer. Even if an adversary can break secp256k1 on a quantum computer, they cannot derive the private key without the public key, and the public key is not revealed until the address signs its first transaction.
Addresses that have sent at least one transaction have permanently exposed their public key on-chain. [11] Institutional custodians and wallets should audit their address inventory for reuse patterns and implement policies preventing the reuse of any address that has signed a transaction. This does not require waiting for BIP-360 or any protocol upgrade — it is a key management practice available today.
Custodian and Exchange Exposure
Exchanges and custodians holding assets on behalf of clients typically consolidate funds into a smaller number of high-value addresses. These addresses are active signers by necessity — they send transactions frequently — and by definition carry exposed public keys. The concentration of value in a small number of quantum-exposed addresses makes institutional custodians a structurally elevated target category. Custodians should request quantum migration roadmaps from their wallet infrastructure vendors and HSM providers, and monitor BIP-360 and BIP-361 progression for timeline signals that determine when P2MR address migration becomes a contractual obligation to client assets.
Smart Contract and Protocol Operator Exposure
Smart contract platforms and DeFi protocol operators face the Ethereum post-quantum migration from a different angle. Many protocols rely on ECDSA signature verification within their contract logic for authorization, multisig schemes, or oracle attestation. EIP-8141’s account abstraction mechanism provides the migration path for externally owned accounts, but contracts that hardcode ECDSA verification logic will require explicit upgrades — not automatic migration. Protocol teams should audit their contract code for hardcoded elliptic curve signature verification and begin planning the upgrade path that EIP-8141 enables.
Table 3: Blockchain Quantum Risk and PQC Migration Priority Matrix by Stakeholder
| Stakeholder Type | Primary Quantum Risk | Urgency | Key Action Available Today | Waiting For |
| Individual Bitcoin holder (legacy address) | Exposed public key — Shor attack on secp256k1 | Medium | Move to a new address after each transaction; avoid address reuse | BIP-360 mainnet activation for full P2MR protection |
| Institutional custodian/exchange | High-value addresses with exposed public keys; HSM key exposure | High | Audit address reuse; request vendor PQC roadmaps; monitor BIP-360 timeline | Vendor HSM PQC support + BIP-360/361 activation |
| Ethereum validator operator | BLS consensus key exposure | Medium | Monitor Ethereum Foundation roadmap; plan leanXMSS transition timeline | Consensus-layer Strawmap fork (2027–2028) |
| Smart contract developer | Hardcoded ECDSA verification in contract logic | Medium-High | Audit contracts for ECDSA dependencies; design EIP-8141-compatible upgrade paths | EIP-8141 activation in Hegotá fork (H2 2026) |
| DeFi protocol/bridge operator | Cross-chain signature verification; oracle key exposure | High | Crypto-agility audit across all signature dependencies | Multi-chain PQC coordination across bridged networks |
| Blockchain application developer | secp256k1 key generation in the application layer | Medium | Adopt ML-DSA for new application-layer signature schemes where protocol-independent | Protocol-level PQC activation for wallet integration |
Counter-Arguments
Objection: No quantum computer can break secp256k1 today. This is a distant threat that blockchain developers will resolve before it becomes real.
Discussion: The objection is accurate in its first clause and uncertain in its second. No quantum computer capable of breaking secp256k1 exists in 2026. However, the relevant risk window for blockchain is not Q-Day itself — it is the point at which a quantum computer can break a key within the time window of a single transaction. Bitcoin’s block confirmation time is ten minutes. Google’s optimized circuit completes the ECDLP-256 attack in approximately nine minutes under highly idealized fault-tolerant conditions.
The margin between theoretical attack speed and transaction window is already narrow in the best-case model. More significantly, for addresses with already-exposed public keys, no transaction window exists — the public key is permanently on-chain and can be attacked at leisure once a CRQC exists. Developer resolution requires consensus, and Bitcoin’s governance history suggests seven-plus years from consensus formation to full migration.
Objection: Bitcoin’s Taproot upgrade already improved security. The post-quantum threat to Bitcoin is overstated.
Discussion: Taproot introduced Schnorr signatures, which provide efficiency and privacy benefits over legacy ECDSA. However, Schnorr signatures on the secp256k1 curve carry the same quantum vulnerability as ECDSA — both depend on the hardness of the elliptic curve discrete logarithm problem, which Shor’s algorithm solves. Google’s March 2026 researchers specifically noted that Taproot’s design choices may increase quantum exposure by making public key exposure more routine across transaction types. Taproot addresses the classical security and privacy properties of Bitcoin transactions; it does not address their post-quantum vulnerability profile.
Objection: Ethereum’s account abstraction approach with EIP-8141 solves the migration problem. Ethereum will be quantum-safe by 2029.
Discussion: EIP-8141 provides a viable migration mechanism for externally owned accounts and represents genuine progress. Two limitations apply. First, EIP-8141 is a planning target for the Hegotá fork in H2 2026 — it has not been activated, and Ethereum Foundation documentation explicitly states that target dates carry no guaranteed commitments. Second, EIP-8141 enables account-level signature migration but does not address the three other cryptographic layers — BLS consensus signatures, KZG data availability, and ZK proof systems — that Vitalik Buterin’s Strawmap identified as separately requiring migration. Full Ethereum quantum resistance across all four layers is a seven-fork, multi-year program. Solana co-founder Anatoly Yakovenko’s May 2026 warning that Ethereum L2s are not quantum-safe is technically accurate regardless of EIP-8141’s activation status.
Objection: We hold cryptocurrency in a hardware wallet. Our keys are offline and therefore safe from quantum attacks.
Discussion: Hardware wallets protect private keys from network-accessible attackers by keeping key material offline. They do not change the on-chain exposure of the public keys associated with addresses that have been used to send transactions. The quantum attack target is the public key published on the blockchain when an address makes its first outbound transaction.
Once that public key is on-chain, it is permanently available to any future quantum computer regardless of where the private key is stored. Cold storage protects against theft of the private key today — it does not protect against derivation of the private key from the on-chain public key in the future. The actionable response for hardware wallet holders is the same as for all holders: avoid address reuse and be prepared to migrate to P2MR addresses when BIP-360 activates.
FAQ
Q1: What makes blockchain specifically more vulnerable to quantum attacks than other cryptographic infrastructure?
A: Conventional cryptographic systems require an adversary to actively capture encrypted data for later decryption — a process known as harvest-now-decrypt-later. Blockchain networks publish every transaction, including the public keys used to authorize them, on a permanently available public ledger. Blockchain ECDSA exposure requires no active collection. Any address that has ever signed a transaction has its public key permanently on-chain, already available to any future quantum computer. This passive, pre-existing exposure is the defining characteristic of the Bitcoin quantum threat and the Ethereum post-quantum challenge.
Q2: Which Bitcoin addresses are quantum-safe today?
A: Addresses that have received funds but have never been used to send a transaction maintain an additional layer of protection through cryptographic hashing. The public key is not revealed until the address signs its first transaction. Pay-to-Public-Key-Hash (P2PKH) and Pay-to-Script-Hash (P2SH) addresses in this never-spent state are considered relatively safer against quantum key derivation — though the hash protection becomes irrelevant once the address is used to send. Best practice for quantum-resistant cryptocurrency holders today is strict address non-reuse: generate a new address for every transaction.
Q3: What is BIP-360 and what does it actually do?
A: BIP-360 proposes a new Bitcoin address format — Pay-to-Multiple-Algorithms (P2MR), using the bc1z prefix — that supports quantum-resistant signature verification alongside existing ECDSA. It reached testnet implementation via BTQ Technologies in early 2026 but has not activated on Bitcoin mainnet. BIP-360 does not automatically protect existing addresses. Holders must actively move funds to new P2MR addresses to gain quantum resistance. Coins in legacy address types remain exposed until moved.
Q4: What is Ethereum’s Strawmap and when will Ethereum be quantum-safe?
A: The Strawmap is the Ethereum Foundation’s living roadmap for Ethereum post-quantum migration, published by Vitalik Buterin in February 2026. It identifies four cryptographic layers requiring migration and targets approximately seven sequential hard forks over multiple years. EIP-8141, the account abstraction mechanism enabling user-level signature migration, is being considered for the Hegotá fork in H2 2026. Full quantum resistance across all four layers — accounts, consensus BLS, data availability, and ZK proofs — is targeted for approximately 2029 as a planning horizon, not a guaranteed commitment.
Q5: Should cryptocurrency holders take action now, or wait for protocol upgrades?
A: One action is available to all holders today regardless of protocol upgrade status: strict address non-reuse. Never send from the same address twice. This prevents public key exposure for addresses not yet used to sign transactions. Beyond that, institutional holders and custodians should audit their address inventory for reuse patterns, request PQC for blockchain roadmaps from wallet and custody infrastructure vendors, and monitor BIP-360 and BIP-361 progression for migration timeline signals.
Q6: How does the quantum threat affect DeFi protocols and smart contracts specifically?
A: Smart contracts that hardcode ECDSA signature verification logic — for multisig authorization, oracle attestation, or access control — are not covered by Ethereum’s EIP-8141 account abstraction migration mechanism. Those contracts require explicit code upgrades. DeFi protocol operators should audit all contract-level signature verification dependencies and design upgrade paths that leverage EIP-8141’s account abstraction framework where possible. Bridge operators face additional exposure because cross-chain signature verification aggregates the quantum vulnerability of multiple networks simultaneously.
Key Points
What Every Blockchain Stakeholder Needs to Know About PQC for Blockchain in 2026
- Every major blockchain — Bitcoin, Ethereum, Solana, and 22 of the top 26 networks — uses secp256k1 ECDSA or related elliptic curve schemes that Google’s March 2026 paper demonstrated can be broken with 20 times fewer quantum resources than previously estimated.
- Blockchain ECDSA exposure is structurally more severe than conventional cryptographic risk: public keys are permanently published on-chain and require no adversarial collection — they are already available to any future quantum computer.
- More than 34 percent of all Bitcoin in circulation sits in addresses with exposed public keys as of March 2026. Project Eleven estimates approximately 7 million BTC is potentially at risk under a broad exposure definition.
- Bitcoin’s BIP-360 reached testnet in early 2026; BIP-361 proposes a phased sunset with enforcement consequences. Neither has mainnet consensus. Full Bitcoin migration is estimated at seven-plus years from the day consensus forms.
- Ethereum’s Strawmap targets seven hard forks through approximately 2029. EIP-8141, enabling account-level Ethereum post-quantum signature migration, is being considered for the Hegotá fork in H2 2026.
Continue your PQC research:
- Read the previous article: Cryptographic Inventory 2026: The Step-by-Step Enterprise Guide to Finding Vulnerable Encryption
- Read the pillar article: Year of Quantum Security 2026: The Complete Action Plan for CISOs
PQC Series Overview
This article is part of the Post-Quantum Security Series — a technical collection of guides exploring cryptographic vulnerabilities exposed by quantum computing, migration strategies for organizations, and the steps required to protect sensitive data before quantum decryption becomes operationally viable.
→ Subscribe to the PQC series for structured updates as blockchain migration proposals advance toward consensus.
References
- [1] Google Quantum AI / Ethereum Foundation / Stanford University. (March 2026). Securing elliptic curve cryptocurrencies against quantum vulnerabilities: Resource estimates and mitigations. quantumai.google.
https://quantumai.google/static/site-assets/downloads/cryptocurrency-whitepaper.pdf - [2] Coinpaprika Education. (April 2026). Quantum vulnerability in cryptocurrency: Responsible disclosure guide.
https://coinpaprika.com/education/quantum-vulnerability-cryptocurrency-responsible-disclosure-guide/ - [3] Project Eleven. (March 2026). Bitcoin quantum exposure analysis: Exposed address risk estimates. Project Eleven Research.
https://www.projecteleven.com/ - [4] Bitcoin.com News. (April 2026). Bitcoin developers propose freezing coins that skip quantum-safe migration under BIP-361.
https://news.bitcoin.com/bitcoin-developers-propose-freezing-coins-that-skip-quantum-safe-migration-under-bip-361/ - [5] Liu, J. (January 2026). Post-quantum roadmaps for blockchain ecosystems. Medium. https://medium.com/@gwrx2005/post-quantum-roadmaps-for-blockchain-ecosystems-af9e77a6fe8b
- [6] Phemex Blog. (2026). BIP-360 explained: Bitcoin’s first quantum-resistant address type (P2MR). https://phemex.com/blogs/bitcoin-quantum-resistant-address-bip-360
- [7] KuCoin Blog. (April 2026). BIP-361 explained: Bitcoin’s new plan to freeze quantum-vulnerable coins and survive quantum computing.
https://www.kucoin.com/blog/bip-361-explained-bitcoin-new-plan-to-survive-quantum-computing - [8] The QRL Foundation. (March 2026). Google just set a 2029 deadline. Bitcoin and Ethereum aren’t ready.
https://www.theqrl.org/blog/google-just-set-a-2029-deadline-bitcoin-and-ethereum-arent-ready/ - [9] Ethereum Foundation. (March 2026). pq.ethereum.org — post-quantum research roadmap and repository hub.
https://pq.ethereum.org - [10] Ethereum.org. (May 2026). Future-proofing Ethereum and crypto quantum security — EIP-8141 and the Hegotá fork.
https://ethereum.org/roadmap/future-proofing/ - [11] Post Quantum Cryptography de. (December 2025). Quantum threat to blockchain: Will Bitcoin survive?
https://www.postquantumcryptography.de/publications/bitcoin_quantumcomputer_pqc.html
