What Would Solana Need to Change to Become Quantum Ready?

Many thanks to Kobi, Lostin, Quentin, Ichigo, Aseneca, and Dean for reviewing earlier versions of this work.

In recent months, various alarmist claims have circulated suggesting that we have only a few years to migrate to post-quantum cryptography, and that Solana would be among the first victims of such a scenario. Regardless of the perceived urgency or whether one accepts such claims, it is helpful to map out what the protocol would need to change if, under today’s conditions, Solana were to transition to post-quantum cryptography.

Brief Introduction to Quantum Computing

Quantum computing is a computational paradigm that departs from the classical model built on binary logic. Instead of processing information strictly as zeros and ones, quantum computers operate on qubits, physical systems that follow the rules of quantum mechanics. A qubit can occupy multiple states simultaneously (a property known as superposition), allowing quantum processors to explore many possible solutions in parallel.

The significance of quantum computing does not lie in speeding up all computations, but in accelerating very specific problems. Despite their theoretical power, today’s quantum devices are far from capable of running these algorithms at meaningful scales. 

No one knows when, or even if, quantum computers will ever reach the scale required to threaten modern public-key cryptography. To break schemes like Ed25519, a quantum computer would need hundreds of thousands to millions of stable qubits, extremely high-quality error correction, and sufficiently long coherence times to run deep quantum circuits such as Shor’s algorithm. Today, such machines are purely theoretical. Existing quantum processors operate on noisy, short-lived physical qubits with error rates far too high for any meaningful attempts to break the cryptography. State of the art devices offer only on the order of hundreds to low thousands of physical qubits—not logical ones—and their gate fidelities and coherence properties remain several orders of magnitude below what would be required for a practical attack.

Even so, the potential long-term impact of quantum computing is significant enough that security-critical systems (including blockchains) must consider what a transition to post-quantum primitives would entail.

Quantum Attacks

Modern cryptography relies on hardness assumptions that classical computers cannot efficiently break. Quantum computers introduce two major algorithms that threaten different cryptographic primitives: Shor’s algorithm and Grover’s algorithm.

Shor’s algorithm efficiently breaks (it allows an attacker to derive the private key from the public key) RSA, Diffie–Hellman and, critically for Solana, elliptic-curve cryptography, including Ed25519, which is the core signature scheme used across the Solana protocol. This makes Shor a meaningful long-term quantum threat.

Grover’s algorithm provides only a quadratic speedup for brute-force search. It reduces the effective security of SHA-256 to 128 bits, which is still far beyond any realistic threat horizon. For symmetric cryptography, Merkle trees and hashing, it is still more cost-effective to scale classical hardware than to build a large-scale Grover-capable quantum machine. Therefore, Grover is not a realistic concern for Solana’s long-term security model.

Because large-scale quantum computers would fundamentally break today’s public-key cryptography, an entire field known as post-quantum cryptography (PQC) has emerged to develop schemes that remain secure even in the presence of quantum attacks. 

NIST (National Institute of Standards and Technology) has so far standardized two post-quantum digital signature schemes:

1. ML-DSA, lattice-based, derived from CRYSTALS-Dilithium
2. SLH-DSA, hash-based, derived from SPHINCS+

Both use public keys and signatures that are much larger than the elliptic-curve primitives used today. This makes early migration impractical for high-throughput systems like Solana unless quantum computers become an imminent threat. 

There is also FN-DSA (based on FALCON, designed as a smaller alternative to ML-DSA), which currently exists only as a draft proposal and is not yet an approved NIST standard.

Post-quantum cryptography is still in a very active stage of development. It is likely that long before any quantum computer capable of running Shor’s algorithm against Ed25519 exists, more efficient schemes will be discovered. Early nonstandard approaches, such as HAWK signatures, look promising, but are still at the research stage.

With internet bandwidth following Nielsen’s law and Solana’s transaction-size limit already increasing to 4096 bytes in 2026, it is reasonable to delay full PQ migration until more efficient schemes are available while preparing the protocol for eventual transition. In the meantime, it is also possible to rely on vault constructions based on well-established hash-based one-time signature schemes, such as Winternitz, which offer long-term security even against quantum attacks. These solutions exist on Solana today.

This article focuses only on the consensus-critical parts of Solana that rely on Ed25519. A full post-quantum migration would also involve other components, such as validator communication, encrypted networking channels, and symmetric cryptography—areas that would likewise need PQ-safe or hybrid replacements, but which are outside the scope of this overview.

Addresses and transaction signatures

Solana’s externally owned accounts (EOAs) use their public key as the address, with Ed25519’s 32-byte public key acting both as the identifier and the verification key. A post-quantum scheme changes this model, and such changes would naturally be introduced under a new address format and transaction version, rather than modifying the existing TX format.

