Quantum Computing's Real Threat to Blockchain

A Migration Playbook for L1s, Wallets, and Smart Contracts Byiringiro Thierry · April 2026

1. Abstract

There are two ways to talk about quantum threats to blockchain. The popular one is "quantum computers will break Bitcoin" — usually accompanied by a misleading "Bitcoin uses SHA-256, which is vulnerable to Grover" framing. The serious one — which this paper takes — quantifies which primitives are vulnerable, which are not, and what the actual migration burden looks like.

Three calibrated claims:

1. Hash functions are essentially safe. Grover's algorithm gives a quadratic speedup against pre-image attacks. SHA-256 retains 2^128 security against a quantum adversary, which is comfortable. SHA-3 and BLAKE3 are similarly fine.
2. ECDSA signatures are the real exposure. Shor's algorithm gives polynomial-time discrete-log break. Every blockchain using secp256k1 (Bitcoin, Ethereum) or Ed25519 (Solana, Aptos, Sui) has an ECDSA-vulnerable signature scheme. Once a cryptographically-relevant quantum computer exists, signing keys are at risk.
3. The vulnerable surface is smaller than headlines suggest. Only addresses that have revealed their public key on-chain are exposed before they spend. P2WPKH-style addresses (Bitcoin segwit, native segwit) reveal only the hash of the public key — pre-image of which is, again, hash-secured. Address types matter enormously.

The remainder of this paper details these claims, provides a migration playbook, and proposes a five-year timeline (2027-2032).

2. The threat surface, chain by chain

2.1 Bitcoin

Bitcoin's threat surface is address type-dependent:

Two important nuances:

• Satoshi's coins (~1M BTC across P2PK addresses) are entirely exposed. A sufficient quantum adversary can spend them. This is the "Satoshi gets liquidated" scenario.
• Taproot was a mistake from a PQ perspective. Taproot reveals the public key on-chain. The ~20% of supply in P2TR addresses is at risk before spending. The 2021 Taproot upgrade traded a marginal privacy gain for substantial PQ exposure. The right Bitcoin response is either a soft-fork to a hash-of-PQ-pubkey address type, or to allow PQ signatures via a future op-code.

2.2 Ethereum

Ethereum's threat surface is narrower in one dimension but wider in another:

• Narrower: EOA (externally owned account) addresses are derived from the hash of the public key. Until you make your first transaction, your public key is not on-chain.
• Wider: After your first transaction, your public key is on-chain (in the signature recovery). Any address that has ever sent a transaction is exposed. This is essentially every EOA with any balance.
• Smart contracts depend on their authorization model. Multisigs using ECDSA-keyed signers are exposed; ZK-rollup signatures that recurse to ECDSA are exposed; EIP-4337 paymaster signatures are exposed.

ERC-4337 Account Abstraction is the Ethereum-side migration vehicle: AA wallets can validate signatures with any logic, including post-quantum schemes. The migration burden is wallet-side, not protocol-side.

2.3 Solana

Solana uses Ed25519. From a PQ perspective:

• Ed25519 is also vulnerable to Shor's algorithm (discrete log over a different curve, but same complexity class for quantum).
• Solana account addresses are the public key — every account is exposed from creation. Worse than Bitcoin's segwit, worse than Ethereum's hash-derived addresses.

The Solana migration story is harder than Bitcoin or Ethereum and largely requires a hard fork to a new account model. The 2025 SIMD discussions around PQ migration acknowledge this but no concrete proposal is approved as of April 2026.

2.4 Emerging L1s

Hyperliquid (and other recent purpose-built L1s) have an advantage: less legacy state. PQ migration is a fork-and-forget operation if the existing user base is willing to redeem positions on a frozen snapshot and re-onboard on a PQ chain.

This is the architectural luxury of being new. Bitcoin and Ethereum cannot do this without breaking sacred social contracts. Hyperliquid can.

3. The "Q-day" timeline, calibrated

There is no single "Q-day" event. The relevant question is: at what point does a single CRQC (cryptographically-relevant quantum computer) exist with enough logical qubits to run Shor's algorithm on a 256-bit ECDSA key?

Estimates from credible sources, April 2026:

A reasonable working assumption: a CRQC capable of breaking ECDSA exists sometime in the 2030s, with the lower bound around 2030 and the upper bound around 2040. Plan accordingly.

The harvest-now-decrypt-later argument applies less directly to blockchain than to general crypto: on-chain data is already public. There's no "stored ciphertext to decrypt later." The threat is forward-looking, not retrospective.

But: the threat manifests abruptly when the first CRQC is deployed. There is no graceful transition from "ECDSA is fine" to "ECDSA is broken." Once a CRQC is available to a nation-state, every exposed key is at risk at once.

4. Migration playbook by chain

4.1 Bitcoin

