Securing Solana Against a Powerful Quantum Adversary

Cryptographically relevant quantum computers are likely still several years away, but Solana should not wait for Q-day to begin preparing. The Anza team and members of the Solana community have already started laying the groundwork for a post-quantum transition: identifying the parts of the protocol that depend on elliptic curve cryptography, evaluating post-quantum signature schemes, increasing transaction sizes to accommodate larger post-quantum signatures, and preparing migration paths so that we are prepared to protect users and applications well before the need arises.

How far away is Q-day?

Last week, Google Quantum released a whitepaper detailing new quantum circuits for Shor's algorithm that dramatically reduce the resources needed to solve the 256-bit elliptic curve discrete logarithm problem (ECDLP-256), the mathematical foundation of the signature schemes used across most blockchains, including Solana. The team compiled two circuits: one using fewer than 1,200 logical qubits and 90 million Toffoli gates, and another using fewer than 1,450 logical qubits and 70 million Toffoli gates (Babbush et al. 2026). On a superconducting architecture with standard hardware assumptions, these circuits could execute in minutes using fewer than 500,000 physical qubits, roughly a 20-fold reduction over previous estimates (Babbush et al. 2026).

On the same day, Oratomic published a complementary result showing that ultra-efficient quantum error correction on neutral-atom architectures could push the number of physical qubits required even lower. At 26,000 physical qubits, the runtime for discrete logarithms on the P-256 elliptic curve could be as short as a few days. In the most aggressive configuration, a fully fault-tolerant quantum computer could be built with as few as 10,000 to 20,000 qubits (Cain et al. 2026).

With these developments in mind, we want to present a path to securing Solana against a powerful quantum adversary. We don't think cryptographically relevant quantum computers are imminent. The largest number factored by Shor's algorithm on actual quantum hardware is just 21 (Martín-López et al. 2012), and the gap between that and breaking a 256-bit elliptic curve remains enormous. But these papers have shifted some of the probability mass in our quantum forecast to the left. Within two to three years, we still consider the risk almost negligible; however, if everything continues to progress on trend with neutral-atoms architecture, it is possible, if not probable, that a powerful quantum computer could come online within five years. Our updated estimate now assigns a 3–5% chance of a quantum computer capable of breaking ECDLP-256 within five years, up from a probability we previously considered negligible over that horizon.

This post is intended to highlight the ongoing work on quantum resistance at Anza and invitation to begin the broader discussion about securing the protocol against a quantum adversary.

What do we need to secure?

The Solana protocol uses elliptic curve cryptography in four places today: 

1. The account model: A quantum adversary capable of breaking Ed25519 could steal user funds by forging transaction signatures and stealing funds from their accounts.

2. Block propagation: Turbine and rotor rely on signatures for shred authentication. An attacker who can forge validator signatures could flood the network with invalid shreds during block propagation, causing loss of availability.

3. Consensus: Alpenglow uses BLS signatures over pairing-friendly elliptic curves. Forging consensus votes could enable double-spend attacks by fabricating confirmations on conflicting forks.

4. User-defined programs: Programs on Solana can invoke signature verification and other cryptographic primitives through syscalls. Any program that relies on elliptic curve operations for authorization logic, on-chain multisigs, custodial schemes, or custom authentication, inherits the same quantum vulnerability as the base protocol.

The Post-Quantum Toolbox: Post-Quantum Signatures

We have a number of tools at our disposal to harden the protocol against a quantum adversary.

The first and most important is post-quantum signature schemes. These serve the same purpose as Ed25519 and BLS-12-381 today, but they do not rely on the discrete logarithm assumption that Shor's algorithm breaks. In 2016, NIST announced a standardization process for post-quantum cryptographic algorithms, soliciting proposals from cryptographers worldwide. Of the 82 candidate algorithms submitted in the first round (NIST 2017), three digital signature schemes have now been finalized as federal standards: ML-DSA (CRYSTALS-Dilithium), a lattice-based scheme suitable for general-purpose signing; SLH-DSA (SPHINCS+), a hash-based scheme intended as a conservative backup; and FN-DSA (FALCON), a lattice-based scheme with compact signatures that is still in draft (NIST 2024).

The main downside of post-quantum signatures is size. FALCON signatures, the smallest of the three NIST schemes, are roughly 10 times larger than Ed25519 signatures.

A secondary challenge is that these schemes generally lack the native aggregatability and thresholdizability properties that specific elliptic curve constructions possess. BLS signatures, for instance, can be trivially aggregated, a property that is used in Simplex-style consensus protocols including Alpenglow. Replicating this functionality with post-quantum primitives remains an active area of research, but there are promising directions. Ethereum's post-quantum team has developed a scheme that uses hash-based signatures (leanXMSS) for individual validator signing, then aggregates them using a post-quantum SNARK (Drake et al. 2025). The key insight is that even though hash-based signatures have no native algebraic structure that permits aggregation, you can achieve the same effect by proving succinctly that all individual signatures are valid. If the proof system itself relies only on hash functions, the entire construction is plausibly post-quantum secure.

