Post-Quantum Security for Blockchain Systems

Key Takeaways:

• RSA-896, a 270-digit challenge number, was factored on September 19, 2026 using Claude AI and up to 2,048 GPUs, about 16 days after RSA-260 fell. Both used classical algorithms, not quantum hardware.
• RSA-2048 is not at risk from classical factoring. The researcher behind the RSA-896 result assessed that RSA-1024 keys are now vulnerable to organizations with data-center GPU fleets.
• Blockchains publish public keys on-chain, so elliptic-curve signatures in Bitcoin, Ethereum, and Solana face a different exposure profile than enterprise data at rest.
• Production migration has started: NEAR activated ML-DSA signing on mainnet in July 2026, Algorand ships Falcon verification as a native opcode, and Solana has Falcon-512 in its validator clients.
• Signature size drives algorithm choice. Falcon-512 signatures are 666 bytes against 2,420 bytes for ML-DSA-44, a 3.6x difference that decides block and fee economics.
• Crypto-agility is the durable objective. Only about 7 percent of enterprises have deployed quantum-safe protections across most of their infrastructure.

Two Cryptanalytic Tracks, One Exposure Surface

Public-key cryptography has an expiration date nobody can read. That uncertainty is the whole problem. Every SSH session, every TLS handshake, every Bitcoin transaction, and every bank vault of encrypted records depends on mathematical problems that were assumed hard for so long that the industry stopped checking.

Two things changed in 2026. On September 3, an engineer at Cognition published a prime factor of RSA-260, an 862-bit number that had resisted attack since the RSA Factoring Challenge. Sixteen days later, on September 19, Anthropic researcher Stephen Weis published two prime factors of RSA-896, a 270-digit number, per his announcement of the factorization. Both records used a classical algorithm running on GPUs, orchestrated by AI agents.

That is the classical track. The quantum track is separate, slower-moving, and ultimately more destructive: a fault-tolerant quantum computer running Shor’s algorithm would not grind through the number field sieve at all. Resource estimates for that machine keep falling, and in March 2026 Google Quantum AI researchers published work suggesting that breaking 256-bit elliptic curve cryptography, the type Ethereum uses, could require roughly 1,200 logical qubits, as summarized on Ethereum’s post-quantum roadmap page.

This article is the entry point to a six-part series on how public-key cryptography breaks and what developers and security engineers can do about it. It gives you the shape of the whole problem and a starting checklist. The depth lives in the parts.

The Classical Track: Two RSA Records in Sixteen Days

The September records deserve careful reading, because coverage has inflated them in both directions. The number field sieve is the same algorithm the RSA-250 team used in February 2020 to factor an 829-bit number at a cost of about 2,700 core-years, as reported in the 2020 paper. What changed is the hardware and the orchestration layer, not the math.

Weis reported that Claude ported CADO-NFS, the open-source factoring software, to run on GPUs and coordinated a computation across up to 2,048 GPUs drawn from idle capacity. The job took about 10 days and roughly 30 GPU-years. He stated plainly that he had not meaningfully improved the running time of the general number field sieve. The analysis of the RSA-896 result shows the scaling is unremarkable: 896 bits sits 34 bits above RSA-260, and standard scaling predicts about 2.6 times more work, which matches 30 GPU-years against Lu’s 13.5.

The crucial number is the gap to RSA-2048. The analysis estimates RSA-2048 needs roughly 35 billion times the work of RSA-896 under the same heuristic, which at Weis’s efficiency comes to about a trillion GPU-years and, at $3.50 per GPU-hour, a bill near $32 quadrillion. No GPU fleet closes that gap, and RSA-2048 is not falling to classical attack.

Where classical factoring does matter is squarely in the middle: RSA-1024. Weis’s own assessment was that deployed RSA-2048 keys are unaffected but that RSA-1024 keys are vulnerable to many organizations with data-center GPU fleets. Eric Lu estimated a hyperscaler could factor RSA-1024 for about $30 million. That is the classical track’s real punchline, and it lands hardest on aging infrastructure still holding 1024-bit keys.

The tracks also interact. Anthropic announced in July 2026 that an AI model found a vulnerability in HAWK, a lattice-based signature scheme under consideration for standardization, and the HAWK team withdrew it the following day. NIST notes this does not affect the finalized ML-KEM and ML-DSA standards, which rest on different mathematical foundations.

Existing Vulnerabilities in Bitcoin and Ethereum

Public blockchains concentrate the risk because they publish the public keys attackers need. On most systems, a public key sits behind a certificate or handshake and can be retired. On a blockchain, a public key that has authorized a transaction stays visible on the ledger permanently.

Bitcoin uses ECDSA over the secp256k1 curve. The exposure depends on address hygiene: an address that has only received coins shows only a hash of the public key, while any address that has spent exposes the full key on-chain. The 2026 report from the Joint Committee of the European Supervisory Authorities, which includes the EBA, ESMA, and EIOPA, flagged this as a systemic risk in its Autumn 2026 update, as covered by Blockonomi. Coinbase’s Independent Advisory Board estimated that roughly 7 million BTC could eventually face quantum-related risk, with around 5 million BTC linked to address reuse.

