a16z Long Article: What Risks Does Quantum Computing Pose to Cryptocurrency?

Author | Justin Thaler, a16z Research Partner

Translation | GaryMa Wu Talks Blockchain

Regarding “when will quantum computers that pose a real threat to existing cryptographic systems arrive,” people often make exaggerated time estimates — leading to calls for immediate, large-scale migration to post-quantum cryptography.

But these calls often overlook the costs and risks of premature migration and ignore that different cryptographic primitives face completely different threat profiles:

Post-quantum encryption, even if costly, must be deployed immediately: “Harvest-now-decrypt-later” (HNDL) attacks are already happening, because when quantum computers truly arrive — even decades later — sensitive data protected by encryption today will still be valuable. Despite the performance overhead and implementation risks of post-quantum encryption, for data requiring long-term confidentiality, HNDL attacks leave no choice.

The considerations for post-quantum signatures are entirely different. They are unaffected by HNDL attacks, and their higher costs and risks (larger sizes, performance overhead, immature implementations, and potential vulnerabilities) mean migration should be cautious rather than immediate.

These distinctions are very important. Misunderstandings can distort cost-benefit analysis, causing teams to overlook more critical security risks — such as vulnerabilities themselves.

The real challenge in successfully moving toward post-quantum cryptography is aligning “urgency” with “actual threat.” Below, I will clarify common misconceptions about quantum threats and their impact on cryptography — including encryption, signatures, and zero-knowledge proofs — with a particular focus on their implications for blockchain.

Where are we in terms of timeline?

In the 2020s, the likelihood of “cryptographically relevant quantum computers (CRQC)” that pose a real threat remains extremely low, despite some high-profile claims attracting attention.

Note: For cryptographically relevant quantum computers / cryptographically relevant quantum computers, the abbreviation CRQC will be used throughout.

A CRQC refers to a fault-tolerant, error-corrected quantum computer capable of running Shor’s algorithm at sufficient scale to attack elliptic curve cryptography or RSA (e.g., breaking secp256k1 or RSA-2048 within a reasonable timeframe, such as within a month of continuous operation).

Based on publicly available milestones and resource assessments, we are still far from such a quantum computer. Although some companies claim CRQC might appear before 2030 or even 2035, publicly observable progress does not support these claims.

Currently, all architectures — ion traps, superconducting qubits, neutral atom systems — lack any quantum computing platform approaching the hundreds of thousands to millions of physical qubits needed to run Shor’s algorithm attacking RSA-2048 or secp256k1 (the exact number depends on error rates and error correction schemes).

Constraints are not only about qubit counts but also gate fidelity, qubit connectivity, and the depth of error-corrected circuits required to run deep quantum algorithms sustainably. While some systems now exceed 1,000 physical qubits, this number alone can be misleading: these systems lack the connectivity and gate fidelity needed for cryptography-related computations.

Recent systems are approaching physical error rates where quantum error correction becomes feasible, but no one has yet demonstrated more than a handful of logical qubits capable of sustained error correction — let alone thousands of high-fidelity, deep, fault-tolerant logical qubits needed for running Shor’s algorithm. There remains a huge gap between the theoretical feasibility of quantum error correction and achieving the scale necessary for cryptographic attacks.

In short: unless qubit counts and fidelity improve by several orders of magnitude simultaneously, “cryptographically relevant quantum computers” remain out of reach.

However, corporate press releases and media reports can easily lead to misconceptions. Common misunderstandings include:

Claims of “quantum advantage” demonstrations, which often target contrived problems. These problems are not chosen for their practicality but because they can be solved on current hardware and appear to show significant quantum speedup — often downplayed or glossed over in publicity.

Claims of thousands of physical qubits, which usually refer to quantum annealers, not gate-model quantum computers capable of running Shor’s algorithm.

Casual use of “logical qubits” without proper context. Physical qubits are noisy; logical qubits require quantum error correction. As mentioned, Shor’s algorithm needs thousands of logical qubits. Using error correction, each logical qubit typically requires hundreds or thousands of physical qubits (depending on error rates). Yet some companies have pushed the term to absurd extremes. For example, a recent claim that a code distance of 2 (which can only detect errors) allows a logical qubit with just two physical qubits is clearly unreasonable: a fault-tolerant logical qubit requires hundreds to thousands of physical qubits, not two.

