Lessons from Solana’s Post-Quantum Migration

Key Takeaways:

RSA-896, a 270-digit number, was factored on September 19, 2026 by Anthropic’s Stephen Weis, who used Claude to port CADO-NFS to GPUs and coordinated up to 2,048 of them for roughly 10 days and about 30 GPU-years. It was the second AI-assisted factoring record in sixteen days, after RSA-260 fell on September 3.

Neither record weakens Solana. The network signs with Ed25519, a different mathematical problem. The relevance is schedule compression, not a new break.

Anza and Firedancer independently selected Falcon-512 and shipped test builds in April 2026. Anza also prototyped a wallet migration proof that runs in about 55 milliseconds.

Ed25519 keys derive from a 32-byte seed through SHA-512, so existing wallets can prove seed possession instead of being abandoned.

No protocol activation date exists. The Falcon work is a syscall proposal, not a mainnet signature swap, and Falcon’s own NIST standard (FIPS 206) is still in draft.

The 2026 Threat Landscape After RSA-896

On September 19, 2026, Stephen Weis, a member of technical staff on Anthropic’s Secure Frameworks team, published the two prime factors of RSA-896, a 270-digit number that had resisted public attack since the RSA Factoring Challenge. He used Claude to adapt CADO-NFS, the open-source number field sieve implementation, for graphics processors and coordinate the run across up to 2,048 GPUs, per Quantum Zeitgeist’s account. The job spanned roughly 10 days and about 30 GPU-years. Sixteen days earlier, Eric Lu of Cognition reported factoring RSA-260 with the company’s Devin agent, covered by Scientific American.

Weis was explicit about the boundaries. The factoring of RSA-896 does not improve the general number field sieve in a meaningful way, and it does not put deployed RSA-2048 keys at risk. His narrower assessment is that RSA-1024 keys now sit within reach of organizations with data-center-scale GPU fleets. The public record advanced from 862 bits to 896 bits in sixteen days, and the part that matters to blockchain teams is that AI tools eliminated the engineering bottleneck that previously kept these records confined to specialized research groups.

A post about Solana opens with an RSA factoring record because both events concern timing, not mathematics. No Solana key is weaker because RSA-896 was factored. The record shortens the migration window that blockchain teams expected. We covered the earlier RSA-260 record and the two-track threat model in Part 1 on SSH keys.

Falcon in Anza and Firedancer

The Four Places Solana Uses Elliptic Curves

Migration planning starts by identifying the surfaces, and the Anza team’s quantum adversary analysis identifies four. The account model is the obvious one: an adversary who breaks Ed25519 can forge transaction signatures and drain accounts. Block propagation is the second, since Turbine and rotor sign shreds, and forged validator signatures would let an attacker flood the network with invalid data and degrade availability.

Consensus is the third and hardest. Alpenglow votes are BLS signatures over pairing-friendly curves, and forging them would enable double-spends by fabricating confirmations on conflicting forks. The fourth is user programs, since any on-chain program that verifies signatures through a syscall for multisignature or custom authorization logic inherits the same exposure. That fourth surface is why an on-chain verification path matters: it lets application developers harden their own contracts ahead of a protocol-wide change.

Google Quantum AI’s 2026 circuits contribute to much of the urgency, and Anza cites them directly. One circuit fits within fewer than 1,200 logical qubits and 90 million Toffoli gates for the 256-bit elliptic curve discrete logarithm problem. Anza’s updated estimate assigns a 3 to 5 percent chance of a quantum computer capable of breaking that problem within five years, up from a probability the team previously treated as negligible over the same horizon.

Hardware and Performance Trade-offs

Every post-quantum signature scheme is larger than the Ed25519 signatures Solana uses today, and for a chain targeting sub-second slots that size difference drives the choice. Falcon-512 signatures run 666 bytes against 2,420 bytes for ML-DSA-44, about 3.6 times smaller. At a few thousand transactions per second that gap multiplies across block payloads, archive storage, and fee markets, which is why the larger standard was set aside for the transaction layer despite its cleaner implementation profile.

