Public key cryptography sits underneath every operation on a blockchain. Users produce signatures to authorize transactions, validators pack transactions in blocks and produce signatures to achieve consensus on which blocks are valid. Ownership and consensus both reduce to the one operation of checking the validity of a signature against a public key.
In a permissionless system, a valid signature is the only proof of authority. An account belongs to whoever can produce a valid signature for its public key. This works because the relationship between the two keys is assumed to be one way, where deriving a public key from a private key is easy, but recovering the private key from the public key is assumed to be infeasible. Quantum computing threatens that assumption, as a sufficiently capable quantum computer could break today’s elliptic curve based signature schemes, undermining both ownership and consensus.
A credible post-quantum roadmap for Solana therefore needs to address the potential threat across consensus, transaction signatures, and the migration path for existing wallets. Each of these components have different technical constraints and performance requirements.
In this post, we discuss a migration path for Solana. Falcon is currently our leading candidate due to its relatively small signatures, but as we’ll discuss below, each component could evolve independently, depending on its bandwidth and implementation constraints.
Recent Developments in Quantum and Post-Quantum
The recent estimates published by Google [1], Nvidia’s increased investment in quantum research [2], and broader progress in error correction and quantum tooling are enough to warrant a roadmap and community discussion.
We do not view quantum computers as an immediate threat to the security of Solana. Our current assumption is that attacks on elliptic curve cryptography remain years away, while Solana continues to ship every month. With substantial research and development still in progress, we intend to continue exploring potential alternatives so that any future changes can be based on the strongest available option, rather than on a decision made prematurely.
At the time of writing, only ML-DSA (Dilithium) is standardized by NIST, and FN-DSA (Falcon) is just a few months away from completing the standardization process. The longer timeline for the roadmap we are pursuing allows us to consider schemes that could fit the protocol better. Future research done in quantum-resistant constructions that could yield even better schemes for Solana remains on our radar. SQISign is a great example, as the signature scheme offers significantly smaller public keys and signatures than Falcon or ML-DSA, but with the current limitation of being extremely slow to verify. Should future advances produce a more efficient verification algorithm, it could become a compelling candidate.
The primary limitations of most post-quantum signature schemes are large signatures and public keys. This would mean adding kilobytes to every transaction and consensus vote, which for a high performance blockchain like Solana could be detrimental. The following table compares the size of public keys and signatures for the schemes that we reference in this article.
For more information, see Cloudflare's summary of currently available PQC schemes.
Consensus
Solana's Alpenglow consensus protocol uses BLS12-381 signatures, in particular because they perform efficient signature aggregation. In Alpenglow, validators’ votes are BLS signatures, and certificates are an aggregation of votes.
An ideal post-quantum consensus layer would still allow for aggregate signatures. Recent work on Falcon signature aggregation using the LaBRADOR proof system showed that aggregation is possible. For consensus, where all validators sign the same message, lattice-based multi-signature protocols (e.g., Raccoon, DOTT) are an active area of research and a plausible path forward.
The signature scheme chosen for consensus could be independent from the scheme used for signing transactions. Just as Alpenglow uses BLS12-381 while transactions use Ed25519, a post-quantum adaptation could use a scheme that best fits its aggregation and latency requirements.
Transaction Signatures
Among NIST's selected post-quantum signature standards, Falcon offers the smallest signatures, which is critical for bandwidth.
Falcon’s standardization was delayed due to concerns of implementation complexity and side-channel attacks; however:
- Falcon signature verification is integer-only and not complex to implement.
- Signing is offchain, wallets and validators control their own signing and can use carefully audited implementations, including integer-only variants [6][7].
As mentioned above, a promising alternative is SQISign, which offers exceptionally small public keys and signatures comparable to those of elliptic curve schemes. Recent advancements continue to improve its security profile and performance; however, it remains unstandardized and is still an active area of research.
Existing Wallets
Another important consideration is the treatment of existing wallets. For blockchains like Bitcoin, a central concern is how to protect funds held in older wallets and migrate them safely to post-quantum secure alternatives.
Fortunately, Solana has a viable migration path for all existing wallets. As noted above, Solana uses Ed25519, in which the private key is derived from a 32-byte seed. During signing, SHA-512(seed) is computed to derive a secret value, which is then used to generate both the public key and signatures. A quantum computer attacking Ed25519 may be able to recover this derived secret value, but not the original seed itself. SHA-512 remains a quantum-resistant one-way hashing function, so the seed remains unrecoverable.
Since a quantum attacker only recovers the secret value, but not the seed, the legitimate owner retains exclusive knowledge. This enables a migration protocol that could look like this:
- Adopt a post-quantum scheme (e.g., Falcon) for new wallets.
- Disable Ed25519 signature verification, as anyone with a quantum computer could recover the secret value and forge signatures.
- Migrate existing wallets by requiring the owner to provide both a valid post-quantum signature from a new keypair, and a zero-knowledge proof showing that they possess the Ed25519 seed.
As we mentioned above, this would allow authorized fund migration without relying on the “broken” Ed25519 signature scheme, since only the legitimate owner could produce the required zero-knowledge proof. Several viable ZKP frameworks could support such a mechanism. While generic constructions may require relatively large proofs (tens or hundreds of kB), this is not a significant concern given that migration would occur only once.
Another class of “wallets” unique to Solana is Program Derived Accounts (PDAs), for which no private key exists; therefore, PDAs are inherently quantum safe.
Other Notes
Solana uses Ed25519 for other parts of the protocol as well. This includes Turbine, where shreds are signed by the leader, Gossip, and QUIC. A transition of these components would look nearly identical to that of transaction signatures.
Currently the Solana runtime exposes a variety of functionalities to developers for working with elliptic curve cryptography, including Ed25519, Secp256k1, Secp256r1, BLS12-381, etc. During a protocol migration, these would simply be turned off, deemed insecure in a post-quantum world, and replaced with newer primitives.
Experimental community R&D efforts, like those at Blueshift, emulate post-quantum custody on-chain using the primitives available today. Their work with Winternitz One-Time Signatures (WOTS) demonstrates an example of an opt-in path to quantum-resistant cold storage, without requiring protocol changes.
Next Steps For Solana
The immediate next step for the protocol is to add a Falcon signature verification syscall for use within smart contracts. This is proposed in SIMD-0416. Efficient onchain Falcon verification would allow developers to adopt Falcon and build their own post-quantum vaults, transfers, and other DeFi primitives.
This does not amount to adopting Falcon as a new protocol level signature scheme or integrating it into Alpenglow. Solana operates on a fast release cadence, while post-quantum research and standardization are still evolving, our focus remains on enabling practical near term use cases while continuing to evaluate the strongest long-term option.
On the Firedancer side, we have developed a highly optimized Falcon signature verification implementation that is 2-3x faster than the reference implementation and will undergo further evaluation and security audits. In parallel, we will continue evaluating alternative schemes to ensure that future protocol decisions can be made with the best available options.
