Quantum risk is often discussed in extremes. One version treats it as an immediate existential threat. Another dismisses it as a problem for a future generation of protocol engineers. Neither framing is especially useful.
For blockchains, the more practical question is not whether a cryptographically relevant quantum computer exists today. It does not. The question is whether a network with billions of dollars of state, long-lived accounts, hardware-wallet integrations, validator identities, and consensus-critical signatures can migrate its cryptography quickly once the threat model changes.
For Solana, the answer is unusually concrete. The ecosystem now has serious research from both Anza and Firedancer, early Falcon implementations, an exploratory SIMD for Falcon verification, production-facing hash-based vault work from Blueshift, and an Agave proof-of-concept demonstrating that post-quantum transaction signing, validator identity, batched voting, and hardware-wallet flows can be wired through a Solana client.
That is meaningful progress. It is not the same thing as production readiness.
This post reviews what has been built, what the current engineering work proves, where the protocol still needs to make decisions, and why the most important remaining work is not a single syscall or signature primitive. It is coordination across transaction format, account addressing, consensus, fee markets, hardware signing, and wallet migration.
What Quantum Risk Means for Solana
A sufficiently capable quantum computer running Shor’s algorithm would undermine the discrete-logarithm assumptions behind today’s elliptic-curve signatures. For Solana, that matters in several places.
First, user accounts are authorized by Ed25519 signatures. If an attacker can recover an Ed25519 private key from a public key, any account that has not migrated to a quantum-resistant authorization scheme becomes vulnerable.
Second, validator and network identities also rely on classical signatures. A quantum-capable adversary would not merely threaten cold wallets; it would affect validator authentication, gossip, and any protocol surface where a public key is assumed to be one-way.
Third, Solana’s next-generation consensus roadmap introduces its own cryptographic constraints. Alpenglow’s use of BLS-style aggregation is attractive because aggregated signatures compress many validators’ votes into a small verification object. Post-quantum signatures generally do not provide that kind of simple aggregation today, which makes consensus migration a different problem from wallet migration.
Finally, programs that verify secp256k1, Ed25519, or BLS signatures for application-level authorization inherit the same long-term exposure. Application developers can mitigate some of this earlier than the base protocol, but only if the runtime exposes efficient post-quantum verification primitives.
This is the right way to scope the issue: not panic, not complacency, but systems planning.
Where Solana Stands Today
The public Solana roadmap is converging around Falcon, also standardized by NIST as FN-DSA, as the leading candidate for high-throughput post-quantum signatures. The reason is straightforward: signature and public-key size matter on Solana.
A Falcon-512 signature is roughly 666 bytes, with a public key of roughly 897 bytes. ML-DSA-65, by contrast, has a 3,309-byte signature and a 1,952-byte public key. ML-DSA is simpler and already standardized as FIPS 204, but those sizes are costly in a network designed around small, fast, highly parallel transaction payloads.
Solana’s current maximum serialized transaction size remains 1,232 bytes. SIMD-0296 proposes raising that to 4,096 bytes, and related transaction-format work may improve the developer experience around larger payloads. But even at 4,096 bytes, ML-DSA-65 is awkward for general-purpose use: a single signature plus public key is already more than 5KB before message data, account metadata, instructions, or framing overhead. Falcon is not small compared to Ed25519, but it is at least plausible.
This is why the independent alignment between Anza and Firedancer matters. The selection pressure is not ideological. It is architectural. Solana’s design rewards compact signatures, fast verification, and predictable data movement. Falcon fits that design better than ML-DSA for the base transaction layer, even if ML-DSA remains valuable for applications that prioritize standard maturity and implementation simplicity.
What the Agave Proof-of-Concept Demonstrates
In parallel with the broader Falcon research, Anagram has built an Agave proof-of-concept around ML-DSA-65. This is useful precisely because it exercises the migration surface rather than stopping at the primitive.
The proof-of-concept introduces ML-DSA key generation, signing, verification, address derivation, transaction encoding, validator identity extensions, vote-account plumbing, detached shred attestations, SBF syscall usage, and hardware-wallet signing flows. It shows that Solana can carry post-quantum signatures through a validator client and finalize local-cluster activity using post-quantum authorization paths.
The most important lesson is not “ML-DSA should be the final answer.” It is that adding a post-quantum signature scheme to Solana is not just a cryptography task. It changes assumptions embedded throughout the system.
Account Addresses Cannot Simply Become PQ Public Keys
Solana account keys are 32-byte Pubkey values. ML-DSA-65 public keys are 1,952 bytes. Falcon-512 public keys are roughly 897 bytes. Neither fits into Solana’s existing account-address model.
The Agave proof-of-concept uses a pragmatic design: hash the post-quantum public key into a 32-byte Solana address using domain-separated BLAKE3-256, then carry the full post-quantum public key alongside the transaction when verification is required.
This preserves compatibility with Solana’s account model, but it introduces a new protocol assumption. The address is no longer the signing public key itself. It is a digest of a larger key. That means the protocol must specify the hash function, domain separation, versioning, off-curve rules, and collision-avoidance strategy with the same rigor currently applied to signature verification.
The security target is still strong. A 256-bit hash offers a substantial margin even under Grover-style quadratic speedups. But it is a different trust boundary than Ed25519-as-address, and it needs to be documented as such.
Transaction Format Is a First-Class Migration Problem
The proof-of-concept uses a V2 transaction format with variable-length signature material and signer public keys. That is the right shape for experimentation because post-quantum signatures are not fixed at 64 bytes and different schemes have very different sizes.
The constraint is bandwidth. A legacy Ed25519 signature is 64 bytes. A Falcon-512 signature plus public key is roughly 1.6KB. An ML-DSA-65 signature plus public key is roughly 5.3KB. These numbers turn the transaction format from an implementation detail into a protocol decision.
A post-quantum transaction format must answer several questions:
- Which signature schemes are valid at the protocol layer?
- Is the transaction signed directly, through a sidecar, or through a digest committed into the message?
- How are signature bytes priced?
- How are public keys carried, cached, or referenced?
- How do RPC nodes, indexers, explorers, wallets, and hardware signers represent these transactions?
SIMD-0296’s 4,096-byte target is a necessary step for richer transactions, but it is not sufficient for arbitrary post-quantum multisig, ML-DSA-based transfers, or large authorization sidecars. The ecosystem should be explicit about this. A 4KB transaction limit makes Falcon-style post-quantum transactions plausible. It does not make every post-quantum construction practical.
Verification Primitives Need to Be Exposed Carefully
The Agave proof-of-concept includes an ML-DSA precompile and syscall for SBF programs. SIMD-0461 similarly began as a Falcon precompile proposal before being refactored toward a syscall after feedback from core engineers.
That evolution is instructive. Solana has historically used precompiles for certain cryptographic operations, but precompiles complicate runtime optimization and execution-pipeline design. A syscall-based primitive may be a cleaner fit if it exposes the right verification surface without introducing unnecessary special cases.
The near-term value of a Falcon syscall is application-level experimentation. It allows smart contracts to verify post-quantum signatures before the base transaction layer migrates. Developers can build vaults, recovery flows, and hybrid authorization systems while the core protocol continues to evaluate the larger migration.
That is a reasonable sequencing: make verification available to programs first, then move transaction authorization only when the transaction format, address format, fee model, and wallet ecosystem are ready.
Sombra, a post-quantum private-payments protocol from Bonsol Labs built on Bonsol, is a useful example of this application-first path. Rather than waiting for Solana’s base transaction layer to migrate, Sombra is designed as a standard Solana program that brings quantum-safe privacy to the application layer: STARK proofs for transfer validity, Kyber-768/ML-KEM for note encryption, and zero-knowledge proofs of decryption in place of classical signatures for spend authorization. Projects like Sombra show the shape of the near-term opportunity: post-quantum primitives can begin protecting specific applications before the protocol has finalized transaction authorization, validator identity, consensus aggregation, and wallet migration.
Validator Identity and Gossip
The proof-of-concept extends validator identity into the post-quantum setting by allowing validators to advertise ML-DSA public keys in gossip and dual-sign contact information.
This is one of the more important parts of the work because it highlights a subtle migration problem: backward compatibility can create downgrade risk.
During any transition, some validators will be classical-only, some will be hybrid, and eventually some may be post-quantum-only. If a validator has advertised a post-quantum identity, nodes need to know when Ed25519-only verification is no longer sufficient. Otherwise, an adversary could strip the post-quantum material and present a legacy-looking identity path.
The proof-of-concept handles this by distinguishing pure post-quantum identities, where the account address is derived from the post-quantum public key, from legacy validator IDs that attach post-quantum keys through gossip. That kind of distinction will be necessary in any production migration.
The broader principle is simple: hybrid periods are dangerous unless the downgrade rules are crisp.
Consensus Is the Hardest Part
Wallet signatures are the most visible surface area, but consensus signatures are likely the hardest post-quantum problem.
Modern consensus protocols benefit enormously from aggregation. If a thousand validators sign the same message, an aggregate signature can compress verification and bandwidth in ways that keep the protocol fast. Classical BLS signatures are useful here because they aggregate cleanly.
Post-quantum signatures generally do not give Solana a drop-in replacement for BLS aggregation. Falcon and ML-DSA are plausible transaction-signature candidates, but they do not automatically solve consensus vote aggregation.
The current Agave proof-of-concept includes batched post-quantum voting, which is valuable but should not be confused with true cryptographic aggregation. Batching reduces the number of signatures produced by one validator over multiple votes. Aggregation compresses signatures across many validators for the same consensus object. They solve different problems.
There are promising research paths, including lattice-based multisignatures and Falcon aggregation through proof systems such as LaBRADOR. But this remains active research, not something that should be described as solved protocol engineering.
For that reason, Solana’s post-quantum roadmap should keep transaction authorization and consensus migration conceptually separate. Falcon may be the right answer for user transactions before the ecosystem has a final answer for consensus aggregation.
Shreds, Leaders, and Network Authentication
The proof-of-concept also explores detached post-quantum attestations for shred Merkle roots. This is the right place to experiment because existing shred headers include fixed-size Ed25519 signatures. Replacing those directly with post-quantum signatures would require a new shred format or a sidecar-based propagation mechanism.
Detached attestations are a reasonable interim model: preserve existing packet layouts while adding post-quantum commitments that can be verified by upgraded nodes. But this is not yet equivalent to a production shred-authentication migration. The leader, TVU, retransmit, and repair paths all need to understand how these attestations are produced, propagated, verified, cached, and rejected.
Here again, the proof-of-concept proves feasibility. It does not remove the need for a protocol-level design.
Hardware Wallets and Custody
Post-quantum signatures are also a hardware problem.
Ed25519 is compact and fast. ML-DSA and Falcon require larger keys, larger signatures, more memory, more code, and more careful side-channel analysis. Falcon in particular has historically raised implementation-complexity concerns because of its sampling and arithmetic requirements.
The Agave proof-of-concept includes a Keystone ForgeBox path with a no_std ML-DSA implementation targeting embedded hardware. That is encouraging because it shows that constrained signing devices can participate in a post-quantum flow. But the broader custody ecosystem is not ready yet.
Institutional custody depends on audited firmware, deterministic build processes, secure entropy, signing UX, policy engines, and often threshold signing. Threshold Ed25519 and ECDSA are mature enough to support production custody. Threshold ML-DSA and Falcon are still emerging. Recent research is improving the picture, but production-grade MPC and hardware-wallet support remain blockers for a serious network-wide migration.
This matters because a post-quantum migration that only works for command-line keypairs is not a migration. It has to work for wallets, custodians, exchanges, validators, and users who will never read a SIMD.
Winternitz Vaults Are Useful, But Not Sufficient
Solana already has a practical post-quantum custody primitive in Blueshift’s Winternitz Vault. Hash-based one-time signatures are conservative, understandable, and quantum-resistant. For high-value, low-frequency custody, that is an excellent fit.
But Winternitz-style schemes have real trade-offs. They are one-time or limited-use constructions. They require state management to avoid key reuse. They are not a natural replacement for general-purpose account authorization, high-frequency trading, programmatic payments, or everyday wallet flows.
This makes them complementary to Falcon, not a substitute for it. Winternitz vaults are a credible interim defense for certain funds today. Falcon or another compact post-quantum signature scheme is still needed if Solana wants a general-purpose quantum-resistant signing model.
Fees Need to Price Bytes, Compute, and Contention
Solana’s current base fee model is signature-oriented. Post-quantum signatures make that model less natural.
A “signature” is no longer a roughly uniform 64-byte object with predictable verification cost. It could be a 666-byte Falcon signature, a 3,309-byte ML-DSA signature, a large hash-based signature, or a hybrid bundle containing both classical and post-quantum material. The public key may also need to be included or referenced.
A production fee model should price at least three resources:
- Verification compute.
- Transaction bytes and network bandwidth.
- State or cache pressure from large public-key material.
This does not necessarily mean Solana needs an entirely new fee market for post-quantum transactions. It does mean that “one signature equals one fee unit” becomes too coarse once signatures are variable-sized and scheme-dependent.
The economic question becomes sharper during migration. If quantum-resistant transactions are larger and more expensive to propagate, users may delay upgrading unless the protocol, wallets, and fee markets make the safe path obvious and affordable.
The Scheme Decision: Falcon, ML-DSA, or Both
The ecosystem’s emerging answer is Falcon first.
That is the right default for Solana’s base transaction layer. Falcon has the smallest signatures among the NIST post-quantum signature candidates under serious consideration, and compactness matters more on Solana than it does in many other systems.
ML-DSA still has an important role. It is standardized, easier to reason about from an implementation perspective, and avoids some of Falcon’s historical concerns around complex sampling and side-channel-resistant implementations. For application-specific authorization, controlled environments, or systems where bandwidth is less binding, ML-DSA may be preferable.
Supporting both at the protocol layer would maximize flexibility, but it would also increase complexity across wallets, RPCs, hardware signers, audit surfaces, fee schedules, and transaction parsing. Solana should be cautious about standardizing multiple base-layer signature schemes unless there is a clear operational reason to do so.
A reasonable division of labor is:
- Falcon for protocol-level transaction authorization, assuming the implementation and standardization path remain sound.
- ML-DSA as an application-level option through program verification primitives where developers explicitly choose the trade-off.
- Hash-based vaults for high-value, low-frequency custody where one-time signing semantics are acceptable.
The Migration Path for Existing Accounts
New accounts are easier than existing accounts. A new wallet can generate a post-quantum keypair, derive a versioned address, and sign under the new scheme from day one.
Existing accounts are harder because Solana addresses are currently tied to Ed25519 public keys. A naive migration would ask users to sign a transaction with their current Ed25519 key and bind a post-quantum key. That works before a quantum adversary exists. It may not work after, because the attacker could recover the same Ed25519 key.
Anza’s research proposes a more elegant path: prove knowledge of the original seed material behind an Ed25519 account, rather than merely proving possession of the derived private key. This could allow a legitimate user to migrate even in a world where Ed25519 private keys are recoverable from public keys, assuming legacy Ed25519 authorization has been disabled.
That is a promising direction, but it is not a small feature. It requires careful proof-system design, wallet support, migration UX, and a protocol rule for how old accounts become bound to new post-quantum authorization.
The migration problem is mostly a user-distribution problem. It is not enough to design a secure path. The ecosystem must make that path easy enough that users actually take it before it matters.
What Needs to Happen Next
Solana’s quantum-readiness work is in a good place because the ecosystem is no longer debating abstractions. There is code, there are concrete proposals, and there is independent agreement around the shape of the solution.
The next phase should focus on protocol decisions:
- Finalize the first verification primitive. A Falcon syscall is the right near-term step because it enables application experimentation without forcing a transaction-layer migration.
- Complete larger-transaction work. A 4,096-byte transaction target makes Falcon-based flows much more plausible, but the ecosystem should be honest about what still does not fit.
- Specify post-quantum address derivation. The protocol needs a formal standard for domain separation, versioning, hash function, off-curve mapping, and future algorithm agility.
- Separate wallet migration from consensus migration. Transaction signatures and consensus aggregation have different requirements and should not be forced into a single timeline.
- Invest in hardware and custody. No migration is real until hardware wallets, institutional custody, exchanges, validators, and threshold-signing providers can support it safely.
- Define the fee model. Variable-size signatures need a cost model that reflects verification compute, bandwidth, and public-key material.
Conclusion
Solana is ahead of most major blockchain ecosystems on post-quantum readiness, not because the threat is imminent, but because the engineering work has started before urgency forces bad decisions.
The current state is best described as credible preparation. Anza and Firedancer have independently converged on Falcon as the leading high-throughput candidate. SIMD-0461 gives the ecosystem a concrete path toward onchain Falcon verification. Blueshift’s Winternitz Vault provides a production-facing quantum-resistant custody option today. Sombra shows how post-quantum privacy can begin at the application layer, using quantum-safe primitives inside a standard Solana program rather than waiting for a base-layer migration. The Agave proof-of-concept demonstrates that post-quantum transaction signing, validator identity, voting, shred attestations, SBF verification, and hardware-wallet flows can be wired through a Solana client.
What remains is the difficult part: turning prototypes and research into a coherent migration plan.
The ecosystem still needs to standardize address formats, enlarge transaction capacity, price larger signatures correctly, support hardware and threshold signing, and solve or route around the consensus aggregation problem. None of those are reasons to delay. They are the reason to keep the work moving now, while the threat is still distant enough for the protocol to choose deliberately.
Post-quantum migration will not be one upgrade. It will be a sequence of compatible steps: application-level verification, new wallet formats, larger transactions, account migration, custody support, and eventually consensus changes. Solana’s advantage is that those steps are now visible.
The transition will not start from a blank page. It will start from working code, serious client-team research, and a network culture that treats performance constraints as first-class protocol design.
References
- Solana Foundation: “Solana’s Quantum Readiness”
- Anza: “Securing Solana Against a Powerful Quantum Adversary”
- Jump Crypto: “Quantum Migration Paths for Solana”
- SIMD-0461: Falcon Signature Verification as a Syscall
- SIMD-0296: Larger Transactions
- NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
- NIST FIPS 206: FN-DSA Initial Public Draft
- Ethereum EIP-8052: Falcon Signature Precompile
- Ethereum EIP-8053: Dilithium Signature Precompile
- Blueshift: Solana Winternitz Vault
- Bonsol Labs: “Sombra: A Quantum-Safe Private Payments Protocol on Solana”
- Sombra Docs: Architecture
Legal Disclaimer
The information in this article has been prepared by Anagram Ltd. (“Anagram”) for educational and informational purposes only. Under no circumstances should this, or any post on this website, be construed as solicitation for investment in Anagram, its affiliates, or any projects named herein or otherwise. The contents herein, and content available on any associated distribution platforms, including Anagram online social media accounts, should not be construed as or relied upon as investment, legal, tax, or other advice.Certain information contained herein, including in charts and graphics, may have been obtained from third parties. While such sources are believed to be reliable, Anagram does not assume any responsibility for the accuracy or completeness of such information. No assurance is made by Anagram regarding the accuracy or completeness of the information or opinions set forth herein, whether or not obtained from third parties, and Anagram shall not be liable therefor. Certain statements herein are based on subjective beliefs, may differ from the views of other market participants, and are subject to change.This presentation contains “forward-looking statements,” which can be identified by the use of forward-looking terminology such as “may”, “will”, “should”, “expect”, “anticipate”, “project”, “estimate”, “intend”, “continue” or “believe” or the negatives thereof or other variations thereon or comparable terminology. Due to various risks and uncertainties, actual events or results may differ materially and adversely from those reflected or contemplated in the forward-looking statements.Anagram and its affiliates may consult, invest, build, or otherwise have interest in companies or projects that are written about in this space. This content is for educational purposes only and does not constitute advice, marketing or solicitation for funding.