More broadly, many quantum computing roadmaps use “logical qubit” to refer to qubits supporting only Clifford operations. These operations can be efficiently simulated classically, making them unsuitable for running Shor’s algorithm, which requires thousands of error-corrected T gates (or more generally, non-Clifford gates).

Therefore, even if a roadmap claims “reaching X thousand logical qubits in year Y,” it does not imply that Shor’s algorithm will be practically executable to break classical cryptosystems in that same year.

Such practices distort public (and even professional) understanding of “how close are we to a true CRQC.”

That said, some experts remain optimistic. For example, Scott Aaronson recently wrote that, given “the astonishing pace of current hardware development,” he now believes it is reasonably possible to have a fault-tolerant quantum computer running Shor’s algorithm before the next US presidential election.

But Aaronson clarified that this does not mean a quantum computer capable of cryptographic attacks: even a fully fault-tolerant implementation that can factor 15 (= 3×5) — a number trivial enough for humans to factor manually — would suffice for his criteria. His standard remains the execution of very small-scale Shor’s algorithm, not cryptographically meaningful scale; earlier attempts to factor 15 used simplified circuits rather than full fault-tolerant implementations. The focus on factoring 15 is not accidental: modular arithmetic for 15 is extremely simple, whereas factoring larger numbers like 21 becomes much more difficult. As a result, quantum experiments claiming to factor 21 often rely on hints or shortcuts.

In summary: there is no public progress supporting the expectation that a quantum computer capable of breaking RSA-2048 or secp256k1 will appear within the next 5 years.

Even 10 years remains an aggressive estimate. Considering the distance to truly cryptographically relevant quantum computers, even if we remain excited about progress, such timelines can coexist with a decade or more.

So what does it mean that the US government has set 2035 as the target year for migrating all government systems to post-quantum cryptography? I believe this is a reasonable timeline for a large-scale migration. But it is not a prediction that “CRQC will appear by then.”

Which scenarios are applicable to HNDL attacks (and which are not)?

“Harvest now, decrypt later” (HNDL) attacks refer to attackers storing encrypted communications now, waiting for the “cryptographically relevant quantum computer” to arrive later, and then decrypting the stored data. It is certain that nation-state actors are archiving US government encrypted communications at scale, intending to decrypt them once quantum computers arrive. This is why cryptographic systems must start migrating today — at least for entities requiring confidentiality for 10–50+ years.

But digital signatures — on which all blockchains rely — differ from encryption: they do not have the “confidentiality” that can be attacked retroactively.

In other words, when a quantum computer arrives, forging digital signatures will become possible from that moment onward, but signatures created before that time are not secret in the same way encrypted messages are. As long as it can be confirmed that a signature was generated before the advent of CRQC, it cannot be considered forged.

Therefore, compared to encryption, the urgency of migrating to post-quantum signatures is much lower.

Major platforms’ actions reflect this: Chrome and Cloudflare have deployed hybrid X25519+ML-KEM schemes in web transport layer security (TLS). [For simplicity in this article, I refer to these as “cryptographic schemes,” though technically, TLS and other secure communication protocols use key exchange or key encapsulation mechanisms, not public-key encryption.]

“Hybrid” means combining a post-quantum scheme (ML-KEM) with an existing scheme (X25519), providing security from both. This approach aims to prevent HNDL attacks while relying on the security of classical schemes like X25519 in case the post-quantum scheme is not yet proven secure.

Apple’s iMessage also incorporates similar hybrid post-quantum encryption in its PQ3 protocol, and Signal has implemented this mechanism in its PQXDH and SPQR protocols.

In contrast, transitioning critical web infrastructure to post-quantum signatures will be delayed until “the actual arrival of CRQC,” because current post-quantum signature schemes entail significant performance degradation (discussed later).

