Solana SOL

Claim: Solana has published comprehensive cryptographic inventories and quantum threat models covering Ed25519 accounts, BLS12-381 consensus (Alpenglow), Turbine shred authentication, and user-defined programs.

Coverage basis: Official developer publications from Anza, Jump Crypto, and Solana Foundation (April 2026)

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Multiple primary sources from core development teams confirm the inventory. Threat model covers all four identified ECC-dependent layers with specific algorithm references.

Inventory covers Ed25519 (accounts/transactions), BLS12-381 (Alpenglow consensus), Ed25519 (Turbine shreds), and user-defined program syscalls. Explicitly acknowledges quantum vulnerability of each layer.

• https://www.anza.xyz/blog/securing-solana-against-a-powerful-quantum-adversary
• https://jumpcrypto.com/resources/quantum-migration-paths-for-solana
• https://jumpcrypto.com/a-post-quantum-migration-path-for-solana
• https://solana.com/news/quantum-readiness

Claim: Assessment is supported by code references, specifications, prototype PRs, testnet evidence, and mainnet documentation.

Coverage basis: Source code repositories, SIMD proposals, prototype implementations, official documentation

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Primary source code and specification evidence is publicly accessible. Prototype Falcon implementations exist as open draft PRs. Project Eleven testnet deployment provides reproducible evidence of PQ transaction viability.

Evidence record is comprehensive and draws from multiple independent sources (Anza, Jump Crypto/Firedancer, Solana Foundation, Blueshift, Project Eleven). All claims are traceable to primary artifacts.

• https://github.com/anza-xyz/solana-sdk/pull/537
• https://github.com/firedancer-io/firedancer/pull/9446
• https://github.com/solana-foundation/solana-improvement-documents/pull/461
• https://github.com/solana-foundation/solana-improvement-documents/pull/296
• https://anza.xyz/the-post-quantum-solana-checklist
• https://solana.com/docs/core/programs/precompiles
• https://projecteleven.com/solana-foundation-collaboration

Claim: Solana mainnet uses Ed25519 precompile for all native transaction signature verification. Falcon is prototype only. Winternitz Vault is opt-in application-layer only.

Coverage basis: Protocol-level signature verification mechanism

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Active production spend authorization remains entirely Ed25519-only. Ed25519 is broken by Shor's algorithm. All native transaction signatures verified via the Ed25519 precompile. No PQ replacement exists at protocol level.

Assurance: Confirmed by official Solana documentation, Anza engineering blog, and Jump Crypto analysis. Ed25519 precompile is documented as the native signature verification mechanism. Falcon PRs are explicitly described as draft/prototype by their authors.

The Winternitz Vault is a smart-contract-level program that users can optionally deposit into. It does not replace or modify the protocol's Ed25519 precompile. Native transaction signing remains Ed25519-only. Fee payer accounts must use Ed25519 — Winternitz Vault cannot pay transaction fees directly.

• https://solana.com/docs/core/programs/precompiles
• https://www.anza.xyz/blog/securing-solana-against-a-powerful-quantum-adversary
• https://github.com/anza-xyz/solana-sdk/pull/537

Claim: Accounts are indexed by Ed25519 public keys exposing them long-term. SHA-512 seed derivation provides partial quantum resistance. PDAs are inherently quantum-resistant via SHA-256.

Coverage basis: Account model, key derivation, and address scheme

Implementation score: 0.25 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Ed25519 public keys are permanently exposed on-chain as account addresses, creating long-exposure attack surface for all accounts.

Assurance: Multiple primary sources confirm the Ed25519-based account model and SHA-512 seed derivation. PDA quantum resistance is a well-understood property of hash-based derivation.

SHA-512 seed derivation is a genuine architectural advantage: the seed material remains quantum-resistant even after Ed25519 is broken, enabling post-Q-day migration via ZK proofs. PDAs use SHA-256 and are off-curve by construction — no associated private key exists. However, the vast majority of user accounts use standard Ed25519 keypairs with fully exposed public keys.