A separate line of work has explored aggregating FALCON signatures directly using LaBRADOR, a lattice-based SNARK (Aardal et al. 2024). Because FALCON and LaBRADOR share lattice-based algebraic structure, this could yield more compact aggregates, but the security analysis relies on rewinding techniques whose post-quantum implications are not fully resolved.

Both approaches could in principle be adapted for Solana, though the engineering constraints differ. Ethereum needs to aggregate signatures from hundreds of thousands of validators once per epoch, making it primarily a bandwidth problem. Solana has fewer validators but requires signatures at much higher frequency, meaning verification latency and proof production latency are more important.

The Post-Quantum Toolbox: Migration

Anza engineers have already completed an initial implementation of a post-quantum migration strategy. The prototype, available at anza-xyz/cryptography/pull/10, generates a post-quantum-secure migration proof of roughly 400 kB in about 55ms. The basic idea is to let a user prove knowledge of the seed material underlying an existing Ed25519 account, then bind that account to a new post-quantum public key without changing the user’s address.

This is critical since even once post-quantum signature schemes are available, the hardest part of the transition may be getting users to migrate. Any account that has not rotated to a post-quantum key before a cryptographically relevant quantum computer arrives remains vulnerable. Without a secure migration path, key stakeholders may eventually face an ugly choice: deprecate accounts that have not migrated, or leave open a surface area that a quantum adversary could exploit. Indeed, Bitcoin Core developers are currently debating this exact tradeoff: https://www.bip361.org/.

Our implementation is based on recent work from Mysten Labs which offers a way to sidestep this tradeoff. Baldimtsi, Chalkias, and Roy (2025) observe that because Ed25519 derives private keys deterministically from a seed via SHA-512, a user can prove knowledge of the underlying seed using a post-quantum zero-knowledge proof. That proof can then authorize the binding of a new post-quantum public key to the existing account, preserving the original address. Crucially, this migration path can remain secure even after Q-day. A user who still possesses their seed phrase could generate the proof and migrate to a post-quantum key even after quantum computers are capable of breaking Ed25519, provided legacy Ed25519 signing has been disabled.

Unfortunately the same trick doesn’t work for bitcoin since some of the “satoshi coins” are held in accounts created before BIP32/39 upgrades.

There is also a more limited application-level approach to migration: quantum vaults. A vault program could require post-quantum signatures before allowing funds to move, giving users a way to opt into stronger protection without waiting for a full protocol migration. This is useful as an early hardening mechanism, especially for high-value accounts, but it is not a substitute for changing the protocol. Vaults can protect assets that have already been moved into them; they cannot protect the broader account model, validator identities, consensus votes, stake-weighted networking, or arbitrary programs that continue to rely on elliptic curve signatures. Most critically, vaults alone are not sufficient because the account model is used to pay fees directly. Vaults are user defined programs and therefore cannot pay fees in the Solana protocol as it exists today. Any fee payer account will be drainable if no action is taken to harden the account model and a powerful quantum computer comes online. 

The post-quantum Solana Checklist

Accounts DB

Accounts are currently indexed by a Ed25519 public key and the private key associated with that public key can be used to authorize transactions. A powerful quantum adversary would be able to recover the Ed25519 private key by solving the discrete log so we need to migrate to a post-quantum signature scheme like FALCON. To do that we need to introduce address versioning. FALCON public keys are significantly larger than Ed25519 keys so we should index these new post-quantum accounts by public key hash rather than public key. One proposal is to hash these to the off curve portion of address space to keep the address space domain the same.

Transactions

SIMD-0296 and SIMD-0385 propose increasing the Solana transaction size to 4096 bytes. We also need to adjust our signature verification pipeline in the TPU to accommodate the new FALCON signatures.

SVM

SIMD-0461 proposes a precompile for FALCON signature verification, which would give programs the ability to verify post-quantum signatures on-chain without prohibitive compute costs.

Networking

XDP increases throughput to offset the throughput lost from post-quantum shreds. Shreds include signatures to prevent DoS vectors but post-quantum signatures are larger so ideally shreds could be sent over a networking protocol that allows for larger units of data to mitigate the bandwidth cost.

Stake-weighted QoS relies on Ed25519 signatures to prove stake ownership. This needs to be moved over to a post-quantum signature scheme.

Consensus

Stake and vote accounts are special accounts that contain consensus relevant identity information. These need to be migrated to post-quantum secure accounts and vote messages need to replace BLS signatures with a post-quantum secure alternative such as FALCON. The protocol currently calls for BLS signature aggregation to produce consensus certificates but the raw votes can be contained in the block if needed, serving the same purpose as certificates do in the current protocol.

Disclaimer

None of this constitutes a commitment to a specific post-quantum signature scheme. The post-quantum cryptography landscape is still evolving rapidly: isogeny-based schemes such as SQIsign already offer much smaller signatures than FALCON, but remain less mature and come with significant performance tradeoffs.