zkSNARKs — zero-knowledge, succinct, non-interactive proofs — are core to blockchain scalability and privacy in the future. Regarding quantum threats, they are similar to signatures. Even if some zkSNARKs are not post-quantum secure (since they use the same elliptic curve cryptography as current signatures), their “zero-knowledge” property remains post-quantum secure.

Zero-knowledge guarantees that proofs do not reveal any information about the secret witness — even against quantum attackers — so there is no “secret” data to be collected and decrypted later.

Thus, zkSNARKs are not affected by HNDL attacks. As today’s non-post-quantum signatures are secure as long as the proofs are generated before CRQC appears, they are trustworthy (the statement being proved is true) — even if they use elliptic curve cryptography. Only after CRQC arrives could attackers craft “seemingly valid but actually false” proofs.

What does this mean for blockchains?

Most blockchains are not exposed to HNDL attacks: most non-privacy chains — like Bitcoin and Ethereum today — primarily use non-post-quantum cryptography for transaction authorization, i.e., signatures rather than encryption.

Again, signatures are not vulnerable to HNDL attacks: “Harvest-now-decrypt-later” attacks only apply to encrypted data. For example, Bitcoin’s blockchain is public; quantum threats concern signature forgery (deriving private keys to steal funds), not decrypting publicly available transaction data. This means HNDL attacks do not pose immediate cryptographic urgency for current blockchains.

Unfortunately, some trusted institutions (including the US Federal Reserve) have incorrectly claimed that Bitcoin is vulnerable to HNDL attacks in analyses, exaggerating the urgency of post-quantum migration.

But “lowered urgency” does not mean Bitcoin can wait indefinitely: the enormous societal coordination required for protocol upgrades creates different time pressures. (More detailed discussion of Bitcoin’s unique challenges follows.)

An exception today is privacy coins, where many transactions are encrypted or otherwise hidden, making user privacy vulnerable to HNDL attacks — though the severity varies by design. Chains that rely solely on public ledgers are at highest risk of future de-anonymization once quantum computers can break elliptic curve cryptography.

The impact depends on the chain’s architecture. For example, Monero’s ring signatures and key images — used to prevent double-spending and link outputs — mean that just by observing the public ledger, it might be possible to reconstruct the entire transaction graph in the future. Other privacy coins, like Zcash, have different levels of resilience — see discussions by Zcash cryptographer and researcher Sean Bowe.

If users believe that “transactions will not be exposed in the future due to quantum computers,” then privacy chains should migrate to post-quantum primitives or hybrid schemes as soon as possible. Alternatively, they should adopt architectures that do not place decryptable secrets on-chain.

The special challenges of Bitcoin: governance + abandoned coins

For Bitcoin, two pragmatic factors make early migration to post-quantum signatures urgent, neither related to quantum technology itself. First is governance speed: Bitcoin evolves very slowly. Any contentious issue that the community cannot resolve through consensus risks triggering a disruptive hard fork.

Second is that transitioning Bitcoin to post-quantum signatures cannot be done passively: coin holders must actively migrate their funds. This means abandoned but still quantum-vulnerable coins are unprotected. Estimates suggest that hundreds of thousands of BTC could be vulnerable due to quantum weakness, worth hundreds of billions of dollars at current prices (as of December 2025).

However, quantum threats are unlikely to cause a “catastrophic overnight collapse” of Bitcoin. More plausibly, they will lead to a gradual, selective attack process. Quantum computers will not break all cryptography at once — Shor’s algorithm must target specific public keys one by one. Early quantum attacks will be costly and slow. Once a quantum computer can crack a single Bitcoin’s signing key, attackers will prioritize the most valuable wallets.

Additionally, as long as users avoid address reuse and do not use Taproot addresses (which expose the public key on-chain), they are relatively protected: their public keys remain hidden until they make a transaction. When they broadcast a transaction, the public key becomes visible, creating a short “race window”: honest users want their transactions confirmed quickly, while quantum attackers may attempt to derive private keys before confirmation and steal funds. Therefore, coins with public keys exposed for years — early P2PK outputs, reused addresses, Taproot holdings — are most vulnerable.

For abandoned, vulnerable coins, there are no easy solutions today. Options include:

• The Bitcoin community agreeing on a “flag day,” after which all un-migrated coins are considered destroyed.
• Allowing anyone with a CRQC to take over abandoned, exposed coins.

The second option raises serious legal and security issues: using a quantum computer to claim funds without the private key — even claiming lawful ownership or good intent — could violate theft and computer fraud laws in many jurisdictions.

Furthermore, “abandoned” relies on the assumption of inactivity, but nobody can be certain whether these coins are truly lost or just inactive. Even if someone proves they once held those coins, they may not have the legal authority to “reclaim” them by breaking cryptography. This legal ambiguity makes those exposed, abandoned coins highly susceptible to malicious attacks ignoring legal constraints.

Another challenge is Bitcoin’s extremely low transaction throughput. Even after migration plans are finalized, moving all vulnerable funds to post-quantum addresses could still take months at current transaction speeds.

These challenges mean Bitcoin must start planning for post-quantum migration now — not because CRQC is likely before 2030, but because coordinating governance, reaching consensus, and the logistical process involving billions of dollars will take years.

The threat of quantum computing to Bitcoin is real, but the pressure stems more from Bitcoin’s own structural limitations than from the proximity of quantum computers. Other blockchains face similar issues with quantum-vulnerable funds, but Bitcoin is especially unique: the earliest transactions used pay-to-public-key (P2PK) outputs, exposing public keys on-chain and putting a large portion of BTC at risk. Its technical history, long chain age, high value concentration, low throughput, and rigid governance make the problem particularly severe.

It’s important to note that these vulnerabilities only concern the cryptographic security of Bitcoin signatures — not its economic security. Bitcoin’s economic security relies on its proof-of-work (PoW) consensus mechanism, which is less susceptible to quantum attacks for three reasons:

PoW depends on hash functions, and thus would only experience a quadratic speedup via Grover’s algorithm, not exponential as with Shor’s algorithm.

Implementing Grover’s search is costly enough that even a modest quantum speedup in PoW is unlikely.

Even if a quantum computer provides a significant advantage, it would mainly benefit large mining operations, not fundamentally undermine Bitcoin’s economic security model.

Post-quantum signatures: costs and risks

To understand why blockchain should not rush to deploy post-quantum signatures, we need to consider both performance costs and the evolving confidence in post-quantum security.

Most post-quantum cryptography relies on one of five approaches: hashing, error-correcting codes, lattices, multivariate quadratic equations (MQ), or isogenies.

Why five approaches? Because the security of any post-quantum primitive depends on an assumption: that quantum computers cannot efficiently solve a specific mathematical problem. The stronger the problem’s structure, the more efficient the resulting cryptographic scheme can be.

But this is a double-edged sword: more structure also means a larger attack surface, making algorithms more vulnerable to breakthroughs. This creates a fundamental tension — stronger assumptions yield better performance but come with potentially weaker security.

Overall, from a security perspective, hash-based schemes are the most conservative and reliable, since we have the highest confidence that quantum computers cannot efficiently attack them. But their performance is the worst. For example, the NIST standard hash-based signature schemes, even at minimal parameter settings, produce signatures of 7–8 KB — compared to current elliptic curve signatures of only 64 bytes, roughly 100 times smaller.

Lattice schemes are the current focus of deployment. NIST has selected one lattice scheme and two signature algorithms based on lattices. One (ML-DSA, formerly Dilithium) has signature sizes of 2.4 KB at the 128-bit security level, and 4.6 KB at 256-bit security — about 40–70 times larger than current elliptic signatures. Another, Falcon, produces smaller signatures (Falcon-512: 666 bytes; Falcon-1024: 1.3 KB) but relies on complex floating-point operations, making implementation a major challenge. One of Falcon’s architects, Thomas Pornin, calls it “the most complex cryptographic algorithm I’ve ever implemented.”

In terms of implementation security, lattice signatures are much harder than elliptic curve schemes: ML-DSA involves many sensitive intermediate values and complex rejection sampling, which require side-channel and fault attack protections. Falcon adds the complexity of constant-time floating-point arithmetic; multiple side-channel attacks have successfully recovered private keys from Falcon implementations.