• https://www.anza.xyz/blog/securing-solana-against-a-powerful-quantum-adversary
• https://helius.dev/blog/solana-post-quantum-cryptography
• https://jumpcrypto.com/a-post-quantum-migration-path-for-solana

Claim: Current TowerBFT uses Ed25519 validator vote signatures. Planned Alpenglow consensus uses BLS12-381. Both are quantum-vulnerable. No PQ consensus authentication exists.

Coverage basis: Validator vote signatures in TowerBFT and Alpenglow consensus protocols

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Consensus authentication is quantum-vulnerable in both current TowerBFT (Ed25519) and planned Alpenglow (BLS12-381). No PQ consensus mechanism exists in any production or planned protocol version.

Assurance: TowerBFT documentation confirms Ed25519 vote signatures. SIMD-0326 (Alpenglow) and SIMD-0387 (BLS pubkey management) confirm BLS12-381 for Alpenglow consensus votes. Anza blog acknowledges research into lattice-based multi-signatures for PQ consensus is ongoing but not implemented.

Alpenglow is in community testnet (May 2026), not mainnet. Mainnet activation expected late 2026. Alpenglow's BLS12-381 aggregate signatures are also broken by Shor's algorithm. The Anza blog explicitly acknowledges this and mentions research into PQ alternatives (lattice-based multi-signatures, PQ-SNARK-based aggregation) but none are implemented or specified in any SIMD.

• https://docs.anza.xyz/implemented-proposals/tower-bft
• https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md
• https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0387-bls-pubkey-management-in-vote-account.md
• https://www.anza.xyz/blog/securing-solana-against-a-powerful-quantum-adversary

Claim: Core state integrity relies on SHA-256/Keccak hashing (Accounts Lattice Hash, PDAs). No pairing-based or KZG commitments used at protocol level for state integrity.

Coverage basis: Protocol-level state hashing and commitment schemes

Implementation score: 0.75 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Hash-based state integrity is well-understood. SHA-256 second preimage resistance against Grover's algorithm provides ~128-bit security, which is adequate. PDAs are off-curve by construction. The BLS12-381 syscall (SIMD-0388) is for user programs, not protocol state integrity. No independent audit of state-integrity mechanisms specifically for quantum resistance.

Solana's core state integrity is predominantly hash-based (SHA-256, Keccak). PDAs use SHA-256 and are not associated with any private key. The Accounts Lattice Hash uses homomorphic hashing, not pairing-based commitments. The alt_bn128 and proposed BLS12-381 syscalls are for user programs, not protocol state integrity. This gives Solana a structural advantage for state integrity compared to chains using KZG commitments or pairing-based state verification. However, some edge cases around account state binding and historical state commitments have not been systematically reviewed for quantum safety.

• https://helius.dev/blog/solana-post-quantum-cryptography
• https://docs.anza.xyz/implemented-proposals/tower-bft
• https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0388-bls12-381-syscalls.md

Claim: Token22 confidential transfers use ZK ElGamal Proof program based on ElGamal encryption and Pedersen commitments — both rely on discrete logarithm assumptions and are quantum-vulnerable.

Coverage basis: Optional Token22 confidential transfer extension

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Code4rena audit (Aug-Sep 2025) covered the ZK ElGamal Proof program and Token22 confidential transfer logic. Audit scope did not include quantum threat assessment. The underlying cryptographic assumptions (discrete logarithm) are quantum-vulnerable by design.

Confidential transfers are an optional Token22 extension, not a mandatory protocol feature. The ZK proof system uses Sigma protocols over ElGamal/Pedersen — these are broken by Shor's algorithm. However, this vulnerability only affects users who opt into confidential transfers. The core protocol does not depend on these proof systems for security.

