Roughly 5.4 million bitcoin, worth hundreds of billions of dollars, sits in wallets whose public keys have already been exposed on-chain. Quantum computing is the reason that number matters. Once a sufficiently powerful quantum computer exists, exposed public keys stop being harmless strings of data and become the starting point for stealing funds outright, which is why cryptocurrency security is now being redesigned years before that computer is built.
The threat isn't hypothetical hand-waving about far-off science fiction. NIST, IBM, Google, and PsiQuantum have each published timelines that converge on the 2030-to-2035 window for cryptographically relevant quantum computers. Blockchain protocols built on elliptic curve cryptography have to migrate before that window closes, not after, because the migration itself takes years and the assets at risk can't simply be recalled once the threat materializes.
Why Elliptic Curve Cryptography Breaks Under Quantum Attack
Bitcoin, Ethereum, and most major cryptocurrencies rely on the Elliptic Curve Digital Signature Algorithm (ECDSA) to prove ownership of funds. The security of ECDSA rests on the elliptic curve discrete logarithm problem: given a public key, it's computationally infeasible for classical computers to derive the corresponding private key. That infeasibility is the entire basis of the trust model.
Shor's algorithm changes the math. Running on a fault-tolerant quantum computer, it solves the discrete logarithm problem in polynomial time instead of the exponential time classical computers require. A 2025 analysis from Google Quantum AI researcher Craig Gidney estimated that factoring a 2048-bit RSA key would require under a million noisy qubits, a dramatic reduction from earlier estimates that assumed tens of millions. Applied to elliptic curve keys, similar resource reductions mean the timeline for a practical break keeps compressing rather than expanding.
# Simplified illustration of what ECDSA relies on:
# given P = k * G (public key = private key * generator point),
# recovering k classically is intractable.
# Shor's algorithm solves this class of problem efficiently on
# a fault-tolerant quantum computer, which is why exposed public
# keys — not just private keys — become the attack surface.
def is_public_key_exposed(address_type: str, has_been_spent: bool) -> bool:
"""
Returns True if the public key for this address is already
visible on-chain and therefore quantum-attackable once a
cryptographically relevant quantum computer exists.
"""
always_exposed = {"P2PK", "P2TR"} # public key visible by design
if address_type in always_exposed:
return True
# P2PKH, P2WPKH, P2WSH hide the key behind a hash until spent
return has_been_spent
This is why the risk isn't evenly distributed across a blockchain. Coins sitting in never-spent hashed addresses, like standard P2PKH or SegWit outputs, keep their public key hidden until the moment they're spent. Coins in P2PK addresses or reused P2PKH addresses have already broadcast their public key, which means they're exposed today and simply waiting for the hardware to catch up.
The Scale of Bitcoin's Exposure Is Larger Than Most Holders Realize
Multiple independent chain analyses have tried to quantify exactly how much Bitcoin sits in this exposed category, and the estimates have grown as measurement techniques improved. Deloitte's earlier scans put the figure at roughly 25% of circulating supply. More recent 2026 measurements from Glassnode found 6.04 million BTC, about 30.2% of issued supply and worth roughly $469 billion, with exposed public keys on-chain.
That figure splits into meaningfully different risk categories. Around 2.3 million BTC, roughly 12% of supply, is dormant across every address type, including Satoshi-era coins whose owners can never move them to safety even with warning. Another 3.7 million BTC, about 19% of supply, is exposed but still spendable, meaning owners can sweep those funds into quantum-resistant outputs if they act before a quantum computer arrives. The remaining 65 to 70% of supply sits in fresh, never-reused hashed addresses, where the public key is only briefly revealed at the moment of spending.
Ethereum's exposure looks structurally different. Because Ethereum was designed around persistent, reused addresses rather than one-time hashed outputs, a much larger share of its supply has already broadcast its public keys as a normal consequence of everyday use. That design choice, which made Ethereum more usable for smart contracts, also makes the network's quantum migration path more urgent and more complicated than Bitcoin's.
The "Harvest Now, Decrypt Later" Problem Compounds the Risk
Even setting aside live quantum attacks on a currently exposed key, cryptocurrency networks face a subtler threat: adversaries can record and store today's exposed public keys and transaction data now, with the explicit plan of decrypting them once quantum hardware matures. Security researchers call this Harvest Now, Decrypt Later, or HNDL, and it applies to blockchains just as it applies to encrypted government communications and corporate data.
For a bank record or a diplomatic cable, HNDL means confidentiality fails years later. For a cryptocurrency wallet, it's more direct: an adversary who has already harvested a public key doesn't need to break anything new when the quantum computer arrives. They just need to run the attack and move the funds before the legitimate owner does. This is one reason security researchers argue the migration clock started the moment Shor's algorithm was proven, not the moment a quantum computer capable of running it gets built.
There's also a narrower, more time-sensitive exposure window that applies to every Bitcoin transaction, regardless of address type. When a transaction is broadcast, its public key becomes visible in the mempool before the transaction is confirmed on-chain. Confirmation currently takes around ten minutes. A sufficiently fast quantum attacker could theoretically intercept that window, derive the private key, and submit a competing transaction with a higher fee, a scenario sometimes called a transaction hijack or race attack. This is a distinct risk from address-level exposure because it threatens every future transaction, not just historically reused ones.
Where Post-Quantum Standards Currently Stand
NIST finalized its first three post-quantum cryptography standards in August 2024: ML-KEM (formerly CRYSTALS-Kyber) for key encapsulation, ML-DSA (formerly CRYSTALS-Dilithium) for digital signatures, and SLH-DSA (formerly SPHINCS+) as a hash-based signature backup. A fourth algorithm, HQC, was added in 2025 to diversify the mathematical assumptions the standards rely on, reducing the risk that a single cryptanalytic breakthrough compromises everything at once.
That diversification turned out to matter quickly. In July 2026, Anthropic disclosed that an AI model it developed had discovered a vulnerability in HAWK, a lattice-based signature algorithm that was under consideration for standardization. The HAWK team withdrew the algorithm, and NIST confirmed the finding doesn't affect the already-finalized ML-KEM or ML-DSA standards, which rest on different mathematical foundations. The episode is a useful reminder that post-quantum cryptography is still an active research field, not a solved problem with a single fixed answer, and that crypto-agility, meaning the ability to swap algorithms without rebuilding a system from scratch, is as important as picking the right algorithm today.
# Conceptual sketch of a hybrid signature scheme, combining a
# classical and post-quantum algorithm so that breaking either
# one alone is insufficient to forge a valid signature.
def hybrid_sign(message: bytes, ecdsa_key, dilithium_key) -> dict:
classical_sig = ecdsa_sign(message, ecdsa_key)
pq_sig = dilithium_sign(message, dilithium_key)
return {
"message": message,
"ecdsa_signature": classical_sig,
"ml_dsa_signature": pq_sig,
}
def hybrid_verify(signed: dict, ecdsa_pub, dilithium_pub) -> bool:
return (
ecdsa_verify(signed["message"], signed["ecdsa_signature"], ecdsa_pub)
and ml_dsa_verify(signed["message"], signed["ml_dsa_signature"], dilithium_pub)
)
NIST's IR 8547 sets a broader migration timeline: quantum-vulnerable algorithms should be deprecated by 2030 and removed from standards entirely by 2035, with high-risk systems expected to transition earlier. That timeline was written with government and enterprise systems in mind, but it's become a reference point for blockchain governance discussions as well, since cryptocurrency networks face the same underlying hardware timeline without the benefit of centralized rollout authority.
How Blockchain Networks Are Actually Responding
Bitcoin and Ethereum face the migration problem differently because their governance models differ. Bitcoin's protocol changes require broad consensus among node operators, miners, and businesses, which makes any hard fork slow by design. BIP-360 is the primary proposal addressing quantum resistance, aiming to introduce a new address format that supports post-quantum signature schemes such as hash-based signatures, without requiring every wallet to migrate simultaneously.
Ethereum's public roadmap treats quantum resistance as a defined workstream rather than a distant contingency. The Ethereum Foundation's post-quantum team has been developing proposals, including EIP-8141, drafted in January 2026, which explores account abstraction mechanisms that could allow wallets to adopt quantum-resistant signature schemes without requiring every user to generate an entirely new address from scratch. Because Ethereum already relies heavily on account abstraction infrastructure from EIP-7702, that flexibility gives it a somewhat smoother migration path than Bitcoin's UTXO model, even though its baseline exposure is higher.
Smaller ecosystems are moving faster precisely because they carry less legacy weight. Postquant Labs launched Quip Network in April 2026, a Layer 2 Bitcoin wallet built on WOTS+ (Winternitz One-Time Signature) cryptography, running through the Arch Network smart contract layer. It's a narrower, opt-in solution rather than a base-layer protocol change, but it illustrates the kind of incremental migration path that doesn't require waiting on Bitcoin Core consensus.
# Example: checking whether a Bitcoin UTXO is in the
# "migratable but currently exposed" risk tier, combining
# address type and spend history the way chain analyses do.
def classify_exposure(address_type: str, spend_count: int, is_dormant: bool) -> str:
if is_dormant and address_type in {"P2PK"}:
return "irreducible" # owner can no longer act
if address_type in {"P2PK", "P2TR"} or spend_count > 0:
return "migratable_exposed" # owner can still sweep funds
return "protected" # key hidden until first spend
# Wallet software increasingly flags "migratable_exposed" UTXOs
# so holders can proactively move funds to fresh addresses ahead
# of any quantum-capable adversary.
What This Means for Developers and Holders Right Now
For developers building on top of these chains, the practical starting point is crypto-agility: designing signature verification and key management so that a new algorithm can be added without a full rewrite. Hard-coding ECDSA assumptions throughout a codebase creates exactly the kind of migration debt that will be expensive to unwind later. Libraries like OpenSSL, BoringSSL, and Bouncy Castle have already begun adding support for ML-KEM and ML-DSA, giving teams a path to start experimenting with hybrid classical-plus-post-quantum schemes now, well before any hard deadline forces the issue.
For individual holders, the practical guidance follows directly from the exposure tiers Deloitte, Glassnode, and other chain analyses have mapped out. Funds sitting in a never-reused address carry structurally lower risk than funds in a reused P2PKH address or an old P2PK output, and wallet software is beginning to surface that distinction directly rather than leaving users to interpret raw address formats themselves. Avoiding address reuse, a piece of advice that predates the quantum conversation entirely, turns out to double as quantum hygiene.
None of this means a quantum attack is imminent. Every credible timeline still places a cryptographically relevant quantum computer somewhere in the 2030 to 2035 range, and the HAWK withdrawal is a reminder that even the replacement algorithms are still being stress-tested. But the migration work, in protocol design, in wallet software, and in developer tooling, takes years to roll out safely across a decentralized network with no central authority to force an upgrade. The organizations and protocols treating this as a 2026 problem rather than a 2032 problem are the ones setting the standard the rest of the ecosystem will eventually have to follow.