These risks are immediate and distinct from the distant threat of a “cryptographically relevant quantum computer.”

Caution is justified in adopting higher-performance post-quantum schemes. Historically, schemes like Rainbow (based on MQ signatures) and SIKE/SIDH (based on isogenies) have been “classically broken” — i.e., cracked by current computers, not quantum computers.

This occurred after the NIST standardization process was already underway, highlighting that premature standardization and deployment can be counterproductive.

As mentioned, internet infrastructure is proceeding cautiously with signature migrations. This is important because transitioning the internet’s cryptography often takes many years. Even algorithms like MD5 and SHA-1, once deprecated years ago, continue to be used in some contexts — not because they are just “possibly crackable in the future,” but because they have been fully broken.

Unique challenges for blockchain vs. internet infrastructure

Fortunately, open-source community-maintained blockchains (like Ethereum and Solana) can upgrade more quickly than traditional internet infrastructure. Conversely, internet infrastructure benefits from frequent key rotations, which change the attack surface faster than quantum computers can keep up — but blockchains cannot, since coins and keys could be exposed indefinitely. Overall, blockchains should adopt a cautious approach similar to the internet for signature migration. Neither is affected by signature HNDL attacks, but migrating too early to immature post-quantum schemes remains costly and risky, regardless of key lifecycle.

Additionally, blockchains face unique challenges that make early migration especially dangerous and complex: for example, the need for “fast aggregation of many signatures.” Current popular schemes like BLS signatures enable efficient aggregation but are not post-quantum secure. Researchers are exploring SNARK-based post-quantum signature aggregation schemes. While progress is promising, they are still early-stage.

For SNARKs themselves, the community mainly focuses on hash-based post-quantum structures. But a major shift is imminent: I am confident that in the coming months and years, lattice schemes will become the most attractive alternatives. They will offer better performance in multiple dimensions, such as shorter proof lengths — similar to how lattice signatures are shorter than hash-based signatures.

The more pressing issue today: implementation security

In the coming years, implementation flaws will be more realistic and severe threats than the distant threat of a “cryptographically relevant quantum computer.” For SNARKs, primary concerns are bugs.

Bugs are the main challenge in digital signatures and encryption algorithms, and SNARKs are even more complex. In fact, a digital signature scheme can be viewed as a highly simplified zkSNARK to prove “I know the private key corresponding to this public key and I authorized this message.”

For post-quantum signatures, the immediate risks include implementation attacks like side-channel and fault injection attacks. These have been empirically demonstrated and can extract private keys from real systems. Their threat is far more urgent than the distant quantum attack.

The community will continue to identify and fix SNARK vulnerabilities, and to harden post-quantum signatures against side-channel and fault attacks in the coming years. Premature migration to immature zkSNARKs and signature aggregation schemes risks locking blockchain systems into suboptimal solutions — and if better schemes emerge or current schemes are found to have serious implementation flaws, a second migration may be necessary.

What should we do? Seven recommendations

Based on the realities discussed above, I offer the following recommendations for various participants — from developers to policymakers. The guiding principle is: take quantum threats seriously, but do not act under the assumption that “a cryptographically relevant quantum computer will definitely appear before 2030.” The current state of technology does not support this assumption. However, there are many preparatory steps we can and should take now:

1. Deploy hybrid encryption immediately

At least in scenarios where long-term confidentiality is critical and performance overhead is acceptable. Many browsers, CDNs, and messaging apps (like iMessage and Signal) have already deployed hybrid schemes. Hybrid schemes — post-quantum + classical — can resist HNDL attacks and protect against potential vulnerabilities of post-quantum schemes themselves.

2. Use hash signatures immediately where large signatures are tolerable

Low-frequency, size-insensitive scenarios like software/firmware updates should adopt hybrid hash signatures now. (Hybrid schemes are a safeguard against potential implementation flaws, not because the security of hash functions is in question.) This conservative approach provides a “lifeboat” for society in case quantum computers arrive unexpectedly early. Without software update mechanisms supporting post-quantum signatures, deploying quantum-resilient cryptography after CRQC’s arrival will be problematic.