• https://github.com/code-423n4/2025-08-solana-foundation
• https://github.com/anza-xyz/agave/tree/afed4fcf3a79e115e12e202640b9b7bd36ce9e8b/programs/zk-elgamal-proof

Claim: Turbine shred authentication uses Ed25519 signatures. Node identity is Ed25519-based. Stake-weighted QoS relies on Ed25519 signatures.

Coverage basis: P2P networking layer and validator identity

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Anza blog explicitly identifies Turbine shred authentication and stake-weighted QoS as quantum-vulnerable layers relying on Ed25519. No PQ alternatives proposed for P2P layer.

P2P vulnerabilities affect network availability (DoS via forged shreds) rather than asset theft or consensus safety directly. The Anza blog notes XDP could help offset throughput loss from larger PQ signatures. However, no concrete PQ P2P design exists.

• https://www.anza.xyz/blog/securing-solana-against-a-powerful-quantum-adversary
• https://docs.anza.xyz/implemented-proposals/tower-bft

Claim: Blueshift Winternitz Vault / Winterwallet provides opt-in PQ wallet support on mainnet using Winternitz One-Time Signatures.

Coverage basis: Opt-in application-layer custody solution

Implementation score: 0.75 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Winternitz Vault is open-source (MIT) and cited by Google Quantum AI. However, the author's README includes a candid disclaimer: 'I am a pretty good dev larping as a cryptographer.' No independent cryptographic audit. Adoption is fewer than 300 accounts on mainnet-beta as of April 2026. Winterwallet provides production tooling (SDK, CLI, on-chain program) but remains opt-in with no default integration in major wallets.

Winternitz Vault is the only Solana-specific PQC solution cited by Google's quantum whitepaper. It provides 176-bit post-quantum security (truncated SHA-256) within current 1,232-byte transaction limits. However, it cannot pay transaction fees directly — fee payer accounts must still use Ed25519. Each vault is single-use by design (WOTS constraint). This is meaningful opt-in protection but does not protect the base protocol or users who haven't actively migrated.

• https://blueshift.gg/ensuring-solanas-quantum-security
• https://blueshift.gg/research/quantum-proofing-solana
• https://github.com/blueshift-gg/solana-winternitz-vault
• https://docs.rs/winterwallet-core/latest/winterwallet_core/

Claim: Almost no SOL or SPL token value is protected by PQ mechanisms. Winternitz Vault adoption is negligible relative to total circulating supply and DeFi TVL.

Coverage basis: Estimated value protection across all on-chain assets

Implementation score: 0.05 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Far below 25% of economically relevant value is protected. Almost all SOL (~$97 USD per token, 167M token-holder addresses, $2.5B+ in tokenized RWAs) remains in Ed25519 accounts with fully exposed public keys.

Assurance: No public data on Winternitz Vault TVL or adoption. The Solana ecosystem roundup (April 2026) mentions $2.5B in tokenized RWAs and 167M token-holder addresses but no PQ-protected value figures. Winternitz Vault has fewer than 300 accounts on mainnet-beta as of April 2026.

All SOL in standard Ed25519 accounts, all SPL tokens, all DeFi TVL, all staked SOL, all program treasuries, and all protocol-controlled value remain quantum-vulnerable. The $2.5B in tokenized RWAs on Solana represents long-exposure value at extreme quantum risk. Coverage is estimated at well under 1% of total value-at-risk.

• https://blockchain.news/news/solana-record-167m-token-holders-april-2026
• https://solana.com/news/solana-ecosystem-roundup-april-2026

Claim: No evidence that any major treasury, exchange, foundation, or protocol wallet has migrated to PQ protection.

Coverage basis: Critical infrastructure wallets

Implementation score: 0 · Evidence confidence: Low

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: No public attestations from exchanges, custodians, foundations, or major protocols confirming PQ migration. Blueshift encourages migration of signing authorities to Winterwallet but provides no data on adoption. This is a quantum-critical uncertainty because critical infrastructure wallets controlling billions in value may remain entirely unprotected.