Verification cost is the other half of the trade-off. Jump Crypto’s comparison puts Falcon-512 verification at 0.25 times the cost of Ed25519, meaning it is cheaper to check than the current scheme, while ML-DSA-44 sits at 0.80 times. That is favorable for a network where validators verify far more signatures than they produce. The catch is signing-side complexity, which Falcon pushes off-chain precisely so that validators and wallets can each run audited, constant-time implementations rather than sharing one general-purpose library.

The performance claim that matters most is the Foundation’s own: it states that network performance is not expected to see a meaningful impact if and when migration activates. That is the Foundation assessing its own roadmap, and no independent mainnet-scale benchmark has confirmed that a post-quantum signature swap leaves throughput untouched. Treat it as a design target, not a measured result.

Hybrid Cryptography: Ed25519 plus Falcon

Hybrid cryptography in a blockchain client means running a classical scheme and a post-quantum scheme side by side so that a break in either one does not immediately compromise the system. Solana’s Ed25519 keys derive their private key from a 32-byte seed by hashing that seed with SHA-512 during signing, and the derived value produces both the public key and signatures. A quantum attacker running Shor’s algorithm can recover that derived secret value, but not the original seed, because SHA-512 remains a quantum-resistant one-way function.

Anza worked through the consequence, drawing on research from Mysten Labs. Because only the derived value falls, the legitimate owner retains something no attacker holds. That supports a migration where the wallet owner proves knowledge of the underlying seed with a post-quantum zero-knowledge proof, then binds the existing account to a new post-quantum public key. The address does not change, and the migration stays secure even after quantum computers can break legacy Ed25519 signing, provided old-style signing has been disabled.

Bitcoin and Ethereum lack that property. Their account keys authorize spends directly, so once the public key is on-chain and the curve falls, an attacker can forge. That is the exposure surface we described in Part 2 on Bitcoin’s public key exposure, where address reuse is what puts keys in the open. Anza noted the same migration trick does not work for Bitcoin because some early coins sit in accounts created before the BIP32 and BIP39 upgrade path existed.

Migration Pathways from Ed25519

The Foundation’s three-step plan is research, then adoption by new wallets if quantum computing becomes a credible threat, then migration of existing wallets. There is no fixed activation date. The immediate engineering step is a syscall rather than a protocol switch: SIMD-0461, proposed as SIMD-0416, adds a precompile for Falcon-512 signature verification. The scope is deliberately narrow, covering verification only with key generation and signing off-chain, and the proposal explicitly does not replace Ed25519. Adding an on-chain verification path lets developers build post-quantum vaults, multisignature wallets, and custody primitives without waiting for a network-wide upgrade.

Anza has already built a prototype of the hardest step. The migration proof generates roughly 400 kilobytes in about 55 milliseconds, letting a user prove knowledge of their Ed25519 seed and bind the account to a new post-quantum public key without changing the address. Anza notes this is the closest thing to a solved problem, because the difficulty in any post-quantum transition is getting holders to move before a quantum computer arrives rather than the cryptography itself.

Consensus needs separate treatment. BLS signatures aggregate efficiently and Falcon does not aggregate the same way, so replacing consensus votes is a distinct research problem involving lattice-based multisignature protocols. Solana already has an opt-in quantum-resistant primitive in production: Blueshift’s Winternitz Vault, live since January 2025 and cited by Google Quantum AI as a leading example of the work, though it is an application-layer add-on rather than a base-layer guarantee.

Signature Sizes and Standards Maturity

The table below compares the candidates Solana evaluated, using the byte sizes published in NIST’s finalized standards and Jump Crypto’s relative verification costs.

