Blockchain Quantum Readiness Index / Solana
L1 · Solana
Solana
Blueshift's post-quantum vault runs on mainnet but is upgradeable by an elliptic-curve key, so it does not yet protect funds against a quantum attacker. Accounts, vote messages and feature activation all still rest on elliptic-curve keys. Anza has published a post-quantum roadmap and merged a migration prototype, but the prototype is not activated on mainnet.
Last reviewed 2026-10-19
Is Solana quantum safe?
Not yet. Solana is at Stage 3 (Testnet) in LimeChain's Blockchain Quantum Readiness Index, with a progress score of 33.3/100. Post-quantum accounts run on a testnet, or on mainnet without keeping funds safe at rest, so users cannot rely on them yet. Still exposed or unproven: admin & upgrade keys.
What Solana needs for Stage 4: Live option
- Stage 4 needs PQ user accounts on mainnet that keep funds at rest out of reach of ECC keys (U is: live-experimental, hold: exposed)
Caps and adjustments
- U: 'WOTS' is not in the mechanism registry -> max 8 points, cannot pass stage gates
- U: PQ spending is live but funds at rest are not PQ-protected (hold: exposed) -> max 6 points, not live
- cap 40: users cannot hold and spend funds under a production PQ mechanism on mainnet
- cap 60: consensus PQ not even on testnet
Rosette slices
| Slice | State | Points | Weight | Reason & evidence |
|---|---|---|---|---|
| U User keys | Live (experimental) non-standard WOTS Winternitz one-time signatures over SHA-256 (plain WOTS, not WOTS+) At rest: Exposed at rest Wallet (system) account addresses are raw 32-byte Ed25519 public keys, so the controlling key is on-chain from the start. The only PQ option, Blueshift's Winterwallet Winternitz vault program (winter5vMwvf51xrSVPTxbAAD6qiSTmPeRTSizMCQCa), is still upgradeable: its ProgramData upgrade authority is 21VbD6sGvLyuvkwLZMTXnuYJmPiAWUBDkdeH68q2sPyT, a system-owned on-curve Ed25519 key (measured via mainnet RPC at slot 456411731 on 2026-10-13), so vault funds can be moved by whoever forges that key. PDAs are off-curve but are controlled by programs, not by PQ keys. |
6/10 | 25 | The Winterwallet Winternitz-OTS vault program (winter5vMwvf51xrSVPTxbAAD6qiSTmPeRTSizMCQCa) works on mainnet but its README says it is not formally audited, and it is upgradeable by an Ed25519 authority (21VbD6sGvLyuvkwLZMTXnuYJmPiAWUBDkdeH68q2sPyT, re-measured 2026-10-19), so hold is exposed and vault funds are only as safe as that ECC key. Usage is negligible (23 signatures through 2026-10-15). The scheme is not in the registry, so the slice is non-standard. |
| C Consensus | Planned | 2/10 | 20 | Anza's published plan would replace BLS vote signatures with a PQ scheme such as FALCON, but the Falcon work is only drafts: SIMD-0461 was withdrawn and the Firedancer and solana-sdk PRs are closed/draft. |
| P Proof system | Not applicable | — | — | L1 without a validity or fraud proof system. no evidence |
| B Bridges & messaging | Not applicable | — | — | No canonical bridge: the complete SIMD index (the repository that 'tracks past and ongoing improvements to Solana') has no bridge proposal; bridges such as Wormhole are third-party programs. Sources 9 |
| A Admin & upgrade keys | Exposed | 0/10 | 15 | Protocol feature activation rests with ECC keys: a feature is queued for activation by its keypair holder (a core contributor team) and takes effect at the next epoch boundary with no on-chain vote or timelock (SIMD-0089, Activated). The Feature Gate program itself has no upgrade authority and major system programs are native or frozen (Token-2022 upgrade authority measured None on 2026-10-12), but individual deployed programs, including the Winternitz vault, remain upgradeable by ECC authorities. Sources 10 |
| M Migration & recovery | In development | 4/10 | 15 | Anza merged a post-quantum proof-of-knowledge-of-seed migration prototype (anza-xyz/cryptography#10) but it is not activated on mainnet and no scheme is committed. |
Stage gates
| Requirement | Status | Details & evidence |
|---|---|---|
| Current audit of the deployed PQ signing code (Stage 5) | Not met | not claimed |
| Admin timelock of at least 30 days with a PQ override (Stage 6, alternative to PQ admin keys) | Not met | not claimed |
| Ratified migration plan with an activation date (Stage 6) | Not met | not claimed |
| New accounts PQ or hybrid by default (Stage 6) | Not met | not claimed |
| ECC sunset enforced (Stage 7) | Not met | not claimed |
PQ adoption published, not scored
No published adoption numbers were found yet. Having PQ accounts does not mean people move to them. This tracks the share of value and accounts that actually moved, over time.
Measured exposure
No on-chain probe run yet. Bitcoin, Solana, Cosmos and Substrate probes are planned.
Evidence and sources (11)
Every non-zero rating above cites at least one of these public sources.
- blueshift.gg/research/quantum-proofing-solana
- solana.com/news/quantum-readiness
- github.com/blueshift-gg/winterwallet
- solana.com/docs/core/accounts
- raw.githubusercontent.com/blueshift-gg/winterwallet/master/RE…
- api.mainnet-beta.solana.com
- anza.xyz/blog/securing-solana-against-a-powerful-quantum-adve…
- github.com/anza-xyz/solana-sdk/pull/537
- github.com/solana-foundation/solana-improvement-documents/blo…
- github.com/solana-foundation/solana-improvement-documents/blo…
- github.com/anza-xyz/cryptography/pull/10
Source: chains/solana.json. Reproduce: python3 score.py chains/solana.json
Building on Solana?
LimeChain helps teams plan their post-quantum migration: what is exposed, what to change first, and the engineering to get there.
Talk to usOpen, repeatable scoring. Non-zero ratings need public evidence; missing evidence means unknown. Methodology v0.4 · mechanism registry 2026-10-13.