The Blueshift research article explicitly identifies program upgrade authorities, token mint authorities, and multisig signers as 'the most consequential near-term quantum vulnerability on Solana' and notes 'the only remaining barrier is adoption.' This confirms that critical wallets have not meaningfully migrated.

Claim: Vulnerable surfaces are identified in assessments but no production measurement, deprecation, or migration system exists.

Coverage basis: Identification and management of legacy vulnerable accounts

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: The assessments identify the vulnerable account model but do not provide live measurement, dashboards, or tools for tracking migration progress. No deprecation, freeze, or migration mechanism is active on mainnet.

The Anza and Jump Crypto assessments provide thorough theoretical identification of vulnerable layers. The migration proof prototype (~400kB, 55ms) demonstrates technical feasibility. However, there is no production system for measuring vulnerable value, prompting migration, or enforcing deprecation of legacy Ed25519 accounts.

• https://www.anza.xyz/blog/securing-solana-against-a-powerful-quantum-adversary
• https://jumpcrypto.com/resources/quantum-migration-paths-for-solana

Claim: Comprehensive public roadmaps exist with specific SIMD proposals, sequencing, and dependencies.

Coverage basis: Published migration roadmaps and SIMD proposals

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Multiple independently published roadmaps from Anza, Jump Crypto, and Solana Foundation converge on the same strategy: Falcon-512, larger transactions (SIMD-0296/0385), Falcon syscall (SIMD-0461), address versioning, and SHA-512 seed-based ZK migration. Dependencies between SIMDs are documented.

The roadmap is unusually detailed for a blockchain project. It covers transaction size prerequisites, signature scheme selection rationale, account model migration, consensus considerations, and emergency migration paths. However, it is still a roadmap — none of the critical SIMDs are activated on mainnet.

• https://jumpcrypto.com/a-post-quantum-migration-path-for-solana
• https://anza.xyz/the-post-quantum-solana-checklist
• https://solana.com/news/quantum-readiness
• https://www.anza.xyz/blog/securing-solana-against-a-powerful-quantum-adversary

Claim: No default PQ account creation. Winternitz Vault is opt-in only. No migration prompts in standard wallets. SIMD prerequisites not yet active.

Coverage basis: User-facing migration tooling and defaults

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: Winternitz Vault/Winterwallet exists as opt-in tooling with SDK, CLI, and on-chain program. No major wallet (Phantom, Solflare, Backpack) integrates PQ account creation or migration prompts. SIMD-0296 (larger transactions) is accepted but not activated. SIMD-0461 (Falcon syscall) is still an open PR without full approval.

Winterwallet is the only available migration tool and requires intentional user action. There are no warnings, prompts, or incentives for users to migrate. The one-time-use constraint of WOTS adds UX friction. Standard wallet interfaces provide no quantum-related information to users.

• https://blueshift.gg/ensuring-solanas-quantum-security
• https://github.com/solana-foundation/solana-improvement-documents/pull/296
• https://github.com/solana-foundation/solana-improvement-documents/pull/461

Claim: No enforcement mechanisms exist. No Ed25519 deprecation, freeze, restricted withdrawals, or mandatory migration deadlines. Exchange coordination is at discussion stage.

Coverage basis: Enforcement mechanisms and ecosystem coordination

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Users can still create new quantum-vulnerable Ed25519 accounts by default with no warnings, restrictions, or deprecation timeline. No enforcement mechanism prevents continued use of quantum-vulnerable accounts.

Assurance: The official Solana Foundation statement explicitly says 'no protocol change required today.' Anza blog discusses future deprecation as a design consideration, not an active plan. No exchange, custody, or infrastructure coordination for quantum migration is evidenced.

