Five major blockchain networks have published post-quantum migration roadmaps in 2026, each selecting different cryptographic primitives, timelines, and architectural trade-offs. Bitcoin's BIP 360 proposes a new output type that hides public keys behind Merkle roots. Ethereum targets full quantum...
"The quantum threat may be MUCH closer than we think." — Eli Ben-Sasson, CEO, StarkWare
Five major blockchain networks have published post-quantum migration roadmaps in 2026, each selecting different cryptographic primitives, timelines, and architectural trade-offs. Bitcoin's BIP 360 proposes a new output type that hides public keys behind Merkle roots. Ethereum targets full quantum resistance across three protocol layers by December 2029. Solana's two core engineering teams have independently converged on Falcon signatures. Starknet announced on October 8 it is considering a departure from Ethereum's Layer 2 architecture to become an independent Layer 1, citing quantum urgency. Sui is the closest to production, with native ML-DSA-65 accounts targeting testnet by year-end and mainnet in Q1 2027.
The urgency is real but unevenly distributed. Europol's October 7, 2026 report estimated 6.9 million BTC ($586 billion) and 55–60% of all ETH sit in addresses with exposed public keys — the precise attack surface a cryptographically relevant quantum computer (CRQC) would target. Google Quantum AI's March 2026 paper reduced the estimated qubit requirement to break secp256k1 to fewer than 500,000 physical qubits, a 20x reduction from prior estimates. No machine at that scale exists today — IBM's Heron processor operates at 156 qubits, Google's Willow at 105 — but the shrinking gap between current hardware and the theoretical threshold has compressed migration timelines across the industry.
The quantum threat to blockchains is narrow and specific. It targets the elliptic curve digital signature algorithm (ECDSA) and Ed25519 schemes used to authorize transactions — not consensus mechanisms, not hash functions, not mining algorithms. Shor's algorithm, run on a sufficiently powerful quantum computer, can derive a private key from an exposed public key in polynomial time.
Hash functions (SHA-256, RIPEMD-160, Keccak-256) remain comparatively resistant. Grover's algorithm provides only a quadratic speedup against hash preimage attacks, meaning a 256-bit hash still offers approximately 128 bits of quantum security — generally considered sufficient.
The immediate risk is structural: blockchain data is public, permanent, and cannot be retroactively re-encrypted. Every exposed public key is already harvestable. Europol's second October 2026 report, developed with Carlos III University of Madrid, named this the "harvest now, decrypt later" (HNDL) vector — though the agency found no clear evidence of systematic HNDL campaigns targeting blockchains at scale.
Approach: New output type — Pay-to-Merkle-Root (P2MR) Status: Draft BIP merged February 2026; testnet implementation by BTQ Technologies (v0.3.0, March 2026) Mainnet activation: Not scheduled Signature scheme: Scheme-agnostic (P2MR does not mandate a specific post-quantum signature algorithm)
BIP 360, authored by Hunter Beast, Ethan Heilman, and Isabel Foxen Duke, introduces SegWit version 2 outputs using bc1z address encoding via bech32m. The design removes Taproot's key-path spend entirely. The output commits only to a Merkle root of the script tree, meaning no public key is exposed on-chain at any point during the coin's lifecycle — until it is spent.
This is an architectural defense, not a cryptographic upgrade. P2MR addresses the "long-exposure" problem: coins sitting for years with visible public keys. It does not solve the "short-exposure" window — the period between a transaction entering the mempool and being confirmed, during which the spending public key is briefly visible.
The scheme-agnostic design is deliberate. Bitcoin's governance process moves slowly; BIP 360 avoids binding the network to a specific post-quantum algorithm that NIST might later deprecate. Migration would be voluntary. The approximately 1.92 million BTC in early P2PK outputs (including coins attributed to Satoshi Nakamoto) cannot be migrated without the original key holder's action.
Key limitation: Bitcoin has no account model and no mechanism to force migration. Legacy funds remain exposed indefinitely unless owners move them to P2MR outputs.
Approach: Full-stack quantum resistance across execution, consensus, and data layers Status: Roadmap published; development underway Target: December 2029 Signature scheme: Hash-based signatures (Winternitz), STARKs for aggregation
The Ethereum Foundation's Protocol Cluster has set what it describes as an "intentionally aggressive" deadline: full quantum resistance by December 2029. Planning assumes CRQCs could emerge as early as 2030, though most industry estimates place the timeline later.
Ethereum's migration is the most complex of the five chains examined here. Four protocol components rely on quantum-vulnerable cryptography:
ECDSA account signatures — every externally owned account (EOA) that has initiated a transaction has its public key permanently exposed on-chain. Ethereum's account-based architecture, unlike Bitcoin's UTXO model, makes this exposure structural and pervasive.
BLS validator signatures — Ethereum's 900,000+ validators use BLS12-381 for block attestations. Replacement candidates include hash-based schemes like Winternitz, with STARKs used to aggregate multiple post-quantum signatures into compact proofs to control consensus overhead.
KZG polynomial commitments — the data availability sampling pipeline used by rollups relies on KZG, which is quantum-vulnerable. This is the most engineering-intensive replacement, as it touches L2 settlement infrastructure.
Application-layer ZK proof systems — some rollups and privacy protocols use SNARKs with quantum-vulnerable setup assumptions.
Vitalik Buterin's "Lean Ethereum" initiative, developed with researcher Justin Drake, frames this migration as part of a broader protocol simplification. Post-quantum cryptography is bundled with reduced validator requirements, formal verification tooling, and EVM restructuring.
Key limitation: The 2029 deadline depends on parallel development across four distinct cryptographic subsystems. A delay in any one — particularly the KZG replacement — could push the full migration past the target.
Approach: Phased wallet migration starting with new accounts Status: Testnet implementations running; Winternitz Vault operational for 2+ years Target: Phased, no hard deadline published Signature scheme: Falcon (NIST FN-DSA)
Solana's two core engineering teams — Anza and Jump Crypto's Firedancer — independently converged on the Falcon signature scheme, a NIST-standardized lattice-based algorithm. This convergence is notable: independent selection of the same primitive by competing engineering teams suggests Falcon's properties (compact signatures, fast verification) are well-suited to Solana's high-throughput architecture.
At NIST Level I, a padded Falcon-512 signature is 666 bytes — 3.6x smaller than a comparable ML-DSA signature at 2,420 bytes. On ARMv8-A hardware, Falcon verification runs 3–4x faster than ML-DSA. The hybrid Falcon-512 scheme showed only a 14% decrease in throughput compared to pure ECDSA in testing, according to Algorand's technical benchmarks (which tested the same algorithm).
Solana's roadmap centers on phased adoption: new wallets first, then gradual migration of the existing base. The network already has a quantum-resistant primitive in production — Blueshift's Winternitz Vault, operational within the Solana ecosystem for over two years. Google Quantum AI has recognized the Winternitz Vault as a leading solution in the blockchain space.
Key limitation: Falcon signing is approximately 2x slower than Dilithium/ML-DSA signing. For a network processing thousands of transactions per second, the signing bottleneck could constrain validator performance during peak load. No hard migration deadline has been published.
Approach: Transition from Ethereum L2 to independent L1 using hash-based STARK proofs Status: Under governance consideration; announced October 8, 2026 Target: 2027 Cryptographic basis: ZK-STARKs (hash-function-based, no elliptic curve dependency)
StarkWare CEO Eli Ben-Sasson announced on October 8, 2026 that Starknet is "actively considering becoming an L1." The rationale: Ethereum's 2029 quantum timeline is too slow. Starknet's STARK proof system relies on hash functions rather than elliptic curves, giving it structural quantum resistance that Ethereum's base layer lacks.
The argument is architecturally coherent. As an L2, Starknet inherits Ethereum's security assumptions — including its quantum-vulnerable signature layer. Becoming an L1 would let Starknet establish its own validator framework with quantum-safe cryptography from the ground up, rather than waiting for Ethereum's four-subsystem migration to complete.
The market responded: STRK rallied approximately 39% in the 24 hours following the announcement. Any protocol change requires governance approval. Becoming an L1 would require Starknet to build its own security and validator infrastructure — a substantial engineering and economic undertaking that trades Ethereum's established security budget for independence.
Key limitation: L1 independence means Starknet would need to bootstrap its own economic security. Ethereum's validator set secures approximately $120 billion in staked ETH. Starknet's STRK token has a fraction of that market capitalization. The quantum-resistance argument is technically sound; the economic security trade-off is unresolved.
Approach: Native post-quantum accounts with in-place key rotation Status: Implementation underway; testnet targeted by end of 2026 Target: Mainnet Q1 2027 Signature scheme: ML-DSA-65 (NIST FIPS 204, Level 3)
Sui is the closest to shipping production-ready post-quantum accounts among the five chains. The network plans to integrate ML-DSA-65 as a native signing option, corresponding to NIST's FIPS 204 digital signature standard at Security Level 3.
The migration design leverages Sui's existing Address Alias feature, which allows an account to update its authorization key without transferring assets. Users can transition to quantum-safe keys while keeping their existing addresses and on-chain state intact. Because Sui keys derive deterministically from a seed, users can upgrade to a quantum-safe key using the recovery phrase they already hold.
This is the smoothest migration path of the five chains. No fund transfers required. No new address format. No hard fork. The post-quantum key simply replaces the existing authorization key on the same account.
Key limitation: ML-DSA-65 signatures are 3,309 bytes — approximately 50x larger than Ed25519 signatures (64 bytes). Public keys are 1,952 bytes versus 32 bytes. This will increase on-chain storage and bandwidth requirements. Sui's object-centric data model may absorb this more gracefully than account-based chains, but the storage cost increase is non-trivial at scale.
| Chain | Scheme | Signature Size | Target Date | Status | Migration Model | |-------|--------|---------------|-------------|--------|-----------------| | Bitcoin | Scheme-agnostic (P2MR) | Varies | Not set | Draft BIP, testnet | Voluntary; new output type | | Ethereum | Winternitz + STARKs | TBD | Dec 2029 | Roadmap phase | Full protocol upgrade | | Solana | Falcon-512 | 666 bytes | Phased, no date | Testnet running | New wallets first | | Starknet | Hash-based STARKs | N/A (proof-based) | 2027 | Governance review | L1 pivot | | Sui | ML-DSA-65 | 3,309 bytes | Q1 2027 | Implementation | In-place key rotation |
Post-quantum signatures are uniformly larger than their classical counterparts. An ECDSA signature is 64–72 bytes. The smallest post-quantum option in active blockchain deployment plans — Falcon-512 at 666 bytes — is roughly 10x larger. ML-DSA-65, chosen by Sui, produces signatures approximately 50x larger than Ed25519.
This size increase has direct economic consequences. Larger signatures mean larger transactions, higher storage requirements, increased bandwidth consumption, and — on chains with byte-based fee markets — higher transaction costs. Ethereum's rollup ecosystem, which compresses transaction data into blobs, faces a compounding effect: post-quantum signatures in the data availability layer would increase blob consumption and, consequently, L2 operating costs.
Falcon offers the best size-to-security ratio among NIST-standardized options, which explains Solana's selection. But Falcon's signing process is more complex (approximately 2x slower than ML-DSA), creating a trade-off between on-chain compactness and validator-side compute cost.
Bitcoin's P2MR approach sidesteps the signature-size problem entirely by deferring the choice of post-quantum signature algorithm. This is either prudent conservatism or a governance bottleneck, depending on perspective.
No chain has shipped post-quantum cryptography to mainnet. Sui is closest, targeting Q1 2027. The gap between roadmap and production remains significant across the industry.
The five chains have selected four different cryptographic approaches — scheme-agnostic deferral (Bitcoin), hash-based signatures with STARK aggregation (Ethereum), Falcon lattice-based signatures (Solana), hash-based STARK proofs via L1 pivot (Starknet), and NIST ML-DSA lattice-based signatures (Sui). No consensus has emerged on the optimal post-quantum primitive for blockchains.
Migration mechanics vary as much as cryptography. Sui's in-place key rotation is the least disruptive. Bitcoin's voluntary output migration is the most dependent on user action. Ethereum's full-stack overhaul is the most ambitious and complex.
Signature size inflation is the universal cost. Every post-quantum scheme produces signatures 10–50x larger than classical ECDSA/Ed25519. The throughput, storage, and fee implications have not been fully benchmarked at production scale on any chain.
The timeline gap is closing. Google Quantum AI's March 2026 paper cut the estimated qubit requirement by 20x. The Europol October 2026 reports framed the threat as a present-day harvesting risk, not a future hypothetical. Chains that treat post-quantum migration as a 2030+ concern are implicitly betting that CRQC development will stall.
The post-quantum migration is a stress test of blockchain governance as much as blockchain cryptography. Bitcoin's scheme-agnostic approach reflects its conservative governance culture but leaves $586 billion in exposed funds without a migration mechanism. Ethereum's 2029 deadline is ambitious but depends on replacing four interdependent cryptographic subsystems simultaneously. Solana's Falcon selection optimizes for its high-throughput architecture but lacks a firm deadline. Starknet's L1 pivot is the most radical architectural response, trading Ethereum's economic security for cryptographic independence. Sui's ML-DSA-65 integration offers the cleanest migration path but imposes the largest signature-size overhead.
All five approaches carry real trade-offs. None is clearly superior across all dimensions. The chains that reach production first will not necessarily have chosen the best cryptography — they will have chosen the cryptography their governance process could ship fastest. Whether that distinction matters depends on a variable no one controls: when the first CRQC arrives.