Inventory well-documented and specific; deployment state separated from published design for every post-quantum entry.

Every signature-bearing primitive in the live stack and approved successor stack is Shor-vulnerable. No PQ-safe primitive is in protocol use. Token-2022 confidential transfers rest on twisted ElGamal public-key encryption over Curve25519 (Shor-break), live and maintained in current mainnet releases; harvested confidential-balance ciphertexts become decryptable once the curve breaks. Validator QUIC transport key exchange is X25519 only.

Families in the core protocol: 0 PQ families (Ed25519 / BLS12-381 are classical DL / pairing). On mainnet at the app level, two PQ families are deployed and executable as opt-in third-party programs: hash-based (Winterwallet, W-OTS over truncated SHA-256, program deployed 2026-04-27) and lattice (Vector Falcon-512, program deployed 2026-05-29, authorizing the ORE smart wallet whose transfers are authorized by an on-chain-verified Falcon-512 signature). A HAWK-512 SVM library also exists; HAWK is lattice-based, so it adds no family diversity beyond Falcon, and the HAWK-512 scheme program identifier in that library's documentation is not present on mainnet. The client-side Falcon implementations were closed unmerged (syscall proposal 2026-06-17; Firedancer implementation 2026-07-08), so no lattice code sits in any consensus client. Protocol-level deployed diversity remains 0 families; we score 7, crediting two app-level families at roughly half the protocol-level '2 mixed = 15' value. The Cryptographic-Diversity Cap (lattice monoculture) does not fire: nothing is deployed at protocol level, and the app-level artifacts span both hash and lattice families. Forward-looking note: the declared protocol direction now spans both families, Falcon-512 (lattice) for account signatures and a hash-based XMSS-style scheme for consensus votes in the Quantumglow design, but neither is merged or deployed.

Ed25519 → 128-bit classical, 0 NIST-PQC category; BLS12-381 → ~128-bit classical, 0 NIST-PQC; SHA-256 → ~128-bit post-quantum (Grover-weaken). No NIST PQC scheme is mapped at protocol level. Falcon-512 (FN-DSA, NIST-selected July 2022, no draft or final FIPS published; NIST category 1 per its submission) reaches mainnet only through third-party app-level BPF verification; the client-side protocol implementations were closed unmerged in mid-2026. Winterwallet's W-OTS construction is a hash-based scheme outside the NIST PQC signature standards and carries no NIST category.

Ed25519 implementations in Agave (ed25519-dalek, Rust) and Firedancer (C/C++) are constant-time per upstream library convention; no machine-checked formal verification of validator-client signing path published; Keccak-256 syscall well-tested in production; BLS12-381 introduced via Alpenglow inherits standard production libraries; no published cryptanalytic-tier audit chain specific to Solana clients. Cryptanalytic maturity tier 1 (classical ECC + SHA-2). Deployed-verifier provenance for the app-level PQ path: the third-party SVM Falcon-512 verifier is cross-checked against NIST SHAKE-256 known-answer tests and one million PQClean-generated signatures with zero failures, but states in its own materials 'This crate is not audited' and is deliberately not constant-time (it operates on public data only); the deployed Winterwallet crate likewise states it is 'not formally audited (yet)' and uses a custom hardened-only HMAC-SHA512 derivation that its own documentation flags as not BIP-32 compatible. No reproducible-build or independent-audit evidence exists for either deployed artifact, so that component scores 0 with no punitive default.

100% of Solana accounts use the Ed25519 public key directly as the 32-byte address (no hash wrapper). Every account that has ever received or sent funds has its full public key on-chain by definition. There is no P2PKH-equivalent protection. Full TVL is post-Shor forgeable. Anza's technical post (re-published August 2026) names the fee-payer account as a distinct drain vector: vault-style programs cannot pay their own transaction fees under the current protocol, so any fee-payer account remains drainable by Ed25519 forgery even where funds sit behind an app-level PQ vault. The deployed ORE smart wallet illustrates the residue: transfers are authorized by an on-chain-verified Falcon-512 signature, but the enclosing transaction still carries an Ed25519 fee-payer signature on a classical keypair.

Same exposure profile as 2a, there is no architectural distinction between 'moved' and 'unmoved' coins; the public key is the address whether the account has signed once or never. Lost / dormant SOL is fully exposed.

Solana transactions are typically single-purpose authorizations rather than long-lived contractual artifacts. Historical signature replay does not create new spend authority because nonce/recent-blockhash binding expires. Long-term forgery risk concentrates on key-not-rotated accounts (very common) rather than on stored signatures.

