Quantum-Resistant Blockchain: Required Knowledge, Tooling & Major Chain Strategies

Part 1: Required Knowledge & Tooling

1. Cryptography Prerequisites — Post-Quantum Cryptography (PQC) Algorithms

Post-quantum cryptography encompasses cryptographic algorithms believed secure against cryptanalytic attacks by quantum computers, though not proven so ¹. The NIST PQC standardization process, concluded in August 2024, finalized three standards built on different mathematical hard problems ²:

Lattice-Based (the primary family):

• ML-KEM (FIPS 203) — formerly CRYSTALS-Kyber. Module-lattice-based key encapsulation mechanism. Primary PQC standard for key exchange. Public key ~1,184 bytes, ciphertext ~1,088 bytes for ML-KEM-768 ².
• ML-DSA (FIPS 204) — formerly CRYSTALS-Dilithium. Module-lattice-based digital signature algorithm. Primary PQC standard for signatures. ML-DSA-65 signatures are ~3,300 bytes (vs. ECDSA's 71 bytes for secp256k1) ²³.
• FN-DSA (pending standardization) — formerly Falcon. Lattice-based signature with smaller signatures (~690 bytes for Falcon-512) but more complex implementation. Selected for ongoing standardization ⁴.

Hash-Based:

• SLH-DSA (FIPS 205) — formerly SPHINCS+. Stateless hash-based digital signature. Extremely conservative security assumptions (relies only on hash function security). Signatures are large: SPHINCS+-128f produces ~7,856-byte signatures ²³. Ethereum's leanXMSS is also hash-based but uses a stateful XMSS construction (NIST SP 800-208) ⁵.

Code-Based:

• Classic McEliece — based on the syndrome decoding problem for binary Goppa codes. Very large public keys (~261 KB for McEliece-6960119) but small ciphertexts. Not yet finalized as a FIPS standard but remains in the NIST Round 4 process ⁴.

Isogeny-Based:

• SQIsign — short signatures (~1-2 KB) based on isogeny problems. Still in NIST's additional digital signature evaluation. Previously, SIKE was broken classically in 2022, demonstrating that isogeny-based crypto requires careful scrutiny ⁴.

What a developer must understand:

1. The mathematical foundations differ fundamentally from ECC — lattice problems (LWE/RLWE/Module-LWE), hash preimage resistance, and code decoding hardness replace discrete logarithms.
2. Hybrid deployment (classical + PQC simultaneously) is the recommended transitional approach to hedge against both classical and quantum breaks ¹.
3. Parameter selection matters: ML-DSA-44/65/87 trade off security level vs. signature size. For blockchain, size is critical.
4. Stateful hash-based signatures (XMSS/LMS) require careful state management — signing keys can only be used a bounded number of times, making them unsuitable for general transaction signing but viable for validator attestation ⁵.

2. Quantum Threat Model

Shor's Algorithm — Solves integer factorization and discrete logarithm problems in polynomial time on a quantum computer. This directly breaks:

• ECDSA (secp256k1, used by Bitcoin and Ethereum)
• Ed25519 (used by Solana)
• BLS signatures (used by Ethereum consensus)
• RSA (used in some legacy systems)

If a cryptographically relevant quantum computer (CRQC) runs Shor's algorithm on a public key, it can derive the private key, enabling signature forgery and fund theft ⁶.

Grover's Algorithm — Provides quadratic speedup for brute-force search. This halves the effective security of symmetric keys: AES-256 effectively becomes AES-128-strength; SHA-256 preimage resistance is halved. Countermeasure: double key sizes for symmetric cryptography. This is not an existential threat to hash functions or symmetric ciphers — just a parameter adjustment ¹.

"Harvest Now, Decrypt Later" (HNDL) — Adversaries collect encrypted traffic today for future decryption when quantum computers become available. For blockchains, this primarily affects confidentiality (encrypted communications, private transaction systems) rather than integrity. Blockchain signatures are already public — the threat is forward-looking: once a CRQC exists, exposed public keys enable private key derivation ⁵⁶.

Timeline Estimates:

• Google Quantum AI (March 2026): Breaking 256-bit ECC may require ~1,200 logical qubits, roughly 20x fewer than earlier estimates. Google set a 2029 internal deadline for PQC migration ⁵.
• NIST IR 8547: ECDSA deprecated by 2030, disallowed by 2035 in US federal systems ⁶⁷.
• CNSA 2.0: US NSA mandates PQC in software/networking by 2030, browsers/OS by 2033 ⁷.
• Most engineering roadmaps place cryptographic relevance in early-to-mid 2030s ⁵.
• Current state (2026): Quantum computers operate with a few thousand noisy physical qubits; logical qubits require many physical qubits each. The gap remains significant but is narrowing ⁵.

Mosca's Theorem provides the urgency framework: if X (migration time) + Y (data secrecy lifetime) > Z (time to CRQC), migration is urgent. For blockchain, X may be 5-10 years, Y is effectively infinite (ledger permanence), and Z is estimated at 8-15 years ¹.

3. Blockchain-Specific PQC Challenges

Signature Size Explosion:

Algorithm	Signature Size	Public Key Size
ECDSA (secp256k1)	71 bytes	33 bytes
Ed25519	64 bytes	32 bytes
BLS12-381	96 bytes	48 bytes
ML-DSA-65	~3,300 bytes	~1,563 bytes
ML-DSA-87	~4,627 bytes	~2,444 bytes
SLH-DSA-128f	~7,856 bytes	~32 bytes
SPHINCS+-128s	~7,856 bytes (small variant)	~32 bytes
leanXMSS	~3,000 bytes	varies

Sources: NIST FIPS 203/204/205 specifications ², BIP-360 draft ⁷.

Gas/Fee Impact: On EVM chains, transaction gas cost is proportional to calldata size. An ML-DSA-65 signature (~3,300 bytes) vs ECDSA (71 bytes) means ~46x more data per transaction. At 16 gas per non-zero byte of calldata, this could add ~50,000+ gas per transaction for signature data alone, before accounting for verification cost differences ³.

State Bloat: Storing larger public keys and signatures on-chain increases storage requirements. For a chain processing millions of transactions, this compounds dramatically. Ethereum's approach with leanVM (250x compression via SNARK aggregation) addresses this for consensus but not yet for individual transactions ⁵.

Consensus Changes: Replacing BLS signatures (which have native aggregation) with post-quantum alternatives that lack aggregation is a fundamental protocol challenge. Ethereum's solution: leanVM for SNARK-based aggregation of hash-based signatures ⁵.

Backward Compatibility: Existing accounts cannot simply be "upgraded" — private keys are fixed. Migration requires either:

1. Account abstraction (Ethereum's approach via EIP-8141) allowing per-account signature scheme choice ⁵.
2. New address types (Bitcoin's BIP-360 P2MR approach) ⁷.
3. Hard forks that invalidate old key types (most disruptive).

Key Migration: Users must generate new post-quantum keys and migrate funds. This is a massive coordination problem for chains with hundreds of millions of accounts.

4. Tooling Stack

NIST PQC Standards (Finalized August 2024):

• FIPS 203 — ML-KEM (lattice-based KEM) ²
• FIPS 204 — ML-DSA (lattice-based signature) ²
• FIPS 205 — SLH-DSA (hash-based signature) ²
• Pending: FN-DSA (Falcon) and HQC (code-based KEM) standardization ongoing ⁴

Core Libraries:

• liboqs (Open Quantum Safe) — Open-source C library implementing PQC algorithms. Latest version 0.15.0 (Nov 2025). Part of the Linux Foundation's Post-Quantum Cryptography Alliance. Integrations available for OpenSSL (oqs-provider), OpenSSH, BoringSSL, and language bindings for Rust, Go, Python, Java, C++ ⁸.
• PQClean — Clean, portable, reference C implementations of NIST PQC candidates. Used as upstream for liboqs. Provides standalone implementations suitable for benchmarking, embedded targets, and formal verification ⁹.
• NIST ACVP Testing — Automated Cryptographic Validation Protocol for testing PQC implementations against NIST standards.

Blockchain-Specific Proposals & Frameworks:

• Bitcoin BIP-360 — Pay-to-Merkle-Root (P2MR), a quantum-resistant output type via soft fork. Draft status as of December 2024 ⁷.
• Ethereum pq.ethereum.org — Dedicated Post-Quantum team site tracking all EF PQC work. Weekly interop testing with 10+ client teams. Roadmap: PQ key registry (I*) → PQ sig precompiles (J*) → PQ attestations + leanVM (L*) → PQ sig aggregation + PQ blobs (M*) ⁵.
• Ethereum EIP-8141 — Native account abstraction enabling per-account signature scheme choice. Under consideration for Hegotá hard fork (H2 2026) ⁵.
• Solana — No formal SIP proposal for PQC found as of May 2026. Solana uses Ed25519 (Schnorr) signatures, equally vulnerable to Shor's algorithm.
• QRL — Purpose-built quantum-resistant chain using XMSS hash-based signatures since mainnet launch ¹⁰.

Testnets & Experimental Networks:

• Ethereum runs regular post-quantum devnets with 10+ client teams participating in weekly interop testing ⁵.
• QRL has been running XMSS-based mainnet since 2018 ¹⁰.
• liboqs includes test harnesses and benchmarking frameworks ⁸.

5. Learning Path

For a developer with classical crypto background:

Foundational Knowledge (2-4 weeks):

1. Read NIST's PQC project overview and FIPS 203/204/205 specifications ²⁴.
2. Study "Post-Quantum Cryptography" chapter in any modern crypto textbook, or the PQCrypto conference proceedings.
3. Understand lattice problems: LWE, RLWE, Module-LWE. Resources: Chris Peikert's "A Decade of Lattice Cryptography" (2016) and the ML-KEM/ML-DSA specification rationale.

Hands-On (2-6 weeks): 4. Install liboqs and run the included benchmarks. Compare ECDSA vs ML-DSA-65 signing/verification times and key/signature sizes ⁸. 5. Build a simple transaction signer using ML-DSA via liboqs Python bindings. Observe the signature size difference firsthand. 6. Experiment with PQClean reference implementations for educational clarity ⁹. 7. Deploy hybrid TLS (X25519+ML-KEM-768) using oqs-provider for OpenSSL to understand hybrid deployment patterns.

Blockchain-Specific (4-8 weeks): 8. Read BIP-360 in full — understand P2MR and the long/short exposure attack model ⁷. 9. Study pq.ethereum.org — the most comprehensive blockchain PQC roadmap publicly available ⁵. 10. Implement a simple PQC signature verifier in Solidity (or via precompile) to understand gas implications. 11. Explore QRL's codebase (MIT-licensed, open source) as a production reference for XMSS-based blockchain ¹⁰.

Advanced/Research (ongoing): 12. Study the Poseidon Prize challenges ($1M research prize for hash-based primitive improvements) ⁵. 13. Follow NIST's additional digital signature standardization process for potential new algorithms ⁴. 14. Engage with ethresear.ch post-quantum topics and Ethereum Magicians discussions.

Recommended Courses & Books:

• NIST PQC standardization workshops (recordings available on NIST CSRC)
• "An Introduction to Mathematical Cryptography" by Hoffstein, Pipher, Silverman (foundations)
• IACR ePrint Archive (eprint.iacr.org) — primary source for latest PQC research
• Dan Bernstein & Tanja Lange's "Post-Quantum Cryptography" (Springer)

---

Part 2: What Major Chains Are Doing

6. Bitcoin (BTC)

BIP-360: Pay-to-Merkle-Root (P2MR)

• Authors: Hunter Beast, Ethan Heilman, Isabel Foxen Duke
• Status: Draft (assigned December 18, 2024)
• Type: Consensus (soft fork)
• Requires: BIP-340, 341, 342 (Taproot)

BIP-360 introduces a new output type called Pay-to-Merkle-Root that removes the key path spend from P2TR outputs, leaving only the script tree path. This eliminates long exposure attacks on elliptic curve public keys stored on-chain, because the script tree commitment does not directly expose the public key ⁷.

Key design decisions in BIP-360:

• Addresses "long exposure attacks" (public keys visible on-chain for extended periods) but not "short exposure attacks" (public keys exposed briefly in mempool during transaction confirmation) ⁷.
• Explicitly does not introduce post-quantum signature schemes yet — a separate future proposal is intended for PQ signatures ⁷.
• Provides backward compatibility: existing P2PKH, P2SH, and P2TR outputs are unaffected. P2MR is opt-in ⁷.
• Transaction size and fee impact is analyzed in the BIP: P2MR script path spends are larger than P2TR key path spends but comparable to P2TR script path spends ⁷.

Community Sentiment: Bitcoin's community is characteristically cautious. The BIP-360 authors acknowledge that some "balk at the potential threat" given quantum computers' limited functionality to date, while others (including governments and corporations following CNSA 2.0 mandates) are actively concerned. The proposal frames P2MR as a "conservative first step" ⁷.

Testnet Activity: No public testnet implementation found as of May 2026. The BIP remains in Draft status.

Historical Context: Previous quantum-related Bitcoin proposals include discussions around P2QRH (Pay-to-Quantum-Resistant-Hash), which evolved into the P2MR approach. The Bitcoin community has historically been resistant to protocol changes without overwhelming necessity, making quantum resistance a contentious topic despite the technical merits.

7. Ethereum

Ethereum is the most proactive major chain addressing quantum threats, with dedicated organizational infrastructure:

Ethereum Foundation Post-Quantum Team: Formed in January 2026, dedicated team within the EF Protocol cluster. Public tracking site at pq.ethereum.org ⁵.

Four Vulnerable Areas Identified (Vitalik Buterin, February 2026):

1. Consensus BLS Signatures → leanXMSS + leanVM:

   • leanXMSS: Hash-based signature scheme replacing BLS for validator attestations ⁵.
   • leanVM: Minimal zkVM for SNARK-based aggregation, compressing PQ signature data by 250x to maintain efficiency ⁵.
   • Hash-based signatures are ~3,000 bytes vs. BLS's 96 bytes — the 250x compression is essential for viability ⁵.

2. Data Availability KZG → STARK/Lattice commitments:

   • KZG relies on elliptic curve pairings (quantum-vulnerable) ⁵.
   • Current mitigation: trusted setup provides partial protection ⁵.
   • Long-term: STARK-based commitments (hash-based, already quantum-resistant) or lattice-based commitments ⁵.

3. Account ECDSA → Account Abstraction (EIP-8141):

   • EIP-8141 enables native account abstraction, letting individual accounts choose post-quantum signature schemes ⁵.
   • Being considered for the Hegotá hard fork (second half 2026) ⁵.
   • No forced migration — users opt into PQ signatures voluntarily ⁵.

4. ZK-Proof Systems → STARKs:

   • SNARKs using elliptic curve pairings are vulnerable; STARKs (hash-based) are already quantum-resistant ⁵.
   • Natural ecosystem adoption of STARK-based rollups is already providing partial PQ security ⁵.

Roadmap Milestones (from pq.ethereum.org):

Fork	Milestone	Layer
I*	PQ key registry	Consensus
J*	PQ sig precompiles	Execution
L*	PQ attestations, real-time CL proofs, leanVM	Consensus + Data
M*	PQ sig aggregation, PQ blobs	Execution + Data
Longer term	Full PQ consensus, PQ transactions, PQ sampling	All

Core PQ infrastructure targeted for ~2029. Weekly interop testing with 10+ client teams ⁵.

Poseidon Prize: $1 million research prize for improvements to hash-based cryptographic primitives, directly supporting the PQ transition ⁵.

No Hard Fork for PQ-Only: Ethereum's approach distributes PQ upgrades across multiple forks rather than a single "quantum fork." The transition is gradual, opt-in where possible, and architecturally integrated ⁵.

8. Solana

As of May 2026, no formal Solana Improvement Proposal (SIP) for post-quantum cryptography has been found. Solana uses Ed25519 (Schnorr signatures on Curve25519) for transaction signing, which is equally vulnerable to Shor's algorithm as ECDSA ¹¹.

Assessment: Solana's high-throughput design (targeting ~65,000 TPS) makes the signature size explosion problem particularly acute. Switching from 64-byte Ed25519 signatures to 3,300+ byte ML-DSA-65 signatures would dramatically increase block sizes and network bandwidth requirements. No public statements from Solana Labs or the Solana Foundation on PQ roadmap were found.

This represents a significant gap compared to Ethereum's proactive approach. Solana's architecture (parallel execution, Gulf Stream mempool, Turbine block propagation) would all require re-engineering for larger signatures.

9. BNB Chain (BSC)

No public PQC roadmap, proposals, or statements from the BNB Chain team were found as of May 2026. BSC uses the same EVM stack as Ethereum (ECDSA for account signatures), meaning it faces identical quantum vulnerabilities ¹².

BNB Chain's blog and documentation do not reference post-quantum cryptography. Given BSC's EVM compatibility, it could theoretically adopt Ethereum's EIP-8141 account abstraction approach if that standard matures, but no independent PQC initiative was identified.

10. Other Major Chains

Cardano: Charles Hoskinson has publicly discussed quantum resistance as a long-term priority for Cardano. However, no concrete PQC upgrade proposal or timeline was found in Cardano's development reports or news as of May 2026. Cardano uses Ed25519 for its signature scheme (same vulnerability as Solana). The Mithril team (light client protocol) is working on SNARK circuit production readiness, which could intersect with PQ concerns, but no explicit PQ roadmap exists ¹³.

Algorand: Algorand's state proofs use Falcon signatures (a lattice-based scheme now being standardized as FN-DSA), making it one of the first major chains to incorporate PQC into its protocol. State proofs enable trustless cross-chain verification using post-quantum signatures. However, Algorand's standard transaction signing still uses VRF/Ed25519, which remains quantum-vulnerable ¹⁴.

Polkadot: No public PQC roadmap or proposals found. Polkadot uses Sr25519 (Schnorrkel) and Ed25519 for its signature schemes. As an ecosystem designed for parachain interoperability, the cross-chain implications of PQ migration are significant ¹⁵.

Cosmos: No Cosmos SDK-level PQC proposals found. Individual Cosmos chains would need to implement PQ signatures independently, as the SDK provides signature-agnostic infrastructure. No IBC (Inter-Blockchain Communication) protocol changes for PQ messaging were identified ¹⁶.

Avalanche: No public PQC roadmap or blog posts found. Avalanche uses secp256k1 and Ed25519 for its signature schemes across its subnet architecture ¹⁷.

Hedera: No dedicated PQC page found on Hedera's site. Hedera uses Ed25519 for network transaction signing and ECDSA for smart contract interactions. The Hashgraph consensus algorithm's security depends on digital signatures, making it equally vulnerable ¹⁸.

IOTA: IOTA has historically claimed quantum resistance due to its use of the Winternitz One-Time Signature (WOTS) scheme in early versions. However, IOTA's Chrysalis upgrade (2021) transitioned to Ed25519 for standard transactions. The IOTA 2.0 protocol does not appear to have reintroduced PQ signatures for standard transactions as of 2026 ¹⁹.

QRL (Quantum Resistant Ledger): The only purpose-built quantum-resistant blockchain with a live mainnet. Uses XMSS (eXtended Merkle Signature Scheme), a NIST-approved (SP 800-208) hash-based, forward-secure signature scheme. Features:

• Mainnet operational since 2018 ¹⁰.
• Hardware wallet integration (Ledger Nano X/S+) ¹⁰.
• Mobile wallets for Android/iOS ¹⁰.
• Ecosystem focus on post-quantum secure communications and digital asset custody ¹⁰.
• Key limitation: XMSS is stateful (finite signature count per key), requiring careful key management — not suitable for high-frequency transaction signing ¹⁰.

11. NIST Standards Impact

NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) on August 13, 2024 — the first completed PQC standards from an eight-year process evaluating 82 initial submissions from 25 countries ².

Chain Responses:

• Ethereum: Explicitly references NIST standards as the foundation for its PQ work. The EF team states "Ethereum's work builds on these foundations" ⁵. ML-DSA is the leading candidate for execution-layer PQ signatures; hash-based signatures (leanXMSS) were chosen for consensus due to their minimal security assumptions.
• Bitcoin (BIP-360): References CNSA 2.0 mandates (2030/2033 deadlines) and NIST IR 8547 (ECDSA disallowed by 2035) as motivation, but the BIP itself does not adopt NIST PQC algorithms — it removes key path exposure instead ⁷.
• Algorand: Adopted Falcon (now FN-DSA, pending NIST standardization) for state proofs before FIPS finalization — early mover ¹⁴.
• All other chains surveyed: No formal response to NIST standardization found as of May 2026.

Adoption Timeline: NIST IR 8547 provides a phased timeline: deprecate quantum-vulnerable algorithms by 2030, disallow by 2035 (with hybrid exceptions). This timeline applies to US federal systems but influences global adoption. For blockchains, the practical adoption timeline is likely 2027-2032 for early movers (Ethereum) and 2030+ for others ⁴⁶.

Ongoing Standardization: NIST continues evaluating additional algorithms: FN-DSA (Falcon) and HQC (code-based KEM) are being standardized. A separate call for additional digital signature schemes could yield backup or use-case-specific algorithms ⁴.

12. Quantum-Safe Bridges / Cross-Chain

No major cross-chain bridge protocol has publicly adopted post-quantum cryptography for messaging as of May 2026.

Algorand State Proofs represent the closest implementation: Falcon-based signatures enabling trustless verification across chains. This is a limited cross-chain use case (Algorand → other chains state verification) rather than a general-purpose PQ bridge ¹⁴.

Theoretical Approaches:

• PQ-secure light client bridges: Replace ECDSA/Ecdsa-based relay signatures with ML-DSA.
• Hash-based bridge commitments: Use STARK proofs for cross-chain state verification.
• PQ threshold signatures: Not yet standardized — lattice-based threshold schemes are research topics.

Gap Analysis: Cross-chain infrastructure is arguably the most vulnerable PQC attack surface because:

1. Bridge contracts hold massive TVL (billions of dollars across major bridges).
2. Relay/multisig signers typically use ECDSA or Ed25519.
3. A quantum attacker could forge relay signatures to drain bridge contracts.
4. Bridges require fast finality — they can't wait for "long exposure" protection alone.

This represents a significant unaddressed risk in the blockchain ecosystem.

---

Key Takeaways

1. The threat is real but not imminent. Current quantum hardware is years away from breaking ECC, but NIST/NSA/CNSA timelines (2030-2035 deprecation) make preparation urgent now.

2. Ethereum is far ahead. Dedicated PQ team, public roadmap (pq.ethereum.org), weekly interop testing, leanXMSS + leanVM development, and EIP-8141 for account-level signature agility. Target: core PQ infrastructure by ~2029.

3. Bitcoin is cautious but moving. BIP-360 (P2MR) addresses long-exposure attacks as a "conservative first step" but does not yet introduce PQ signatures. Community is divided on urgency.

4. Most chains are doing nothing publicly. Solana, BNB Chain, Cardano, Polkadot, Cosmos, Avalanche, Hedera, and IOTA have no public PQC roadmaps as of May 2026. This is a significant gap.

5. Signature size is the killer problem. 46x+ increase from ECDSA to ML-DSA breaks blockchain economics. Solutions require compression (leanVM's 250x SNARK aggregation) or new architectural patterns (account abstraction for opt-in migration).

6. Cross-chain bridges are the most exposed. Billions in TVL protected by quantum-vulnerable signatures with no public PQ migration plans.

7. QRL is the only purpose-built quantum-resistant chain but has limited ecosystem adoption compared to major chains.

8. Hybrid approaches are the near-term answer. Running classical + PQC algorithms simultaneously provides transitional security while standards and implementations mature.

---

References