The lack of enforcement is appropriate given that PQ protection is not yet available at protocol level. However, it means there is currently no mechanism to prevent or discourage creation of new quantum-vulnerable accounts, and no framework for coordinated migration when PQ becomes available.

• https://www.anza.xyz/blog/securing-solana-against-a-powerful-quantum-adversary
• https://solana.com/news/quantum-readiness

Claim: General security programs (STRIDE, SIRN) exist but no formal quantum-specific incident-response playbook is documented.

Coverage basis: Quantum-specific incident response and governance

Implementation score: 0.25 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: STRIDE (Solana Trust, Resilience and Infrastructure for DeFi Enterprises) and SIRN (Solana Incident Response Network) exist as general security programs. The Anza blog discusses quantum-specific threat assessment and emergency migration paths (network halt, Ed25519 disable, Falcon enable, ZK seed-proof migration) but this is a conceptual design, not a formal playbook with defined roles, triggers, and procedures.

Per QRI v3.1 Note-Only Caveat Rule: the absence of a formal quantum-specific IR playbook is treated as an assurance-only caveat. The underlying migration design (SHA-512 seed + ZK proof) provides a credible technical recovery path. The lack of formal process documentation does not itself create a quantum-vulnerable path.

• https://solana.com/news/solana-ecosystem-roundup-april-2026
• https://www.anza.xyz/blog/securing-solana-against-a-powerful-quantum-adversary

Claim: Falcon-512 (FN-DSA) is the leading candidate — a NIST draft standard (FIPS 206). Winternitz OTS is a well-known hash-based construction. Dilithium and SPHINCS+ are also under consideration.

Coverage basis: Algorithm selection for planned PQ migration

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Falcon-512 is a NIST draft standard (FIPS 206), not yet finalized. Winternitz OTS is a well-understood hash-based construction but not NIST-standardized. The project explicitly considers alternatives (Dilithium, SPHINCS+, SQIsign) and acknowledges the evolving PQC landscape. However, no algorithm is in production use at protocol level — all remain at prototype/research stage.

Falcon-512's compact signatures (~666 bytes) and fast verification (~5μs) make it well-suited for Solana's bandwidth-sensitive architecture. The SIMD-0461 discussion includes a thoughtful comparison of Falcon vs. Dilithium vs. SPHINCS+ tradeoffs. Score of 0.50 reflects prototype implementation status.

• https://www.anza.xyz/blog/securing-solana-against-a-powerful-quantum-adversary
• https://jumpcrypto.com/resources/quantum-migration-paths-for-solana
• https://github.com/solana-foundation/solana-improvement-documents/pull/461

Claim: No independent cryptographic audit of Falcon implementation, Winternitz Vault, or any quantum-critical component exists.

Coverage basis: Independent audit of PQ implementations

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: The Code4rena audit (Aug-Sep 2025) covered Token22 confidential transfers only — scope-mismatched for quantum-critical assessment. The Winternitz Vault README contains a candid disclaimer from its author questioning their own cryptographic expertise. Falcon implementations are draft PRs not yet ready for audit. Per QRI v3.1: audit absence reduces Implementation Score for algorithm assurance because the PQ implementation cannot be verified as cryptographically sound.

This is scored as 0.00 because no audit exists for any quantum-critical implementation. The score treatment is 'score-reducing' within the Algorithm & Implementation Assurance category (affects the category score), not a Readiness & Risk Cap. The lack of audit is most concerning for the Winternitz Vault, which is live on mainnet protecting real (though minimal) user funds.

• https://github.com/blueshift-gg/solana-winternitz-vault
• https://github.com/anza-xyz/solana-sdk/pull/537

Claim: All PQ work is open source: Falcon PRs (Anza, Firedancer), Winternitz Vault (MIT), Winterwallet SDK.

Coverage basis: Source code availability and reproducibility

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: All PQ codebases are publicly accessible with permissive licenses (MIT, Apache 2.0). Falcon implementations use liboqs. Winternitz Vault and Winterwallet are fully open source. Code can be independently reviewed and reproduced.

