{
  "id": "solana",
  "name": "Solana",
  "type": "Monolithic L1",
  "reviewed": "2026-07-03",
  "summary": "Solana's mainnet-beta default is overwhelmingly quantum-vulnerable: account signing, transaction verification, TowerBFT consensus votes, node identity, and P2P transport all rest on Ed25519 over Curve25519 — a Shor-breakable elliptic-curve scheme — and a base Solana address IS the raw 32-byte Ed25519 public key, so there is no hash-hiding margin protecting exposed keys. The only quantum-safe surfaces are hash-based: Proof of History (a sequential SHA-256 chain), the SHA-256/BLAKE3 state commitment, and the crypto-free SBF/BPF VM. The hash-based Winternitz Vault (WOTS) exists but is an opt-in third-party program with single-use keys that cannot pay its own transaction fees, so it fails the election route at E6 — the canonical E6 boundary case. Alpenglow will move votes to BLS12-381 aggregate signatures, but it is not live on mainnet (community test cluster since May 2026) and BLS is Shor-breakable regardless. Confidential SPL Token-2022 balances use twisted ElGamal + Bulletproofs over Curve25519, exposed to harvest-now-decrypt-later. Verified against primary sources — pinned Agave / solana-sdk source, official SIMDs, and Anza docs (July 2026).",
  "links": {
    "Docs (Solana)": "https://solana.com/docs",
    "Docs (Anza / Agave)": "https://docs.anza.xyz",
    "Agave client": "https://github.com/anza-xyz/agave",
    "solana-sdk": "https://github.com/anza-xyz/solana-sdk",
    "SIMDs": "https://github.com/solana-foundation/solana-improvement-documents"
  },
  "assessment": {
    "1.1": { "verdict": "fail", "scheme": "Ed25519 (Curve25519) — address is the raw public key", "why": "A Solana Keypair is a thin wrapper around ed25519_dalek and the account address (Pubkey/Address) is the raw 32-byte Ed25519 public key with no hashing applied — so the full public key is on-chain with no hash-hiding margin. Ed25519 rests on the elliptic-curve discrete log, broken by Shor. The only quantum-safe alternative, the Winternitz Vault (hash-based WOTS), fails the election route at E6: its keys are single-use (each spend reveals ~50% of the private key, forcing close-and-reopen), it is a standalone opt-in third-party program, and it cannot serve as a persistent fee-paying account — the enclosing transaction must still be signed and fee-paid by an Ed25519 key. It also fails E4 (no generally available wallet integration).", "sources": ["https://github.com/anza-xyz/solana-sdk/blob/sdk@v2.2.2/keypair/src/lib.rs", "https://solana.com/docs/core/accounts", "https://github.com/deanmlittle/solana-winternitz-vault"] },
    "1.2": { "verdict": "fail", "scheme": "Ed25519 private keys", "why": "Wallets and custody solutions store the same Shor-breakable Ed25519 private keys; there is no post-quantum key type in the default account model.", "sources": ["https://github.com/anza-xyz/solana-sdk/blob/sdk@v2.2.2/keypair/src/lib.rs"] },
    "1.3": { "verdict": "fail", "scheme": "Ed25519 multisig / MPC (e.g. Squads)", "why": "On-chain multisig and MPC/threshold signers (e.g. Squads) ultimately produce and verify Ed25519 signatures — the same Shor-breakable primitive as a single-key account.", "sources": ["https://github.com/anza-xyz/agave/blob/master/perf/src/sigverify.rs"] },
    "1.4": { "verdict": "na", "scheme": "", "why": "Solana has no protocol-native account-abstraction / smart-account signature layer: the runtime verifies a fixed set of Ed25519 (and secp256k1/secp256r1 precompile) transaction signatures, and programs cannot install an arbitrary signature verifier as the account's transaction-authorization scheme. There is therefore no per-account abstraction surface to score." },
    "1.5": { "verdict": "na", "scheme": "", "why": "Solana has no protocol-level passkey or session-key standard; delegated/session authority is an application-layer pattern, not a core protocol component." },
    "1.6": { "verdict": "na", "scheme": "", "why": "Human-readable naming (the Solana Name Service, .sol) is an application-layer program, not a protocol-native identity component." },
    "1.7": { "verdict": "na", "scheme": "", "why": "On-chain governance (Realms / SPL Governance) is an application-layer program, not part of the base protocol; there is no protocol-level coin-holder-vote signature scheme to break." },
    "2.1": { "verdict": "fail", "scheme": "ed25519 + secp256k1 + secp256r1 native verify programs", "why": "Solana's native signature-verification programs (ed25519, secp256k1, secp256r1) that on-chain programs use to check signatures all verify Shor-breakable elliptic-curve schemes. A post-quantum path has only reached demo / proof-of-concept stage — BTQ Technologies and Bonsol Labs demonstrated ML-DSA (FIPS 204) verification via off-chain proving with on-chain proof checking (Oct 2025), and Agave carries a proof-of-concept ML-DSA precompile/syscall — but neither is audited or live on mainnet, so this fails the election route at E3 (demo/PoC only, not production).", "sources": ["https://github.com/anza-xyz/agave/blob/master/perf/src/sigverify.rs", "https://github.com/anza-xyz/solana-sdk", "https://www.prnewswire.com/news-releases/btq-technologies-partners-with-bonsol-labs-to-achieve-industry-first-nist-standardized-post-quantum-cryptography-signature-verification-on-solana-302592494.html", "https://blog.anagram.xyz/taking-solana-post-quantum/"] },
    "2.2": { "verdict": "fail", "scheme": "Native ZK ElGamal Proof Program + alt_bn128 (BN254) pairings", "why": "Solana has a native, built-in ZK ElGamal Proof Program (SIMD-0153, at ZkE1Gama1Proof11111111111111111111111111111) that verifies zero-knowledge proofs over twisted ElGamal ciphertexts and Pedersen commitments (range/equality/zero-balance) — all EC-discrete-log over Curve25519 — plus alt_bn128 / BN254 pairing syscalls used for on-chain Groth16 verification (e.g. ZK compression / Light Protocol). Both are Shor-breakable. (The ZK ElGamal Proof Program was feature-gated off on mainnet after a June 2025 soundness bug pending re-audit, but it is architecturally native and the crypto is unambiguously breakable.)", "sources": ["https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0153-elgamal-proof-program.md", "https://docs.anza.xyz/runtime/zk-elgamal-proof"] },
    "2.3": { "verdict": "fail", "scheme": "Operator-signed oracle feeds (Ed25519)", "why": "On-chain oracle feeds (e.g. Pyth) authenticate their updates with classical Ed25519 signatures verified through the same Shor-breakable path as ordinary transactions.", "sources": ["https://github.com/anza-xyz/agave/blob/master/perf/src/sigverify.rs"] },
    "2.4": { "verdict": "na", "scheme": "", "why": "Solana has no protocol-native verifiable randomness / beacon; on-chain VRF is provided by application-layer services (Switchboard, ORAO) that are scored against their operators, not the base protocol." },
    "2.5": { "verdict": "pass", "scheme": "Proof of History (sequential SHA-256 chain)", "why": "Solana's time-based ordering primitive, Proof of History, is a sequential SHA-256 pre-image hash chain, not a group-based verifiable delay function. Hashing is only weakened by Grover (quadratic, not exponential), so a 256-bit hash chain retains ~128-bit security and is not exposed to Shor — this is a genuine quantum-safe component. (The block producer's authority to extend the chain is an Ed25519 signature, scored separately under 3.1.)", "sources": ["https://docs.anza.xyz/consensus/synchronization"] },
    "3.1": { "verdict": "fail", "scheme": "Ed25519 leader/shred signatures (not PoW)", "why": "Sequencing is not hash-based Nakamoto ordering: on mainnet the slot leader signs blocks and shreds with an Ed25519 validator key, and vote transactions share the identical Ed25519 verification path as ordinary transactions (merely flagged SIMPLE_VOTE_TX). Proof of History orders events but the leader's authority to produce them is a Shor-breakable signature, so this is a signature-based FAIL, not a PoW pass.", "sources": ["https://github.com/anza-xyz/agave/blob/master/perf/src/sigverify.rs", "https://www.simd.watch/simd/0387/page"] },
    "3.2": { "verdict": "na", "scheme": "", "why": "Solana is a monolithic L1 that validates state transitions by validator re-execution (replay), not by a succinct validity proof, so there is no proof system to score." },
    "3.3": { "verdict": "na", "scheme": "", "why": "Solana uses no trusted setup." },
    "3.4": { "verdict": "na", "scheme": "", "why": "Data availability is internal to the protocol (Turbine block propagation with erasure coding), not a commitment posted to a separate base layer, so there is no external DA commitment to score." },
    "3.5": { "verdict": "pass", "scheme": "SHA-256 bank hash / BLAKE3 accounts hash", "why": "Solana's state is committed by hash digests — the SHA-256 bank hash and the BLAKE3 accounts-lattice-hash — not by an elliptic-curve commitment. Hashing is only Grover-weakened, so 256-bit state roots stay quantum-safe.", "sources": ["https://docs.anza.xyz/runtime/programs"] },
    "3.6": { "verdict": "pass", "scheme": "SBF / BPF VM", "why": "The Solana SBF/BPF virtual machine is a bytecode interpreter that carries no cryptography of its own; all crypto is exposed through separate syscalls/precompiles scored elsewhere.", "sources": ["https://docs.anza.xyz"] },
    "4.1": { "verdict": "fail", "scheme": "Ed25519 TowerBFT votes (Alpenglow → BLS12-381)", "why": "TowerBFT consensus votes are signed with Ed25519 validator keys on mainnet today — Shor-breakable. Alpenglow (SIMD-0326/0387) would replace these with BLS12-381 aggregate signatures, but it is not live on mainnet (governance-approved Sept 2025, community test cluster since May 2026, mainnet targeted late 2026) and BLS12-381 is itself pairing-based and Shor-breakable — so consensus fails either way.", "sources": ["https://github.com/anza-xyz/agave/blob/master/perf/src/sigverify.rs", "https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md"] },
    "4.2": { "verdict": "fail", "scheme": "Ed25519 validator-signature verification", "why": "Solana has no succinct or post-quantum light client; a light client establishes trust by verifying validator vote/identity Ed25519 signatures — Shor-breakable.", "sources": ["https://github.com/anza-xyz/agave/blob/master/perf/src/sigverify.rs"] },
    "4.3": { "verdict": "na", "scheme": "", "why": "Solana is a base L1; it does not anchor its state to a separate settlement chain." },
    "4.4": { "verdict": "na", "scheme": "", "why": "Solana has no in-protocol canonical bridge; cross-chain bridges (Wormhole and others) are third-party operator-run programs, scored against their operators rather than the chain." },
    "4.5": { "verdict": "na", "scheme": "", "why": "Restaking / AVS attestation (Solayer, Jito restaking) is an application-layer/emerging feature, not part of the core protocol." },
    "4.6": { "verdict": "na", "scheme": "", "why": "Payment channels / conditional transfers are not part of Solana's core protocol." },
    "4.7": { "verdict": "na", "scheme": "", "why": "Solana has no in-protocol proposer-builder separation / relay market; the Jito block engine is off-chain application-layer infrastructure, not protocol-native PBS." },
    "5.1": { "verdict": "fail", "scheme": "QUIC/TLS + gossip (classical EC key exchange)", "why": "Node-to-node transport uses QUIC/TLS and a gossip protocol built on classical elliptic-curve key exchange and Ed25519 node keys — Shor-breakable, with no PQ/hybrid deployment.", "sources": ["https://github.com/anza-xyz/agave/blob/master/perf/src/sigverify.rs"] },
    "5.2": { "verdict": "fail", "scheme": "Ed25519 node identity keys", "why": "A Solana validator's node identity is an Ed25519 keypair — Shor-breakable.", "sources": ["https://github.com/anza-xyz/solana-sdk"] },
    "5.3": { "verdict": "fail", "scheme": "Classical TLS", "why": "RPC / API connections use classical TLS with elliptic-curve key exchange.", "sources": ["https://docs.anza.xyz"] },
    "5.4": { "verdict": "na", "scheme": "", "why": "Solana has no deployed protocol-level stealth-address or on-chain key-agreement (ECDH) standard." },
    "5.5": { "verdict": "fail", "scheme": "Twisted ElGamal + Bulletproofs over Curve25519", "why": "SPL Token-2022 confidential balances use twisted ElGamal public-key encryption over Curve25519 (each transfer carries sender/receiver/auditor ElGamal public keys), with sigma-protocol and Bulletproofs range proofs — all EC-discrete-log over Curve25519 and Shor-breakable. Harvest-now-decrypt-later applies to any encrypted balances.", "sources": ["https://www.solana-program.com/docs/confidential-balances/zkps", "https://docs.anza.xyz/runtime/zk-elgamal-proof"] }
  }
}