Scheme	Public key	Signature	Verify cost vs Ed25519	Standards status
Ed25519 (in use)	32 bytes	64 bytes	1.00x	Not quantum safe; long deployed
Falcon-512 (FN-DSA)	897 bytes	666 bytes	0.25x	Draft as FIPS 206
ML-DSA-44 (Dilithium2)	1,312 bytes	2,420 bytes	0.80x	Final as FIPS 204 since August 2024
SQIsign	65 bytes	148 bytes	about 100x	Unstandardized; active research

The standards gap is a practical constraint alongside the byte counts. ML-DSA became final as FIPS 204 in August 2024, while FN-DSA is still in draft as FIPS 206, a lag of more than two years per a 2026 comparison. Falcon’s compactness depends on a Gaussian sampler using floating-point arithmetic, and Cloudflare’s assessment of post-quantum signatures argues ML-DSA is the better general default because integer-only arithmetic is easier to implement without side-channel leaks. For a chain where bandwidth dominates, the byte savings outweigh that risk, which is the trade Solana made.

Limitations and Open Questions

Solana’s work is further along than most chains, and the gaps are worth naming. No protocol activation date exists, and the Foundation has been explicit that it is watching and researching rather than changing anything the network does not yet need. The Falcon implementations are test builds, not production code running under adversarial load. The Foundation’s performance claim remains its own.

Implementation risk is the sharpest edge. Falcon’s standardization was delayed over concerns about implementation complexity and side-channel attacks. Verification can be made constant-time, but signing-side floating-point behavior remains a documented research concern. A chain adopting Falcon must enforce audited, constant-time code across many wallet and validator repositories, which is a supply-chain problem more than a cryptography one.

Alternatives are not closed off. SQIsign offers 148-byte signatures and 65-byte public keys, closer to elliptic-curve sizes, but verification is roughly 100 times more expensive than Ed25519 today. The coordination problem also persists regardless of algorithm: a chain can have a sound post-quantum signature scheme and still fail to migrate if holders never move their funds. Anza’s own framing is that this is the binding constraint, and Solana answered it with a migration proof rather than a deadline.

Audit Checklist for Blockchain Teams

Count the elliptic-curve surfaces in your protocol before choosing an algorithm. Solana has four: account signatures, block propagation, consensus votes, and user-program verification.
Check whether your key derivation is reversible. Ed25519’s SHA-512 seed derivation enables a proof-of-possession migration path; secp256k1 accounts do not have that option.
Measure signature overhead against your throughput target. A move from 64-byte to 666-byte signatures changes block and fee economics, so model it against current payload and archive costs.
Separate consensus from execution in the migration plan. Aggregated consensus signatures have different constraints than per-transaction signatures, and Falcon lacks native aggregation.
Enforce constant-time signing where side channels are reachable. Falcon’s floating-point sampling is the known weak point, so audit every wallet and validator implementation rather than trusting a library name.
Track the runtime proposals on your chain, not just the standard. For Solana, that means SIMD-0461 and on-chain Falcon verification; for Ethereum, the account abstraction work.
Confirm your chosen scheme’s standards status. ML-DSA is final under FIPS 204; FN-DSA is still a draft under FIPS 206, which affects what an audit or procurement team can check.
Treat opt-in vaults as a stopgap. Blueshift’s Winternitz Vault provides real post-quantum custody on Solana today, but application-layer options do not change base-layer guarantees.
Handle RSA-1024 exposure separately from quantum risk. Weis’s assessment puts 1024-bit RSA within reach of data-center GPU fleets, so legacy keys at that size need their own schedule.

Solana’s edge is that Ed25519’s seed-derived design turned an intractable problem into a proof-of-possession exercise, that two independent client teams converged on the same compact signature scheme, and that the first protocol step was a verification syscall rather than a flag day. Chains built on secp256k1 should read the record as a warning about migration design, since the cryptography is the tractable part and the movement of existing funds is not.

Part 5 turns to the end of the exposure surface where the secrets sit still: banking and data at rest, where RSA in TLS, PKI, and hardware security modules must survive a harvest-now, decrypt-later attacker.

More in-depth coverage from this blog on closely related topics:

Sources and References

Sources cited while researching and writing this article: