Quantum risk follows exposure
Current quantum computers do not pose a cybersecurity risk, but their successors will. Our new white paper analyses how this could play out for cryptocurrencies. The most important takeaway concerns the actions that should be taken today, while there is still time to sequence it.
Below is a summary and the full analysis is on arXiv.
The Risks
A quantum algorithm known as Shor's algorithm puts widely deployed cryptographic schemes based on integer factorization and discrete logarithms in danger of being broken, including RSA, Diffie-Hellman, ECDSA, and EdDSA. Elliptic-curve cryptography schemes are the most exposed because their comparatively small key sizes make them a cheaper target. Unfortunately, their small key sizes are also why the major blockchain platforms such as Bitcoin, Ethereum and Solana use them to secure accounts, authorize transactions and maintain consensus.
Recent research from Google Quantum AI and collaborators has sharpened these concerns. They found a substantially more efficient way to implement Shor's algorithm. For the task of breaking the elliptic-curve discrete logarithm problem on secp256k1, their approach would need a quantum computer with around 20 times fewer physical qubits than prior estimates required, meaning that less hardware R&D will be needed to build such a quantum computer than previously thought. Similar conclusions are expected to hold for related schemes, such as P-256.
When quantum computers become sufficiently performant to pose a cybersecurity risk, they will be referred to as 'cryptographically relevant quantum computers' or CRQCs for short. A CRQC could derive a private key from a published public key. On a blockchain that means direct theft from exposed accounts, as well as the ability to use administrative and governance keys to perform malicious smart-contract upgrades. Stablecoin ecosystems are among the most vulnerable, since the compromise of issuer or administrator keys would allow unauthorized minting, burning, freezing or transferring of assets that the market generally treats as settled cash.
Grover's algorithm is the other relevant consideration, but the effect of this quantum algorithm is much more limited. Consider hash functions. They compress any input into a short fixed-length fingerprint, and they are useful in cryptography because recovering the input from the fingerprint is meant to be infeasible. Grover's algorithm gives a quadratic speedup on brute-force attempts at such a recovery, halving the effective preimage security level. For example, even when future CRQCs run Grover's algorithm against SHA-256, it will have roughly 128 bits of effective preimage security, which is still enough to leave it out of the reach of attackers.
Some platforms already have partial defences. Bitcoin's most widely used address types record only a hash of the public key, so the key stays hidden while coins sit unspent and is revealed at the moment the owner spends. Solana's Winternitz vaults let a user park chosen assets behind hash-based signatures instead. Both help, and both are narrow. They cover selected assets rather than whole accounts, and neither protects validator identities or the cryptography securing consensus.
The white paper works through what is at stake economically across Bitcoin, Ethereum and Solana, detailing which components are exposed and which migration paths are practical today. Because blockchains are public and continuously priced, they give an unusually clear view of how their quantum risk is perceived.
The analysis highlights four findings, discussed below, that extend beyond blockchain systems and carry across to conventional enterprise cryptographic infrastructure. Indeed, the implications already reach beyond crypto-native firms, as more than $200 billion in stablecoins and tokenized real-world assets is issued on Ethereum alone.
1. Exposure time sets the threat
Envisioned quantum attacks on blockchains can be categorized into the following three classes.
At-rest attacks target public keys that stay exposed indefinitely: dormant accounts, reused addresses and validator keys. The key sits there and an attacker works for as long as is needed. There is no deadline, so the CRQC just needs to be functional. It doesn't need to be fast.
On-spend attacks must recover the private key from a public key revealed in a pending transaction, then get a competing transaction accepted before the original is included in a block. That window depends mainly on block or slot times (about 400 milliseconds on Solana, 12 seconds on Ethereum and an average of 10 minutes on Bitcoin), along with fees and mempool rules.
On-setup attacks work differently. Some cryptographic systems depend on fixed public parameters that are generated once in a setup ceremony. Producing those parameters creates secret values that the participants are then supposed to destroy. A CRQC could recover those secrets from the public parameters, and it only needs to do it once. From then on, the backdoor works on an ordinary computer, and using it produces nothing on the ledger that looks anomalous. Ethereum's data availability sampling and several privacy protocols rest on parameters of this kind.
The same exposure model applies to traditional enterprise cryptography. At-rest exposure is anything where a public key is durable and the asset it protects outlives it: root and intermediate certificate authorities, code and firmware signing keys, long-lived device identities, and information encrypted years ago that still matters today. 'Harvest now, decrypt later' attacks belong in this category. Short-lived session exposure is the equivalent of on-spend attacks, and it is the less urgent priority. At-rest exposure comes first, and it is important to get that ordering right.
2. Value concentrates in a small number of privileged keys
Working from public chain data and from resource estimates published by Google Quantum AI and collaborators, the picture is one of concentration.
- Approximately 6.9 million BTC are assessed as quantum-vulnerable, close to $500 billion at current valuations.
- About 9.7% of supply sits in script types whose public keys are exposed on-chain from the outset: mostly P2PK, with Taproot (P2TR) accounting for most of the rest (see Figure 1).
- On Ethereum, roughly 41 million ETH secures proof-of-stake consensus.
A rational attacker would likely prioritize targets that combine high value with long-exposed public keys. High-value dormant wallets are particularly attractive to an early quantum adversary because they can be attacked at rest, without the tight timing constraints of intercepting an active transaction. But the most consequential targets may lie elsewhere: stablecoin administrator keys, bridge operators, contract upgrade authorities, exchange hot wallets and validator infrastructure can concentrate enormous value or control behind relatively few keys.
The same logic holds inside an enterprise. Cryptographic risk is not evenly spread across a certificate inventory. It clusters in roots of trust, HSM-held signing keys, privileged automation credentials and the handful of systems everything else authenticates against. A migration plan that treats all findings as comparable will spend its first year in the wrong place.
3. Some assets cannot be migrated at all
The hardest case is dormant wallets. Lost or abandoned coins cannot be moved to post-quantum schemes because nobody holds the key. Blockchain communities may eventually need to decide how to treat assets that remain under quantum-vulnerable keys, for example, whether to require migration by a deadline or freeze unmigrated assets. These are governance questions that cryptographic upgrades alone cannot resolve.
Most enterprises hold the same category of asset and have not inventoried it: embedded devices with hardcoded certificates, firmware that will never receive another update, encrypted archives whose owners have left, and cryptography inside third-party products that cannot be modified. Instead of being fixed by a migration project, they are compensated for, replaced, or formally accepted. Either way, they need naming early, because their mitigation lead times are the longest in the program.
4. Signature size is the binding constraint
The post-quantum signature schemes available today differ in size by more than a factor of ten among themselves, and by just over two orders of magnitude against the schemes they would replace (see Table 1). That difference decides what can be deployed where.
| Scheme | Public key | Signature | Status |
|---|---|---|---|
| Ed25519 (current) | 32 B | 64 B | FIPS 186-5, not PQC |
| ML-DSA-44 (Dilithium) | 1,312 B | 2,420 B | FIPS 204, final |
| FN-DSA (Falcon-512) | 897 B | 666 B or less | FIPS 206, draft |
| SLH-DSA-128s (SPHINCS+) | 32 B | 7,856 B | FIPS 205, final |
Table 1. Post-quantum signature scheme size comparison.
Ed25519, which Solana and many other platforms use today, produces a 64-byte signature and offers no protection against Shor's algorithm. ML-DSA-44, one of the finalized replacements, produces a 2,420-byte signature, roughly 38 times larger. For a blockchain with a transaction size limit, that is a protocol change. Inside an enterprise the same arithmetic surfaces on the wire (e.g., larger TLS handshakes and certificate chains, packets that no longer fit and have to be fragmented) and in hardware (e.g., smartcards, HSMs and embedded devices that run out of room). These are integration and capacity problems, and they are where post-quantum programs actually slow down.
Compactness matters most where transaction size and bandwidth are hard limits, which is why the white paper points to FN-DSA for ledger use. Enterprise and federal programs work to a different constraint set. ML-DSA under FIPS 204 is finalized and deployable now, while FIPS 206 remains in draft with a final standard expected in late 2026 or early 2027, so FN-DSA is best treated as something to test and design around. The principle that carries across both settings is that scheme selection is driven by size and integration cost as much as by security level.
Migration profiles
Centralized financial infrastructure and distributed ledgers have opposite migration profiles. Card networks and interbank messaging can mandate upgrades, rotate keys and reverse fraudulent transactions, and they also carry hundreds of millions of terminals, cards, HSMs and embedded devices that would need upgrading or replacing. Blockchains invert that. Coordination is contested and governance-bound, but most participants run software that can be upgraded without touching physical infrastructure.
Neither profile is straightforwardly safer. The question is which of the two an organization has more of, because that determines whether its real migration constraint is decision-making or hardware.
Where the keys sit
For security and risk leaders, one distinction matters. Holding digital-asset exposure is not the same as operating the cryptography behind it. If a fund holds tokenized treasuries or an ETF wrapper, then the signing keys sit with a custodian, a sub-custodian, a transfer agent, an issuer or a bridge operator. The exposure is real, but it belongs to a third party and it will not appear in an internal scan. For European financial entities, managing it is what DORA's ICT third-party risk provisions already require. If an institution runs its own custody, tokenization or settlement infrastructure, then the keys are its own and the analysis above applies directly.
That looks like two separate problems, a counterparty question and an inventory question, but they meet at the boundary. Nobody can scan a counterparty's estate. The cryptography protecting the connection to that counterparty is your own. The certificates, protocols and service authentication on every integration you run sit in your network and your cloud environments, and they are what tell you which counterparties you cryptographically depend on, and where.
That is the difference between asking a provider whether they have a post-quantum plan and asking whether they can change the signing scheme on a named integration without interrupting service. Without your own side mapped, the exchange comes down to reassurance.
Where to start
Post-quantum migration is an infrastructure resilience program, and waiting for confirmation of quantum capability is the wrong trigger to plan against. Our earlier analysis of quantum scaling sets out why that confirmation is unlikely to arrive as a clean signal: Quantum's hard takeoff.
The following questions apply to any estate:
- Where are public keys exposed continuously, what do they protect, and for how long?
- Which keys carry disproportionate value or authority?
- What cannot be migrated at all, and what is the compensating control?
- Where will post-quantum key and signature sizes break something?
- Which keys are held on your behalf by someone else, and what is their migration plan?
The full analysis, including the per-script exposure tables, the Ethereum and Solana breakdowns, and the scheme comparison, is in the white paper: Cryptocurrencies in the Quantum Age: Migration Paths to PQC
Authored by A. Kodukhov, Terra Quantum AG. Reviewed by C. Mansell, T. Hartley, R. Brasher and E. Wood.