Ethereum’s exposure is broader than account keys. Its roadmap identifies four vulnerable areas: consensus-layer BLS signatures, KZG polynomial commitments used for data availability, ECDSA account signatures on secp256k1, and zero-knowledge proof systems. The Ethereum Foundation maintains a dedicated post-quantum research team, funded research, and a published migration roadmap under the “Lean Ethereum” program, which targets 2029 for full post-quantum protection. Account abstraction (EIP-8141, under consideration for Hegotá in the second half of 2026) is positioned as the vehicle for signature agility, letting individual accounts adopt post-quantum signatures ahead of the protocol.

Solana is furthest along in client-level testing. Anza and Firedancer, two of its most-used validator clients, implemented a test version of the Falcon-512 post-quantum signature scheme in April 2026. Jump Crypto, the team behind Firedancer, said Falcon-512 generates the smallest signature among NIST’s selected post-quantum signature standards, which matters for preserving Solana’s throughput. The Solana Foundation stated that “the migration work is manageable, transition can happen quickly when time is right, and network performance is not expected to see meaningful impact.” That is a foundation’s own assessment of its own roadmap, and independent validation at production scale does not exist yet.

The Rise of Post-Quantum Standards

NIST finalized its first three post-quantum cryptography standards on August 13, 2024, giving the industry a concrete set of tools to begin replacing quantum-vulnerable schemes. The three are ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a hash-based backup signature scheme. The NIST post-quantum cryptography project page states that these standards were developed through an eight-year effort and are ready to be implemented now.

The standards are moving into validated products. FortifyIQ announced in September 2026 that its post-quantum signature verification library completed NIST’s Cryptographic Algorithm Validation Program, confirming alignment with FIPS 204 for post-quantum digital signatures, as reported by AnySilicon. CAVP validation matters because it gives procurement teams a checkable artifact rather than a vendor claim.

The standards have not been static. NIST selected HQC as a fifth algorithm in March 2025 to serve as a backup for general encryption. In May 2026, nine candidates advanced to a third round of the additional digital signature process. That process also produced a cautionary result: the HAWK scheme was withdrawn after Anthropic’s AI-assisted analysis found a vulnerability. NIST’s position is that this finding does not affect the finalized standards, since ML-KEM and ML-DSA rely on different mathematical foundations. The lesson for adopters is that algorithm diversity is a feature, not redundancy to trim.

Choosing an Algorithm: ML-KEM, ML-DSA, and Falcon

Signature size is the constraint that decides blockchain migration economics. Every extra byte per transaction multiplies across block payloads, archive storage, and fee markets.

The figures above come from the Hacken comparison of Falcon in Web3, which also reports that on ARMv8-A hardware Falcon verification runs three to four times faster than ML-DSA at the same security level. Falcon-512 signatures are 3.6 times smaller than ML-DSA-44. For a high-throughput chain, that difference decides whether post-quantum migration is feasible without renegotiating block-size limits.

The counterweight is implementation risk. Cloudflare’s assessment of post-quantum signatures argues that ML-DSA is the right default today despite being larger on the wire, because its clean integer arithmetic is easier to implement without side-channel leaks. Falcon is the better fit where bandwidth dominates and the team can enforce constant-time floating-point. A 2024 paper by Gajland, Janneck, and Kiltz, A Closer Look at Falcon, identified that standard Falcon parameters do not satisfy all conditions of the classical trapdoor-signature security proof, and proposed Falcon+ to address the gap. For key establishment rather than signatures, ML-KEM (FIPS 203) is the standard choice and underpins the hybrid handshakes in OpenSSH and modern TLS.

Deployments Already in Production

Several blockchains have moved past white papers, and their choices are the most useful evidence available for anyone planning a migration.

NEAR Protocol activated quantum-safe account signing on its 2.13 mainnet upgrade in July 2026, using the NIST-approved FIPS-204 (ML-DSA) scheme. NEAR describes this as the first instance of a major public blockchain deploying a NIST-standardized post-quantum signature in live production, per its launch announcement. Note the scope: this is account signing, not a full protocol-wide replacement of every signature in the system.

Algorand went a different route. Its September 2024 v4.3.0 consensus upgrade added falcon_verify as a native Algorand Virtual Machine opcode, meaning on-chain signature verification rather than a proof wrapper or precompile proposal. The Hacken analysis notes this gives Falcon a real production deployment to benchmark against. The trade-off is that Falcon’s compactness rests on a Gaussian sampler that uses floating-point arithmetic, which researchers have shown is exposed to single-trace power analysis on Falcon-512. Constant-time floating-point is required on hardware where power or electromagnetic side channels are reachable.

Bitcoin’s path is the slowest and the most consequential. BIP-360, published in February 2026 and merged into Bitcoin’s BIP repository, proposes Pay-to-Merkle-Root (P2MR), a new output type that removes the key path entirely so no public key appears on-chain at creation time. A BTQ Technologies testnet implementation included five ML-DSA signature opcodes and reportedly attracted over 50 miners. The roadmap analysis is candid about what P2MR does not fix: migrating from a legacy address still exposes the classical public key in the mempool, creating an on-spend race window that private mempools or commit-reveal schemes would need to close.

Migration Strategies for Blockchain Networks

Ethereum’s phased approach is the clearest template. The Ethereum Foundation runs a dedicated post-quantum research team, funds external research, and operates weekly development networks against a published roadmap. The roadmap treats quantum computing as a first-class design constraint rather than a future contingency, which is why the four vulnerable areas (consensus BLS signatures, KZG commitments, ECDSA account signatures, and zero-knowledge proofs) each have a named solution path.

The consensus layer illustrates the trade-offs. Ethereum plans to replace BLS signatures with leanXMSS, a hash-based scheme considered quantum-safe because it relies only on hash function security. The problem is size: hash-based signatures run roughly 3,000 bytes against 96 bytes for BLS, which would produce far more data per slot. The leanVM zero-knowledge virtual machine is designed as an aggregation engine to compress that data, preserving the efficiency benefit of combining many signatures into one. This is the pattern other chains should study: the post-quantum replacement is not a drop-in swap, and the surrounding machinery has to be rebuilt alongside it.

Account abstraction serves a different purpose. Rather than a single protocol-wide migration, EIP-8141 would give users signature agility so individual accounts can switch to a post-quantum scheme without waiting for the entire protocol to change. Users and wallets that want protection early can adopt it voluntarily. For chains without Ethereum’s development capacity, the practical sequencing is to inventory cryptographic dependencies, prioritize long-lived value, and design for algorithm replacement rather than a one-time swap.

Regulatory and International Signals

Regulators have started treating preparation as an immediate security issue rather than a distant technology problem. The Joint Committee of the European Supervisory Authorities, which includes the EBA, ESMA, and EIOPA, warned in its Autumn 2026 risk update that advanced quantum systems could weaken the cryptography protecting transactions, communications, databases, and distributed ledgers, and that financial institutions may face security risks before quantum computing reaches mass adoption.

The EU’s coordinated post-quantum roadmap, adopted in June 2025, calls for every member state to begin migration by the end of 2026, with high-risk systems and critical infrastructure complete no later than 2030, according to the European Commission’s post-quantum policy page. NIST anticipates deprecating ECDSA by 2030 and disallowing it by 2035. Google has set a 2029 internal deadline for migrating its own systems.

For blockchain networks, migration is harder than for conventional infrastructure because signature upgrades may require protocol changes, ecosystem coordination, and users moving assets from vulnerable addresses. That coordination problem, not the cryptography, is the binding constraint. A chain can have a technically sound post-quantum signature scheme and still fail to migrate if holders never move their coins.

Immediate Audit Checklist

You can start moving before the later parts publish. These steps apply regardless of which part of the problem you own.

• Inventory every RSA key at 1024 bits or below and treat them as urgent. The classical factoring records put RSA-1024 within reach of organizations with data-center GPU fleets, per Weis’s assessment.
• Check your OpenSSH version and confirm post-quantum key exchange is active. OpenSSH 10.0 and later default to mlkem768x25519-sha256; 10.1 warns when a session falls back.
• Separate signature risk from key-exchange risk. OpenSSH’s own guidance notes there is no store-now-decrypt-later exposure for signatures, so the urgency on key exchange is higher than on signature retirement.
• Classify data by confidentiality lifetime. Anything that must stay secret past 2035 is already exposed if it travels under RSA or elliptic-curve protection.
• Audit long-lived secrets and stale credentials. The Cloud Security Alliance reports that roughly 64 percent of secrets confirmed valid in 2022 remained valid in January 2026.
• Measure signature overhead before picking an algorithm. A migration from 64-byte Ed25519 signatures to 666-byte Falcon-512 or 2,420-byte ML-DSA-44 changes block and fee economics, so model it first.
• Avoid address reuse on any blockchain holdings you control, since reuse is what exposes public keys on-chain and drives the roughly 5 million BTC figure from Coinbase’s advisory board estimate.
• Track NIST’s finalized standards and the NCCoE migration guidance rather than waiting for a final deadline.

No system is broken today in a way that lets an attacker steal your funds this afternoon. That is exactly the window in which migration is cheap. The parts that follow show you where to start, and the audit checklists will tell you where you stand.

Sources and References

Sources cited while researching and writing this article:

• announcement of the factorization
• Post-quantum cryptography on Ethereum | ethereum.org
• 2020 paper
• RSA-896 Factored With Claude, 16 Days After RSA-260
• announced in July 2026
• EU Regulators Warn Quantum Threat Could Hit Blockchain Before Mass Adoption
• Post-quantum cryptography – NIST
• FortifyIQ Announces CAVP Validated ML DSA Post Quantum Digital Signature Verification Library
• Falcon (FN-DSA): The Post-Quantum Signature Algorithm for Web3
• Why we cannot wait for better post-quantum signature algorithms
• A Closer Look at Falcon
• NEAR Protocol Brings Quantum-Safe Signing to Mainnet
• Fixing Bitcoin: The Post-Quantum Migration Technical Roadmap
• European Commission’s post-quantum policy page

Series outline