3. Blockchain does not need to rush deploying post-quantum signatures — but should start planning now

Blockchain developers should learn from Web PKI practices to cautiously advance post-quantum signature deployment. This gives the schemes time to mature in terms of performance and security understanding. It also allows system redesigns to accommodate larger signatures and develop better aggregation techniques. For Bitcoin and other Layer 1 chains, the community needs to develop migration paths and policies for handling quantum-vulnerable, abandoned funds. Passive migration is impossible; planning is crucial. The challenges faced by Bitcoin are mostly non-technical — slow governance and a large amount of potentially abandoned, quantum-vulnerable addresses — emphasizing the need for early planning.

Meanwhile, research on post-quantum zkSNARKs and aggregatable signatures should continue to mature (likely over several years). Again, early migration risks locking in suboptimal solutions or having to re-migrate after discovering implementation flaws.

Regarding Ethereum’s account model: Ethereum supports two account types, with different implications for post-quantum migration — externally owned accounts (EOAs) controlled by secp256k1 private keys, and smart contract wallets with programmable authorization logic.

In non-emergency scenarios, when Ethereum adds post-quantum signatures, upgradable smart wallets can switch to post-quantum verification via contract upgrades. EOAs may need to transfer assets to new post-quantum addresses (though Ethereum might also provide dedicated migration mechanisms). In urgent cases, Ethereum researchers propose hard forks: freezing vulnerable accounts and allowing users to prove control of their mnemonic via post-quantum zkSNARKs to recover assets. This mechanism applies to EOAs and un-upgraded smart wallets.

For users, well-audited, upgradable smart wallets can offer smoother migration paths — but the difference is modest, involving trust in wallet providers and governance. More important is that Ethereum continues to develop post-quantum primitives and emergency plans.

Broader design lessons: many blockchains tightly couple account identities with specific cryptographic primitives — for example, Bitcoin and Ethereum bind accounts to secp256k1, others use EdDSA. The difficulty of post-quantum migration underscores the value of decoupling account identities from specific signature schemes. Ethereum’s move toward “smart accounts” and similar account abstraction trends embody this approach: enabling account upgrades while preserving on-chain history and state. This does not make migration trivial but offers much more flexibility compared to fixing accounts to a single signature scheme. It also enables features like pay-to-contract, social recovery, multisignatures, etc.

4. For privacy coins, prioritize migration when performance allows

These chains encrypt or hide transaction details, so user privacy is currently exposed to HNDL — severity varies by design. Chains relying solely on public ledgers are at highest risk of future de-anonymization once quantum computers can break elliptic curve cryptography. Hybrid schemes (post-quantum + classical) can be adopted to mitigate risks, or architectures can be redesigned to avoid storing decryptable secrets on-chain.

5. Focus on implementation security first — not just quantum threat mitigation

Especially for complex primitives like zkSNARKs and post-quantum signatures, bugs and implementation attacks (side-channel, fault injection) will be more immediate and severe in the coming years than the distant threat of a “cryptographically relevant quantum computer.” Investments should prioritize auditing, fuzzing, formal verification, and multi-layer defenses — do not let fear of quantum threats overshadow the urgent risks posed by bugs.

6. Support quantum computing development

From a national security perspective, continuous investment in quantum research and talent cultivation is essential. If leading adversary nations achieve CRQC earlier than the US, it could pose serious security risks globally.

7. Maintain a realistic perspective on quantum computing announcements

As hardware matures, many milestone headlines will appear. Paradoxically, the frequent occurrence of these milestones indicates we are still far from CRQC. Each milestone is just a step toward the ultimate goal and will generate media excitement. News should be viewed critically, as progress reports rather than signals to act immediately.

Certainly, breakthroughs could accelerate timelines, or setbacks could delay them.

I emphasize that I do not believe a CRQC will appear within five years — only that it is “highly unlikely.” These recommendations are designed to be robust against this uncertainty and help us avoid more immediate, realistic risks: bugs, premature deployment, and common cryptographic migration errors.

Justin Thaler is a16z research partner and associate professor of computer science at Georgetown University. His research areas include verifiable computation, complexity theory, and algorithms for large data sets.