• PQ public keys are much larger, so 32-byte addresses can no longer encode public keys directly. Addresses would instead become hashes of the PQ public key and of the signature scheme identifier.
• If PQ addresses coexist with existing Ed25519 addresses during migration, the address space must be constructed so that PQ-derived hashes cannot collide with points on the Ed25519 curve, ensuring that no Ed25519 private key exists for those addresses. This mirrors how PDAs avoid being valid Ed25519 points by using a bump seed.
• PDA security remains unaffected, because PDAs rely on SHA-256 second preimage resistance, which is not threatened by any plausible future application of Grover’s algorithm.
• The transaction ID today is the first Ed25519 signature in the transaction. With PQ signatures being far larger, this must change. A natural alternative is defining the transaction ID as a hash of the transaction payload, making it signature-agnostic and future-compatible.

Beyond user accounts, all authority keys in Solana are also Ed25519 public keys. This includes every form of protocol- or program-level authority: account owners, mint authorities, freeze authorities, upgrade authorities, stake and withdraw authorities, validator identity keys, and vote authority keys. They are all simply Ed25519 keypairs under different semantic roles, and therefore fall under the same post-quantum migration constraints as user addresses and transaction-signing keys.

As we will see in the Votor section, there is currently no PQ equivalent to aggregated signatures such as BLS. If such a scheme emerges in the future, we could also aggregate signatures over the message body and save a lot of space on transactions with multiple signatures—potentially even using less space than Ed25519.

Votor

Votor (i.e., the voting part of the Alpenglow consensus upgrade) relies on an all-to-all voting structure among validators. Validators send votes to all other validators every slot, and once quorum is reached, a certificate can be formed.

Today, this is efficient because BLS aggregation provides compact signatures and aggregated certificates. In a PQ setting, the situation changes.

There is currently no practically deployable PQ analogue to BLS aggregation. Several research directions exist, including lattice-based aggregation ideas such as Chipmunk. While none of them look fundamentally impossible, they are not yet efficient enough for Solana’s real-time requirements. There is also a STARK-based aggregation, which could, in principle, prove the validity of many signatures, but generating a proof for hundreds of validator signatures remains too slow…for now.

If we had to move toward signature aggregation in the near future, Votor could be adjusted so that the bandwidth impact is significantly reduced. Validators would forward full certificates only to the next one or two leaders and to a small, random subset of the stake, rather than broadcasting them to all peers. Bandwidth demands increase but remain comparable to the current pre-Alpenglow gossip layer.

Of course, reducing the number of validators would also mitigate the problem. If future protocol changes or economic designs were to result in a much smaller validator set, the bandwidth and computation requirements for PQ era voting and signature handling would become substantially more manageable. Fewer validators reduce the size of the all-to-all communication, lower the cost of certificate formation, and make even suboptimal PQ aggregation schemes more feasible in practice. However, such a reduction comes with its own trade-offs in decentralization and fault tolerance, and would therefore need to be weighed carefully against the system’s security goals.

Rotor (Turbine)

Rotor (the successor to the Turbine protocol), the data propagation protocol of the Alpenglow upgrade, is Solana’s single-relay network that disseminates blocks quickly and efficiently. It works by having the leader break the block into larger units called slices (or Forward Error Correction sets), each of which is composed of multiple shreds. The slices provide the forward-error-correction structure, while the shreds serve as the MTU-sized packets that get disseminated through Rotor. The leader then sends the shreds only to a small set of nodes in the first layer of the tree; each of those nodes verifies the shreds and forwards them to their own children, utilizing the bandwidth of many nodes in a fault-tolerant way rather than requiring the leader to broadcast to everyone. Because Rotor combines this structure with Forward Error Correction, nodes need to receive only a subset of the shreds to fully reconstruct the block, making the system resilient to packet loss while maintaining extremely high throughput.

To prevent malicious and invalid shreds from being propagated through the network, each shred includes a leader's signature, which works because Ed25519 signatures are small. PQ signatures are much larger, often exceeding MTU limits, so embedding one in each shred is not feasible.

Two realistic PQ-compatible approaches emerge:

A) One signature per slice (FEC set)

A practical direction is:

• Increase slice (FEC-set) size
• Authenticate the channels between validators to prevent malicious nodes from injecting untraceable forged shreds
• Compute a Merkle root over all shreds in that slice and have the leader sign only that root (which is already how the system works today)
• Each shred includes its Merkle proof, but no signature

Validators verify shred authenticity via Merkle proofs against the signed root. Invalid shreds are rejected immediately, preserving pipelining and compatibility with Rotor’s stake-weighted relay design.

B) One signature for the entire block

