Not All Blockchains Face the Same Risk
The quantum threat to cryptocurrency is often discussed as if it applies uniformly across the entire asset class. It does not. The specific vulnerability of any given blockchain is a function of at least three independent variables: the signature scheme used for transaction authorization, the address format and whether it exposes the public key before a transaction is spent, and the historical key exposure pattern accumulated by that network's user base. A blockchain could use a relatively quantum-resistant address format but have ten years of exposed public keys on-chain from its early transaction history. A network could have a modern address design but rely on a signature algorithm that Shor's algorithm breaks as efficiently as ECDSA.
The ranking below is based on current, publicly documented protocol design and on-chain data. It is not a prediction of which network will be attacked first, since that depends on hardware timelines and adversary targeting decisions. It is an assessment of structural vulnerability: given a sufficiently capable quantum computer, how much damage can it do, and to how much of each network's supply?
Tier 1: Highest Risk
Bitcoin P2PK Addresses
Pay-to-public-key outputs represent the original Bitcoin transaction format, used heavily from 2009 through approximately 2012. In P2PK, the full public key is embedded directly in the locking script of the transaction output. There is no hashing layer, no one-way function standing between the blockchain record and the public key. Every P2PK output is permanently, unconditionally vulnerable to a quantum attack once the attacker has sufficient qubit capacity to run Shor's algorithm against a 256-bit elliptic curve key.
The concentration of value in P2PK outputs is significant. Satoshi Nakamoto's estimated 1.1 million BTC in early coinbase rewards are predominantly P2PK. Early mining rewards from 2009 and 2010 are largely in the same format. According to the Coinbase advisory board report, roughly 6.9 million BTC in total sits in addresses with exposed public keys, with P2PK outputs accounting for a substantial portion of that figure. Review the Vulnerable Wallets guide to understand whether your holdings include P2PK outputs.
Bitcoin Reused P2PKH Addresses
Pay-to-public-key-hash addresses added one layer of protection by hashing the public key before encoding it in the address. Before any transaction is sent from a P2PKH address, only the hash of the public key is known publicly, and hash functions are much less vulnerable to quantum attacks than elliptic curve operations. Grover's algorithm, the primary quantum threat to hash functions, roughly halves the effective security level, reducing SHA-256 from 256-bit to 128-bit security in the quantum threat model. That is a meaningful reduction but not a catastrophic one for current hash sizes.
However, the moment a P2PKH address is used to send Bitcoin, the spending transaction includes the full public key in its input script. That key is now permanently on-chain and permanently vulnerable. Address reuse, which is extremely common in Bitcoin's transaction history, means that a large number of P2PKH addresses currently hold balances with fully exposed public keys. Anyone who has ever sent from an address that still holds a balance falls into Tier 1 regardless of the address format they used.
Tier 2: High Risk
Ethereum
Ethereum's account model makes the public key exposure problem structural rather than optional. Unlike Bitcoin's UTXO model where each coin can theoretically sit in a fresh address, Ethereum accounts are persistent. Every account has a fixed address derived from the public key. The first outgoing transaction from any Ethereum address reveals the public key in the transaction signature. After that first send, the address is permanently in Tier 1 territory.
Because Ethereum users typically reuse their account address indefinitely, and because the account model encourages repeated interaction with DeFi protocols, token contracts, and NFT markets from a single address, the vast majority of active Ethereum accounts have exposed public keys. New wallets that have only received ETH but never sent any outgoing transactions retain some hash-layer protection, but this describes a minority of active addresses. For a full explanation of why quantum computing threatens blockchain security at the protocol level, Ethereum's account model is the clearest illustration of how exposure accumulates at scale.
Solana
Solana uses EdDSA over Curve25519 (the Ed25519 scheme) rather than the ECDSA over secp256k1 used by Bitcoin and Ethereum. This distinction is meaningful for performance and resistance to certain classical attacks but provides no meaningful advantage against a quantum adversary. Shor's algorithm breaks the discrete logarithm problem on any elliptic curve, including Curve25519. The security level of Ed25519 against a quantum computer is roughly equivalent to the security level of secp256k1 against a quantum computer: both go to zero once the attacker has enough logical qubits.
Solana's account model resembles Ethereum's in the key-exposure sense: addresses are persistent, and program interactions require signed transactions that expose public keys. The network's high transaction throughput means that a large fraction of Solana addresses are highly active and have exposed public keys many times over.
XRP
XRP uses ECDSA over secp256k1 by default, making it directly comparable to Bitcoin from a signature-scheme perspective. The XRPL also supports Ed25519, which as noted above provides no meaningful quantum advantage. The XRP Ledger's account model is persistent, similar to Ethereum, so active accounts have exposed public keys after their first outgoing transaction. The concentration of XRP in relatively few large addresses does mean that a smaller number of high-value targets exist compared to more distributed networks, but the structural vulnerability is identical.
Signature Schemes: ECDSA vs EdDSA vs Schnorr
A common question is whether choosing a different classical signature scheme provides any meaningful quantum protection. The short answer is no. ECDSA, EdDSA, and Schnorr signatures all derive their security from the elliptic curve discrete logarithm problem. Shor's algorithm solves the discrete logarithm problem efficiently on quantum hardware regardless of which specific curve or signature variant is being used. Bitcoin's Taproot upgrade, which enables Schnorr signatures, provides real benefits in privacy and script efficiency but does not alter the quantum vulnerability profile at all.
The meaningful distinction is not between ECDSA, EdDSA, and Schnorr. It is between all classical elliptic curve schemes on one side and genuinely post-quantum constructions — lattice-based, hash-based, code-based — on the other. NIST standardized several post-quantum signature algorithms in 2024, including CRYSTALS-Dilithium and FALCON. None of the major existing blockchains have deployed these at the protocol level for user-facing transactions.
Why Hash Functions and Proof-of-Work Are Less Vulnerable
It is worth noting what quantum computers are not particularly good at attacking. Proof-of-work mining relies on SHA-256 preimage resistance. Grover's algorithm can search for a preimage in O(sqrt(N)) time rather than O(N), which effectively halves the bit security of the hash function. For SHA-256, this reduces security from 256-bit classical to 128-bit quantum-adjusted. That is still a very large number, and doubling hash output size provides full restoration of security. Proof-of-work mining is not a primary quantum concern for Bitcoin, even though it is often conflated with the signature vulnerability in general discussions of quantum risk.
Hash-locked contracts, Merkle proofs, and other constructions that rely purely on hash functions rather than public-key operations similarly enjoy Grover's-only exposure and are substantially more resistant to quantum attack than signature schemes. This distinction matters when evaluating which parts of blockchain infrastructure are most urgently in need of post-quantum upgrades.
Taproot and Bech32: Do Newer Formats Help?
Taproot (P2TR) addresses and native SegWit bech32 addresses provide meaningful protection in one specific scenario: a wallet that has only received funds and has never sent any outgoing transaction. In that state, only a hash of the public key or a hash of the Taproot output key is visible on-chain, and breaking that hash requires Grover's algorithm rather than Shor's. The effective security against quantum attack for an unspent P2TR or bech32 address is substantially better than for a P2PKH address that has sent funds.
The protection vanishes the moment the address is used to send. Taproot spending reveals the internal key in the witness. SegWit spending reveals the public key in the witness script. The hash-layer protection is a one-time benefit that disappears on first use. For long-term cold storage that will never send, modern address formats provide real protection. For any address that has participated in the transaction graph, they do not.
DeFi and Smart Contract Specific Risks
DeFi protocols introduce additional quantum risk beyond simple wallet exposure. Smart contracts that hold custody of funds, validate signatures on-chain, or use public keys as identifiers in their logic are vulnerable in ways that depend on the specific contract implementation. A multisig contract that relies on ECDSA verification is only as quantum-resistant as the weakest signature scheme it uses. Oracle contracts that sign data feeds with secp256k1 keys are vulnerable to key forgery. Governance systems that weight votes by signatures can be manipulated if private keys are derived by an adversary.
The DeFi risk is not limited to direct fund theft. The integrity of price feeds, governance votes, and cross-chain bridges can all be undermined by an actor with quantum key-derivation capability, potentially causing cascading failures across protocols that depend on each other. The harvest now, decrypt later threat is particularly relevant for DeFi participants who sign many transactions from the same address, since each signature provides additional material for cryptanalysis and increases the value of attacking that specific key.
The Only Real Protection: Never Exposing Keys
The ranking above converges on a single structural insight: all existing major blockchains are vulnerable because they require public key exposure as part of normal operation. The severity varies by address format and usage pattern, but the underlying problem is architectural. Any system where spending a transaction reveals the public key, and where that revelation is permanently recorded on a public ledger, accumulates quantum vulnerability with every transaction it processes.
The architecturally sound response is to design systems where the public key is never placed on-chain. TADEQS architecture implements this through parent/child key structures and atomic key rotation on spend, ensuring that no spending transaction ever reveals key material that can be harvested. The Quantum Oracle monitors the threat environment continuously, and Proof of Coherence builds quantum-hardened infrastructure requirements into consensus itself.
Practical Checklist: Assessing Your Own Exposure
Use the following questions to audit your cryptocurrency holdings against the quantum risk tiers above:
- Do you hold Bitcoin in P2PK addresses? These are associated with very early transaction history. If yes, this is Tier 1 exposure regardless of any other factor.
- Have you ever sent from any of your Bitcoin addresses? If yes, those addresses have exposed public keys and are in Tier 1. Move any remaining balance to a fresh address you have never sent from.
- Do you hold ETH, SOL, XRP, or other classical-curve assets? Any address that has ever sent a transaction is in Tier 2 at minimum. Accounts that have only received funds retain some hash-layer protection.
- Do you use DeFi protocols? Any address that signs transactions with DeFi contracts has exposed its public key at least once for every protocol interaction. Assume full exposure.
- How long is your holding horizon? The Quantum Threat Calculator can help you model the intersection of your exposure profile with realistic hardware timelines. The qubit requirement compression over the past seven years has been moving faster than most holders have internalized.
The quantum threat does not arrive at the same time for every holder or every blockchain. But the structural vulnerability is already baked into the design of every major network operating today, and the engineering progress on quantum hardware is following a curve that reduces the time available for mitigation. The ranking here is not meant to induce panic — it is meant to enable accurate calibration of a risk that demands both technical literacy and practical action.