Open-source availability is a strength. The Winternitz Vault is MIT-licensed and the Winterwallet SDK is published on crates.io. Falcon PRs reference the standard liboqs library. Project Eleven's testnet deployment provides additional reproducibility evidence.

• https://github.com/anza-xyz/solana-sdk/pull/537
• https://github.com/firedancer-io/firedancer/pull/9446
• https://github.com/blueshift-gg/solana-winternitz-vault
• https://docs.rs/winterwallet-core/latest/winterwallet_core/

Claim: Anza blog explicitly discusses the evolving PQC landscape and migration design allows algorithm changes. SIMD proposals are modular.

Coverage basis: Documented algorithm agility and upgrade planning

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: The Anza blog explicitly discusses SQIsign as a future possibility with smaller signatures than Falcon, and notes 'the post-quantum cryptography landscape is still evolving rapidly.' SIMD proposals are designed as modular components (separate SIMDs for transaction size, Falcon syscall, consensus changes). The SHA-512 seed migration path is algorithm-agnostic.

Parameter agility is well-considered. The migration design binds a PQ public key to an existing Ed25519 address via seed proof, allowing the PQ algorithm to change without requiring re-migration. The SIMD process provides a governance mechanism for algorithm selection and activation.

• https://www.anza.xyz/blog/securing-solana-against-a-powerful-quantum-adversary
• https://github.com/solana-foundation/solana-improvement-documents/pull/461

Claim: Winternitz Vault handles one-time signature constraint automatically. Falcon implementation considerations documented. No formal side-channel analysis or HSM integration.

Coverage basis: Implementation safety for stateful and side-channel considerations

Implementation score: 0.25 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: The Winternitz Vault handles WOTS one-time constraint by closing and opening new vaults with each spend. The Winterwallet SDK includes position-advancement enforcement. The vault README warns about reuse risks. However, no formal side-channel analysis exists for the Falcon or Winternitz implementations. No HSM or hardware-wallet integration exists for any PQ scheme. Falcon's floating-point implementation raises unique side-channel concerns not addressed in current documentation.

Stateful-signature safety is handled at the application level for Winternitz. Falcon does not have stateful-signature concerns (unlike XMSS/LMS). However, Falcon's floating-point implementation presents side-channel risks (timing, power analysis) that are acknowledged in the academic literature but not addressed in Solana's implementation documentation. This is scored as a note-only caveat because the current production scope has no PQ spend authorization — these risks would become material only when PQ signatures are in production use.

• https://github.com/blueshift-gg/solana-winternitz-vault
• https://docs.rs/winterwallet-core/latest/winterwallet_core/

Claim: Preliminary performance analysis exists for Falcon signature sizes, verification costs, and transaction size requirements.

Coverage basis: Performance analysis of PQ algorithms in Solana context

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: operational/product caveat · Score treatment: note-only

Assurance: Falcon-512 signature size (~666 bytes), public key size (~897 bytes), and verification time (~5μs) are documented in SIMD-0461. Transaction size increase to 4096 bytes (SIMD-0296) is designed explicitly to accommodate PQ signatures. The migration proof prototype (~400kB, 55ms) provides performance data. However, no formal benchmarking of PQ signature verification in Solana's validator pipeline, block validation impact, gas/fee market effects, or archival storage growth analysis exists.

Performance analysis is adequate for the current prototype stage but insufficient for production deployment decisions. Key open questions include: impact of Falcon verification on block validation time at scale, fee market effects of larger signatures, archival storage growth from larger transactions, and validator hardware requirements for PQ signature verification throughput.

• https://www.anza.xyz/blog/securing-solana-against-a-powerful-quantum-adversary
• https://jumpcrypto.com/resources/quantum-migration-paths-for-solana
• https://github.com/solana-foundation/solana-improvement-documents/pull/461