Another possible approach is:

• The leader signs only the final block hash (i.e., the vector commitment of all the shreds)
• Shreds are forwarded throughout the slot without any immediate signature-based authentication
• At block completion, validators verify the one PQ signature and check whether all received shreds match the authenticated block hash
  
  In this model:
  
  
• Validators cannot detect invalid shreds during the slot, because they cannot verify authenticity until the block signature is seen
• After the block is complete, invalid shreds are detected; the responsible relayers can be identified and temporarily blacklisted within Rotor
• This approach would also require authenticated channels between validators

Both strategies avoid the need to embed large PQ signatures into every shred, which is the main bottleneck for Rotor in a PQ world.

Myths

Myth 1: “If quantum computers break asymmetric cryptography, we have bigger problems than broken crypto.

It’s often claimed that once quantum computers can break public-key cryptography, the entire digital world collapses at once: banks, governments, payment networks, everything. In reality, centralized systems can migrate to new cryptography much more easily. A bank or government can rotate keys internally, update infrastructure, and force users to adopt new secure channels.

Public blockchains cannot. A blockchain cannot centrally rotate millions of user keys without the users themselves signing a migration transaction. Every user must use their current private key (which is the very thing becoming vulnerable) to move their assets to a post-quantum-safe address. This makes migration far more complex and time-sensitive for decentralized systems than for any centralized service.

Myth 2: “If you’ve never spent from an address, you’re safe.”

This is partially true only for some chains (e.g., Bitcoin). In such designs, coins are often locked behind a hash (e.g., P2WPKH), and the public key becomes known only when the user spends from that address. Until then, the actual public key is hidden. But this protection disappears the moment a single spend happens. Once revealed, that public key remains exposed forever, and in a post-quantum world, it becomes a target for Shor’s algorithm.

Solana, however, uses a different model: every address is a public key. There is no “hidden” layer and no pre-image protection from hashing. As a result, every externally owned account on Solana is, by default, Shor-vulnerable once a sufficiently powerful quantum machine exists. No unspent-address safety net exists here.

Myth 3: “Quantum computers are just around the corner.”

Despite impressive engineering progress in the last year, quantum computers remain incredibly limited. Today’s devices can run toy versions of Shor’s algorithm, typically demonstrated on factoring numbers like 21, which is trivial and offers no real cryptanalytic value.

Breaking modern cryptography would require hundreds of thousands to millions of stable qubits, extremely low error rates, long coherence times, and deep, error-corrected circuits.

Myth 4: “Grover’s algorithm makes hash functions useless.”

Grover’s algorithm offers a quadratic speedup for brute-force search. For SHA-256, that means reducing 256-bit security to roughly 128 bits. This remains far beyond any realistic attack horizon, especially compared to the monumental difficulty of building a quantum machine that can even execute Grover at scale.

For symmetric cryptography, Merkle trees, and hash-based constructions, including PDAs on Solana, classical scaling is cheaper and more practical than relying on quantum attacks.

Myth 5: “A quantum computer can extract your seed phrase from your public key.”

No quantum algorithm can magically derive a seed phrase from a public key. A seed phrase is not mathematically embedded in the public key, nor is there any reversible mapping that exposes wallet seeds through public information. Quantum computers could derive the private key from the public key, but they cannot reach further “upstream” to reconstruct the seed phrase that originally generated that keypair.

Seed phrases derive private keys through a one-way key-derivation function, and Shor’s algorithm cannot invert those functions. A quantum attacker gaining your private key is already catastrophic—they can sign transactions—but they still cannot clone or recover your seed phrase, which can protect your new PQC keys with a different derivation path.

Conclusion

Solana does not need to migrate to post-quantum cryptography anytime soon. Achieving this would require changes to the transaction format to carry larger PQ public keys, logic to ensure the derived address hash is off-curve (possibly using a bump/salt to avoid collisions), and support for verifying multiple PQ schemes inside the runtime. The biggest costs would be increased transaction size and higher verification compute, since PQ signatures are more expensive to process than Ed25519. The timeline for practical quantum computers ranges from “a few years” to “never,” and today’s PQ signature schemes are quite large and slow for a system optimized around extremely high throughput.

But if a migration eventually becomes necessary, the path is conceptually clear. None of these changes is impossible, but they would reshape some of Solana’s most performance-sensitive subsystems. The good news is that by the time a credible quantum threat appears, the cryptographic landscape will likely look very different, and far more efficient PQ primitives may exist.

References

• Alpenglow Whitepaper
• NIST Post-Quantum Signature Standards (ML-DSA, SLH-DSA)
• HAWK Signatures
• Solana Winternitz Vault
• Shor’s Algorithm (1994)
• Grover’s Algorithm (1996)