Validator transaction ingestion runs over QUIC (TLS 1.3) using the rustls ring provider with key exchange restricted to X25519 only in the Agave tls-utils crypto provider (the source carries the comment 'Disable all key exchange algorithms except X25519'), so no X25519+ML-KEM (FIPS 203) hybrid group is offered; Turbine block propagation and gossip carry Ed25519-signed messages over UDP with no transport encryption documented; HTTPS RPC endpoints at major providers use standard classical TLS. No hybrid PQ KEM is declared anywhere in the validator stack or at major RPC endpoints. The mempool-equivalent ingestion path is public, so transport HNDL content is bounded. Scored down one point for an indefinitely retained on-chain ciphertext surface: Token-2022 confidential transfers encrypt amounts under twisted ElGamal over Curve25519, live and maintained in the current stable mainnet release line, so harvested confidential-transfer ciphertexts are decryptable once Shor breaks the curve, with no re-encryption or PQ migration plan published.

Pseudonymous, fully transparent. Every transaction, account, and program interaction is publicly readable from any RPC node or block explorer. No protocol-level shielding.

RPC layer is concentrated among a small number of commercial providers; Helius, QuickNode and Triton One are the named providers we checked. No public per-provider stake-weighted percentages are foundation-published and we found no source-backed market-share ranking. Mempool is observable via leader-schedule TPU forwarding (no encrypted mempool). Validator metadata retention policies are not protocol-mandated.

Wormhole, deBridge and Allbridge, the named bridges we checked, expose source-to-destination transactions in the clear. Passive observers can link cross-chain flows trivially because both sides are public.

Most Solana state is already pseudonymous-transparent, so for the bulk of activity a Shor break does not expose meaningfully more than is already public. The exception is confirmed live: the Token-2022 confidential transfer / confidential balances extension encrypts amounts under twisted ElGamal public-key encryption over Curve25519 (Pedersen-commitment based, per the crate documentation of the encryption library), and Token-2022 is deployed and executable on mainnet. The current stable mainnet release line still maintains the feature: Agave v4.2.0 (2026-08-07) shipped a correction to the parsed output for the confidential-transfer deposit and withdraw instructions. A discrete ElGamal pubkey registry program exists in the Token-2022 repository, though the program ID it declares is not present on mainnet, so the registry is an available component rather than a deployed one. Harvested confidential-transfer ciphertexts are retroactively decryptable once Shor breaks the curve, so users of that extension face genuine retroactive de-anonymization of amounts and balances. Scored down because the chain does hold on-chain encrypted state: the extension's live ElGamal encryption is retained indefinitely.

No protocol-level mixnet, shuffle, or commit-reveal at consensus. Application-layer privacy tooling such as Light Protocol compressed accounts sits outside consensus and does not score here for protocol-level credit.

Ed25519 is hard-coded in the protocol; adding a new signature type requires a SIMD + validator-client upgrade + feature gate. Alpenglow (SIMD-0326, merged 2025-09-09 after open review requiring approval from both client teams) demonstrates the chain can change consensus signatures (Ed25519 votes → BLS12-381 aggregates), establishing one production-track example of signature-scheme switch. No general-purpose signature-algorithm switch primitive at the account layer. Two merged prerequisites now exist: the larger-transaction-size and v1-transaction-format specs (SIMD-0296, SIMD-0385) both merged 2025-12-17, removing the size blocker for larger PQ signatures at the spec level (merge is not activation; no mainnet feature-gate activation of either is confirmed). An address-versioning proposal to index new post-quantum accounts by a hash of the public key rather than the raw key is published in Anza's technical post: proposed, not specced, not shipped.