Soft-fork approach. Proposed BIPs (as of 2026):

• BIP-360 (post-quantum addresses, in draft) — a new address type that commits to a hash of a post-quantum public key. Spending requires producing the PQ public key + signature.
• A future soft-fork for ML-DSA or SLH-DSA verification. SLH-DSA is the conservative choice; signature size (~8 KB) is the cost.

Migration cost: every UTXO holder must spend their UTXO to a new PQ address before Q-day. Wallets must support PQ key generation and storage.

4.2 Ethereum

ERC-4337 + new signature validators. Concrete steps:

1. AA wallets deploy a validate(userOp) function that accepts ML-DSA signatures.
2. Users migrate from EOAs to AA wallets before their PQ exposure window opens (post first transaction).
3. EOAs become deprecated; a future EIP enforces AA-only deployment.

This is the cleanest of the three migrations. ERC-4337 was not designed with PQ in mind but happens to enable it cleanly.

4.3 Solana

Requires a chain-level upgrade. The proposed SIMD (2025) introduces a PQAccount type alongside the existing Account model. Old accounts can be migrated by signing a one-time migration transaction that commits to a PQ key.

Hard fork in coordination with major wallets (Phantom, Solflare, Backpack) and the validator set. Realistically: 2029-2030 timeframe.

4.4 Smart contracts and bridges

Bridges using ECDSA multi-sigs are cross-chain attack surfaces. A bridge governed by ECDSA-signed multi-sig is broken if any signer's key is exposed. Migration:

• BLS-based multi-sigs are also vulnerable (BLS is pairing-based, vulnerable to Shor over its base curve).
• Move to ML-DSA or SLH-DSA multi-sigs. Larger signatures, but cleanly post-quantum.

5. The wallet UX challenge

The technical migration is solvable. The UX migration is harder.

• Larger keys. ML-DSA-65 public keys are 1,952 bytes. Hardware wallets with 256-byte secure-element key slots need re-engineering.
• Larger transactions. ML-DSA signatures are 3,309 bytes. A typical Ethereum transaction balloons from ~120 bytes to ~3,400 bytes — 28× larger. Gas costs scale; bandwidth scales; mempool sizes scale.
• Recovery flows. Most "I lost my seed phrase" recovery flows assume short BIP-39 24-word phrases. PQ keys cannot be expressed as 24 words easily. Wallet recovery UX needs a redesign — likely via account-recovery social-recovery flows rather than seed-phrase regeneration.

The wallets that solve this first win wallet market share for a decade.

6. Five-year timeline (2027-2032)

A coordinated migration timeline, by year:

This is aggressive but plausible. The slower-case is +3 years on each milestone.

7. Implications

For long-term holders. If you intend to hold a UTXO unspent through 2032, move it to a PQ-safe address type as soon as one is available on your chain. The cost is one transaction fee; the upside is forward security.

For smart-contract authors. Audit your authorization model. Any contract that hard-codes ECDSA-signature verification (ecrecover-style) is a PQ liability. Build dispatch on a signature-scheme tag from day one.

For exchanges and custodians. This is operational risk, not just technical risk. Insurance underwriters in 2030 will price PQ-non-compliance as a material liability. The earliest movers get the lowest premia.

For protocols building today. Make your authentication layer scheme-agile. The cost of scheme-agility is two days of engineering; the cost of not having it is a hard fork in 2030.

8. Conclusion

The quantum threat to blockchain is real, narrower than headlines suggest, and has a five-year migration path that the major chains can credibly execute. The technical primitives exist (ML-KEM, ML-DSA, SLH-DSA, all NIST-finalized as of 2024). The protocol-level migration vehicles exist (BIPs, EIPs, SIMD). The wallet UX is the bottleneck, and the wallets that solve it first win.

The bet I would make: chains with smaller, newer footprints (Hyperliquid, Aptos, Sui, modern L2s) migrate first and cleanest. Bitcoin and Ethereum drag, but ultimately migrate. Solana is the swing case — its address model is the most exposed and its governance is centralized enough to execute a fast hard fork. Watching Solana's PQ migration timeline is the leading indicator for the rest of the space.

---

References

1. Shor — Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer (1994)
2. Mosca — Cybersecurity in an Era with Quantum Computers (revised 2024)
3. Gidney & Ekerå — How to Factor 2048 Bit RSA Integers in 8 Hours Using 20 Million Noisy Qubits (2025)
4. BIP-360 draft — Pay to Quantum Resistant Hash (Bitcoin, 2025)
5. ERC-4337 — Account Abstraction Using Alt Mempool (Ethereum, 2023)
6. NIST FIPS 203/204/205 — Post-Quantum Cryptography Standards (August 2024)
7. Solana Foundation — SIMD for Post-Quantum Account Types (Draft) (2025)