Solana has no native account abstraction in the EIP-7702 sense: PDAs give program-controlled signing but not user-key rotation under a stable address, and a new scheme would need a new address format, so the account-model component is 5. The seed-rebind floor (6) applies because every standard Solana address is an RFC-8032 Ed25519 seed-derived key: Shor recovers the signing scalar but not the seed, so the holder can prove seed knowledge and rebind to a PQ key without moving funds, which a forger cannot do. Anza published a Solana-specific seed-rebind design with a merged prototype (a zero-knowledge proof of knowledge of the seed behind an Ed25519 keypair, built as a STARK over a custom SHA-512 arithmetization using the Plonky3 backend with the KoalaBear field, FRI, and Keccak-256 Merkle commitments, a hash-based and therefore post-quantum-sound proof system, 400,848-byte proof generated in ~55 ms and verified in ~13 ms, merged into the team's cryptography repository on 2026-04-08). The rebind bonus is nonetheless 0, not 2: that prototype's own pull request records under 'Current limitations' that it is an intentional temporary construction in which the link from the derived signing seed to the public key is enforced by an Ed25519 signature rather than in-circuit, the fully sound version (Ed25519 scalar multiplication inside the STARK) being impractical today. Under the 4b hard gate, a rebind whose authorization rests on an Ed25519 signature, itself forgeable by the same adversary the rebind is meant to defeat, and whose proof statement does not bind the new post-quantum key, forfeits the bonus regardless of prover maturity. Freeze maturity is independently 0: disabling legacy Ed25519 signing exists only as a stated precondition, with no spec, testnet or deployed path. 4b = min(20, max(6, 5) + 0) = 6. Dim 2 Forge exposure is unchanged: until a rebind confirms and legacy signing is frozen, every account stays fully forgeable.

Coordinated upgrades via feature gates and SIMDs in last 3 years; protocol changes ship as stake-weighted feature-gate activations bundled into versioned client releases rather than as discrete named fork events. History of network outages 2022-2023 is operational, not governance. Recent governance has been tractable: the Alpenglow core and migration specs both merged through the public improvement-document process.

The larger-transaction-size and v1-format specs (SIMD-0296, SIMD-0385, merged 2025-12-17) remove the size blocker for larger signatures at the spec level, though mainnet activation is not confirmed. No published hybrid-envelope spec: every protocol-level PQ effort to date proposed additive verification alongside Ed25519 (SIMD-0461 states it does not replace Ed25519 and 'provides an additional verification option'), never a classical+PQ composite requiring both, and the Quantumglow consensus design replaces rather than composes. At the app level the deployed ORE smart wallet pairs a standard Ed25519 fee-payer signature on the enclosing transaction with a Falcon-512 signature verified on-chain that alone authorizes transfers; this is a third-party program pattern, not a protocol hybrid composition, and the Ed25519 half remains a live forge surface for fees. Phantom and Ledger 'developer builds' with dual Ed25519 + Dilithium keypairs remain cited only in third-party coverage; direct checks of both vendors' public materials in August 2026 found no post-quantum content, so the claim stays unverified.

Falcon (announced account-level target) is stateless (full credit by default per v3.1 rule). The Winternitz constructions are stateful one-time schemes but app-level and out of consensus scope; the deployed Winterwallet library documents the one-time constraint explicitly and enforces position advancement in its keypair API. The Quantumglow design proposes a stateful XMSS-style scheme (Ax) for consensus votes with validators pre-exchanging one-time public keys; it is a research design with no implementation, so no state-management spec is yet required or scored, and 4e will come into scope if that design is merged.

Solana under Alpenglow (SIMD-0326, merged 2025-09-09; migration spec SIMD-0384 merged 2025-11-21) introduces BLS12-381 aggregate consensus signatures via Votor, bringing Solana into Dim 4 4f scope. Alpenglow is still not activated on mainnet (the foundation's July 2026 roundup reports the final feature flag for activation work merged; the stable Agave v4.2 line ships preparatory support; activation targets are announced, not shipped). Anza's research group published Quantumglow (2026-07-30; Alpenglow whitepaper v1.2, dated 2026-07-29, section 5 with formal definitions, proofs, and simulated finality latency), a declared PQ path that replaces the protocol's elliptic-curve signatures with a hash-based XMSS-style scheme named Ax, avoids signature aggregation entirely via a single-signer approval mechanic and local certificate pools, and replaces per-shred signatures with a block commitment plus symmetric authentication over authenticated channels, matching the hash-based and authenticated-channel path classes. The April 2026 technical post separately notes an un-aggregated fallback ('the raw votes can be contained in the block if needed') and Falcon as a candidate vote signature. No merged SIMD, prototype, or testnet exists for any of these, so this scores 5: declared with a published formal design, below the 10 reserved for a merged spec.

Mainnet PQC traffic is effectively 0% and is now measured rather than estimated. Two opt-in app-level programs are deployed and executable on mainnet under named PQ primitives: Winterwallet (Blueshift, hash-based W-OTS over truncated SHA-256; program winter5vMwvf51xrSVPTxbAAD6qiSTmPeRTSizMCQCa, last-deploy block time 2026-04-27) and the Vector Falcon-512 scheme program that authorizes the ORE smart wallet (program BoS6ho8tZU8iRLNi9VR8dYXihrsyNUMU7nvgiAChPesU, last-deploy block time 2026-05-29, and the ORE command-line repository was created the same day). A public-RPC signature enumeration on 2026-08-19 returns 13 lifetime transactions for the Winterwallet program (9 of them failed, first 2026-04-27, last 2026-07-28) and 23 for the Vector Falcon-512 program (6 failed, first 2026-05-29, last 2026-07-28): 36 transactions in total, 21 successful, and none in the 21 days to the scoring date. Under the 1,232-byte transaction limit the Winterwallet path provides 176 bits of post-quantum security per Blueshift's documentation, with a stated 256-bit level pending activation of the merged larger-transaction specs. The separate Solana Winternitz Vault (W-OTS over truncated Keccak-256, repository published January 2025) is not deployed at the program ID declared in its own source on mainnet, devnet or testnet, so it earns no traffic credit; a March 2026 arXiv resource-estimate paper cites that repository and groups it under experimental and test deployments. No protocol-level PQC traffic. Score 1 reflects primitives that are genuinely on mainnet and have executed, at negligible volume.

Zero PQC code is merged in any consensus client. The client-side Falcon paths were closed unmerged: the Falcon-512 verification syscall proposal (SIMD-0461, opened 2026-02-01, renamed from precompile to syscall 2026-02-06) was paused and closed 2026-06-17 with the stated reasoning that a third-party SBF Falcon implementation at under 170,000 compute units makes a syscall unnecessary and that it would 'reopen when there is more demand'; the Firedancer in-client Falcon implementation was closed unmerged 2026-07-08 ('Not going to need, as Falcon implemented as BPF program is viable'); the follow-up generic Keccak-p1600 accelerator syscall (SIMD-0563, opened 2026-06-15) was closed unmerged 2026-07-27; and the Agave-side implementation PR ('implement falcon from liboqs') remains open with no activity since 2026-02-01. The endorsed path, on-chain BPF-program verification, is app-level bytecode, not consensus-client code, so it earns no 5b credit.

0% of stake operates a PQC validator key. All validator votes are Ed25519 today; under Alpenglow, BLS12-381.

VOIDED per v3.1 because 5a is effectively 0. Beyond the void: no dated protocol milestones exist. The foundation's quantum-readiness post outlines a three-step plan with no dates and states 'No change is required today or likely anytime soon'; the one concrete protocol milestone path (the Falcon-512 verification syscall) was closed 2026-06-17 'for now', to reopen 'when there is more demand', with no date attached; the Quantumglow consensus design carries no dates; and neither the foundation page nor the re-published technical post reflects the closure.

Trailing-12-month announced items ≈ 5: the third-party ML-DSA (FIPS 204) verification press release (2025-10-23, an off-chain-proving / on-chain-proof-verification demonstration, network not stated, carrying an industry-first superlative we do not adopt); the foundation / Project Eleven post-quantum testnet partnership (2025-12-18, testnet, no scheme named); the two-client Falcon implementation effort (January 2026, since closed unmerged); the coordinated April 2026 quantum-readiness publications (foundation post, still live, undated and unrevised; Anza technical post, re-published 2026-08-12; Firedancer-team migration-paths post); and the Quantumglow consensus design (2026-07-30). Shipped and verifiable on-chain under the named primitive: 2 (Winterwallet, deployed 2026-04-27; Vector Falcon-512, deployed 2026-05-29). Ratio ≈ 5/2 = 2.5: above the 1.5 threshold, so the 10-point Dim 5 deduction applies, and above the 2.0 threshold, so the QRI-65 washing cap fires, non-binding. Washing-adjacent flags retained: the re-published technical post still presents the syscall proposal in the present tense two months after it was closed on the public record, and the foundation-facing quantum-readiness page describes the Winternitz vault as having 'been in place for over two years' when its repository was published in January 2025 and its declared program is absent from mainnet.

Ed25519 signatures are 64 bytes and public keys 32 bytes. Falcon-512 signatures are 666 bytes in the fixed-length encoding (~10× Ed25519) and Falcon-512 public keys are 897 bytes (~28× Ed25519 public key); the deployed SVM verifier stores a prepared public key at 1,024 bytes to save decode cost. ML-DSA-44 signatures are 2,420 bytes (~38× Ed25519) with 1,312-byte public keys per FIPS 204, and SLH-DSA-SHA2-128s signatures are 7,856 bytes (~123× Ed25519) with 32-byte public keys per FIPS 205. HAWK-512 signatures are 555 bytes per the deployed SVM scheme table. Reference falls into the 5-10× band for Falcon-only; 10-38× for ML-DSA. Score 10 (5-10× midband) anchored to the announced primary candidate Falcon-512. Third-party outlet figures for a testnet signature-size multiplier are not used: no source we could re-fetch names the scheme those figures were measured against. The Quantumglow consensus design avoids aggregation and shrinks vote signatures by pre-exchanging one-time public keys, but publishes no per-block byte figures, so it earns no credit here yet.

Named Solana wallets checked: Phantom, Solflare, Backpack. A direct check of Phantom's public blog and of Ledger's public education library in August 2026 found no post-quantum content, so the third-party 'developer builds with dual Ed25519 + Dilithium keypairs' claim stays unverified and earns no credit. Solflare and Backpack: no published PQC roadmap found. Outside those, ORE shipped a smart wallet authorized on-chain by Falcon-512 signatures (deployed 2026-05-29), an app-team artifact rather than a wallet-vendor roadmap, so it does not lift the tile.

Named bridges checked: Wormhole, deBridge, Allbridge. No published PQC roadmaps found from any. Bridge classical-ECDSA / Ed25519 signing is unchanged.

Named custodians with visible Solana flow: a tier-1 US exchange custodian, Fireblocks and BitGo. A direct check of Fireblocks' public blog listing in August 2026 surfaced no post-quantum custody article, so no post-quantum research-material credit is carried for that vendor rather than resting on an unreproducible citation; the tile now scores on the same basis as the bridge tile. No production PQC custody for Solana was found at any of the three, and no Solana-specific PQC roadmap was found.

Named RPC providers checked: Helius, QuickNode, Triton One, no PQC roadmaps found. HSM vendors (Ledger HSM, Thales) and TEE attestation chains used in MEV / oracle paths: no Solana-specific PQC declarations found. Ecosystem tooling exists below the vendor layer: one third-party team, Blueshift, ships PQC building blocks (Winterwallet and SVM verification libraries for Falcon-512 and HAWK-512, the Falcon-512 one self-described as not audited) that a wallet, custodian, or RPC vendor could adopt, but no named commercial vendor is found doing so, and tooling availability is not vendor readiness.

Measured directly from the mainnet-beta public RPC on 2026-08-19: 688 current vote accounts plus 8 delinquent, ~435.2M SOL activated stake, largest single validator 3.93% of stake, 41 validators needed to reach 50% of stake, and a Nakamoto coefficient of 18 (the minimum number of validators whose combined stake exceeds one third). This measurement supersedes a '≈20 per third-party trackers' figure; one public tracker reported 10 on the same date while returning an implausible value for another chain, so trackers are not relied on. Client diversity is real but thin and new: mainnet has run Agave, the Jito-Agave fork, and Frankendancer (Firedancer networking on the Agave runtime, with mainnet releases through 2025 and 2026), while the full Firedancer client's first mainnet-ready release is v1.1.3 on 2026-08-04, two weeks before this scoring date; the Firedancer v1.0.0 release of 2026-06-12 was labelled testnet. The Zig implementation Sig has no tagged release after v0.1.0 in May 2023 and we found no evidence of mainnet validator use, so it is not counted toward deployed diversity. We publish no per-client stake share: no source-backed measurement was found.

Recovered from 2022-2023 outages and executes feature gates routinely. Measured spec-to-activation cadence on the current flagship upgrade: Alpenglow's core and migration specs merged 2025-09-09 and 2025-11-21 through the public improvement-document process requiring approvals from both client teams, and activation had still not shipped in the stable release line as of 2026-08-19 (Agave v4.2.0 released 2026-08-07 and v4.2.1 on 2026-08-13 carry preparatory support; the foundation's July 2026 roundup reports the final feature flag for activation work merged; v4.3.0-beta.0 of 2026-08-14 carries ongoing vote and BLS signature-verification work; activation targets are announced, not shipped). That is roughly eleven months from merged spec to unactivated mainnet. The proposal pipeline itself is continuously active. We do not characterise the Alpenglow merge as a ratified stake-weighted referendum: that description appears in secondary coverage and we found no primary record of the vote.

Solana Foundation, Anza and the Firedancer team co-coordinate. The PQ coordination record is visible in public engineering channels: Anza engineers authored, paused, and closed the Falcon-512 syscall proposal with stated reasoning on the record; the Firedancer team closed its in-client implementation pointing to the same BPF path; Anza's bylined technical post (re-published 2026-08-12) is the current statement of account-level direction; and Anza's research group published the Quantumglow consensus design on 2026-07-30. The foundation-facing quantum-readiness page is out of sync with that record, carrying no date or byline and no mention of the syscall proposal, its closure, Alpenglow, or the deployed app-level artifacts. No single named PQC working-group lead with a published mandate exists.

Post-FTX recovery (2022) and validator-coordination across multiple outages demonstrate pressure-response. No PQC-specific adversarial coordination test.

No published canary, honeypot, or rate-limited spending rule for quantum compromise. The Project Eleven Q-Day prize is an industry-wide bounty, not a Solana-embedded tripwire.