PoS smart-contract platform
Solana SOL
Solana scores 24/100 (Stage 2: Mitigation / Development). The project has published one of the most comprehensive quantum risk assessments in the blockchain industry, with detailed cryptographic inventories, formal migration roadmaps, and prototype Falcon implementations from both Anza and Firedancer. The SHA-512 Ed25519 seed derivation provides a credible theoretical migration path via ZK proofs. However, none of this changes the production reality: all native transaction signatures on mainnet use Ed25519 (broken by Shor's algorithm), TowerBFT consensus uses Ed25519 votes, BLS pubkey registration (SIMD-0387) is already live on mainnet for the upcoming Alpenglow consensus which will use BLS12-381 (also quantum-vulnerable). The opt-in Winterwallet (Winternitz Vault) provides application-layer quantum resistance on mainnet but protects negligible value (<300 accounts). SIMD-0461 (Falcon syscall) was closed/paused in June 2026; the team is exploring a Keccak-f1600 syscall approach instead. SIMD-0296 (larger transactions to 4096 bytes) is activating imminently as prerequisite infrastructure. No independent cryptographic audit of any quantum-critical component exists. No protocol-level PQ spend authorization or consensus authentication exists. Solana is well-prepared on paper but has no material production quantum protection today.
Roadmap OnlyPartial Protection
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
5.75 / 20
Migration Mechanism, Governance & Ecosystem Coordination
5.25 / 15
Migration Status & Value-at-Risk
1.5 / 25
Production Cryptographic Protection
6.3 / 35
Security Assessment & Evidence Preparedness
5 / 5
Critical Quantum Blockers
- All production transaction signatures use Ed25519, which is broken by Shor's algorithm. No protocol-level PQ or hybrid-PQ spend authorization path exists on mainnet.
- Consensus authentication (TowerBFT Ed25519 vote transactions; upcoming Alpenglow BLS12-381 aggregated certificates) remains quantum-vulnerable. BLS pubkey registration is already live on mainnet.
- Material long-exposure quantum-vulnerable value exists across all SOL accounts, SPL tokens, DeFi protocols, bridges, and treasuries with no migration, freeze, deprecation, burn, recovery, or policy path.
- SIMD-0461 (Falcon syscall) was closed/paused. The alternative Keccak-f1600 syscall approach (SIMD-0563) is exploratory and does not yet provide native PQ verification.
Key Risks
- All SOL and SPL token accounts with exposed public keys are vulnerable to offline quantum attack via Shor's algorithm. This includes every account that has ever signed a transaction, every stake account, every vote account, every token mint authority, every program upgrade authority, and every multisig.
- Consensus finality is quantum-vulnerable. A quantum adversary could forge Ed25519 vote transactions to compromise TowerBFT consensus. The planned Alpenglow upgrade (BLS12-381) does not resolve this — it introduces a different quantum-vulnerable primitive.
- BLS pubkey registration (SIMD-0387) is already live on mainnet, and Alpenglow consensus activation is expected in Agave 4.3 (October 2026). This means near-term protocol upgrades are deepening classical cryptographic assumptions.
- No migration, freeze, deprecation, or burn mechanism exists for quantum-vulnerable accounts. If a CRQC (cryptographically relevant quantum computer) emerges before migration is complete, all exposed value is at immediate risk with no protocol-level recourse.
- SIMD-0461 (Falcon syscall) was closed/paused, and the alternative Keccak-f1600 syscall approach (SIMD-0563) is exploratory. The final PQC algorithm choice and activation timeline remain uncertain.
- Bridge dependencies (e.g., Wormhole) may allow value to flow between Solana and non-PQ-secure systems. The quantum security of wrapped/bridged assets depends on both chains and the bridge's own signer-set security.
- No hardware wallet, HSM, or institutional custody solution supports PQ signatures for Solana. Even if protocol-level PQ support were activated tomorrow, the custody infrastructure is unprepared.
- The Winterwallet's WOTS scheme is one-time-use, creating UX and key-management challenges that limit its suitability as a general-purpose replacement for Ed25519.
Assurance Notes
- No independent cryptographic audit of any quantum-critical component (Falcon implementations, Winternitz Vault, or any PQ-specific code) exists as of 2026-08-13. The Code4rena audit (Aug-Sep 2025) covered Token22 confidential transfers only — scope-mismatched for quantum-critical assessment.
- SIMD-0461 (Falcon syscall) was closed/paused in June 2026. The core team is exploring a Keccak-f1600 syscall (SIMD-0563) as an alternative approach that would support multiple PQC signature schemes without committing to Falcon specifically.
- SIMD-0296 (larger transaction sizes to 4096 bytes) is merged and expected to activate with Agave 4.2 starting the week of August 17, 2026. This is a prerequisite for native PQC signatures but does not itself provide any quantum protection.
- Alpenglow consensus introduces BLS12-381 aggregated certificates. BLS pubkey registration (SIMD-0387) is already live on mainnet. Full Alpenglow activation is expected in Agave 4.3 (targeted October 2026). Both Ed25519 (current) and BLS12-381 (planned) are quantum-vulnerable.
- The Winternitz Vault README contains a candid disclaimer from its author: 'I am a pretty good dev larping as a cryptographer.' No independent cryptographic audit has been published for this component.
- No formal quantum-specific incident-response playbook has been published. General security programs (STRIDE, SIRN) exist but are not quantum-focused.
- The SHA-512 Ed25519 seed derivation design provides a credible theoretical post-Q-day migration path via ZK proofs, but this mechanism is not yet implemented on mainnet. Anza has a prototype at anza-xyz/cryptography/pull/10.
- Winterwallet (Blueshift) provides opt-in application-layer quantum resistance using WOTS on mainnet, but adoption is negligible (<300 accounts as of April 2026) and it does not protect the protocol-level transaction signature scheme.
Non-Scoring Caveats
- SIMD-0296 (larger transaction sizes to 4096 bytes) is a prerequisite for native PQC signatures but does not itself provide quantum protection. Its activation with Agave 4.2 is a necessary but insufficient step.
- The SHA-512 Ed25519 seed derivation design is a strong architectural advantage for future migration (ZK proof of seed → bind Falcon key) but is not yet implemented on mainnet. This is a roadmap asset, not current protection.
- Project Eleven deployed a functioning PQ testnet in late 2025 demonstrating end-to-end viability, but this has not been promoted to mainnet.
- Winterwallet demonstrates that application-layer PQC is deployable on Solana today without protocol changes, but adoption is negligible and it cannot protect the broader account model, fee payment, consensus, or arbitrary programs.
- No hardware wallet, HSM, or institutional custody solution supports PQ signatures for Solana. Even if protocol-level PQ support were activated, the custody infrastructure is unprepared.
- Solana's fee model is signature-oriented and will need updating to price verification compute, transaction bytes, and state pressure for PQC signatures — an economic and resource challenge that is acknowledged but unresolved.
- No formal performance benchmark exists for PQ signature verification in a production Solana validator context. Existing analysis (Jump Crypto, Project Eleven, IACR eprint 2025/1741) is preliminary.
- Near-term protocol upgrades (Alpenglow with BLS12-381) are introducing new classical cryptographic dependencies while the network has not yet addressed quantum vulnerability at the transaction layer.
Evidence record
Claims and Caveats
Security Assessment & Evidence Preparedness
Public cryptographic inventory and quantum threat model
Claim: Solana has published a comprehensive public cryptographic inventory identifying Ed25519 (account/transaction signatures), BLS12-381 (planned Alpenglow consensus), and SHA-256/Keccak (hashing) as the critical public-key mechanisms, with explicit quantum threat modeling covering Shor's algorithm impact on spend authorization, consensus, and account model.
Coverage basis: PQ/hybrid usage assessment
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Primary sources from Anza (core developer), Solana Foundation, and Jump Crypto/Firedancer all converge on the same inventory. The Anza blog post (2026-04-27) explicitly identifies four protocol layers using ECC and provides a detailed quantum threat model with updated probability estimates.
This is one of the most comprehensive quantum risk assessments published by any blockchain project. The cryptographic inventory is detailed, code-referenced, and covers all critical layers.
Security Assessment & Evidence Preparedness
Public evidence record supporting the assessment
Claim: The quantum risk assessment is supported by code references, protocol specifications, transaction examples, and reproducible analytics across multiple primary sources.
Coverage basis: PQ/hybrid usage assessment
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Evidence includes links to specific source code (Agave repo), protocol documentation (Ed25519 precompile), and detailed technical analysis with concrete attack scenarios. The Anza blog post links to specific PRs (anza-xyz/cryptography/pull/10) demonstrating migration proof prototypes.
Evidence quality is strong. Multiple independent teams (Anza, Firedancer, Blueshift, Anagram) have published corroborating analyses.
Production Cryptographic Protection
Spend authorization / transaction signatures
Claim: All native transaction signatures on Solana mainnet use Ed25519, verified via the Ed25519 precompile. No protocol-level PQ or hybrid-PQ signature verification path exists on mainnet. SIMD-0461 (Falcon syscall) was closed/paused in June 2026. The Winterwallet provides opt-in application-layer PQC spend authorization using WOTS but is not a protocol-level solution.
Coverage basis: PQ/hybrid usage
Implementation score: 0.25 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All production transaction signatures use Ed25519, broken by Shor's algorithm. No protocol-level PQ path exists on mainnet.
Assurance: Multiple primary sources (Solana docs, Anza blog, Jump Crypto, GitHub) confirm Ed25519-only production spend authorization. SIMD-0461 closure is confirmed in the GitHub PR. Winterwallet mainnet deployment is confirmed but adoption is negligible.
Scored 0.25 (roadmap/proposal) rather than 0.00 because a public design and migration roadmap exists (Falcon selection, SIMD proposals, ZK-proof-based migration design). The Winterwallet demonstrates application-layer feasibility but does not change the protocol-level score.
Production Cryptographic Protection
Account, address, public-key exposure, and key-derivation design
Claim: Solana accounts use Ed25519 public keys as on-chain addresses. Public keys are long-exposed for any account that has signed a transaction. The Ed25519 keypair derivation uses SHA-512, which is quantum-resistant for preimage resistance, enabling a theoretical ZK-proof-based migration path. However, no PQ/hybrid controls, address versioning, or migration mechanism exists in production.
Coverage basis: PQ/hybrid usage
Implementation score: 0.25 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All account public keys are Ed25519 and long-exposed on-chain. No PQ address format or migration path exists in production.
Assurance: The SHA-512 seed derivation property is a genuine architectural advantage for future migration but provides zero current protection. PDAs (Program Derived Addresses) have no private keys and are inherently quantum-resistant for their controlled state, but the programs that control them rely on Ed25519 signatures.
Scored 0.25 rather than 0.00 because the SHA-512 seed derivation is a notable design property that enables a future ZK-proof migration path, and Winternitz Vault provides opt-in application-layer PQ protection. However, this does not prevent long-exposure quantum-vulnerable ownership paths for the broader account model.
Production Cryptographic Protection
Consensus-critical authentication
Claim: Current TowerBFT consensus uses Ed25519 vote transactions for validator authentication. BLS pubkey registration (SIMD-0387) is already live on mainnet for the upcoming Alpenglow consensus. The planned Alpenglow consensus upgrade (expected Agave 4.3, October 2026) will use BLS12-381 aggregated certificates. Both Ed25519 and BLS12-381 are quantum-vulnerable via Shor's algorithm. No PQ consensus authentication exists in production or in any planned consensus mechanism.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Consensus authentication is quantum-vulnerable (Ed25519 now, BLS12-381 planned). No PQ consensus design exists.
Assurance: Alpenglow mainnet activation is expected in Agave 4.3 (October 2026). BLS pubkey registration (SIMD-0387) is already active on mainnet. The current production consensus remains TowerBFT with Ed25519 votes.
The Alpenglow upgrade is particularly concerning from a quantum perspective: it introduces a new quantum-vulnerable dependency (BLS12-381) at the consensus layer while the network has not yet addressed quantum vulnerability at the transaction layer. BLS pubkey registration being already live means the network is actively deepening classical cryptographic assumptions.
Production Cryptographic Protection
State-integrity and data-availability mechanisms
Claim: Solana's state integrity relies primarily on SHA-256-based Merkleization (account hashes, bank hashes, epoch boundary states), which is quantum-resistant for preimage resistance. No KZG/pairing-based commitments exist in current production. However, Turbine/Rotor shred authentication for data availability uses Ed25519 signatures, creating a quantum-vulnerable DoS vector.
Coverage basis: PQ/hybrid usage
Implementation score: 0.75 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The core state integrity mechanisms (SHA-256 hashing) are quantum-resistant. The Ed25519 shred signing vulnerability primarily affects data availability (DoS) rather than state integrity. A quantum adversary could flood the network with forged shreds but could not forge the state commitment itself.
Scored 0.75 because the core state-integrity commitments are hash-based (quantum-resistant), but data-availability authentication (shred signing) remains Ed25519-dependent. This is a liveness/DoS concern rather than a state-integrity concern, but it affects the overall security model.
Production Cryptographic Protection
Privacy and proof layers
Claim: Solana's Token22 program includes confidential transfers using ZK ElGamal proofs, which rely on discrete-log assumptions and are quantum-vulnerable. Most transactions are transparent. No PQ privacy layer exists.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The Code4rena audit (Aug-Sep 2025) covered the ZK ElGamal Proof program and Token22 confidential transfer logic but did not include quantum threat assessment. The underlying cryptographic assumptions (discrete logarithm) are quantum-vulnerable by design. Most Solana transactions are transparent, limiting the practical quantum risk from this layer.
Privacy is an optional feature on Solana. The quantum vulnerability of ZK ElGamal affects only users who opt into confidential transfers.
Production Cryptographic Protection
P2P transport, node identity, and peer authentication
Claim: Solana uses Ed25519 for node identity and shred authentication in Turbine/Rotor. QUIC/TLS is used for transport. Node identity keys are quantum-vulnerable.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: Medium
Issue classification: operational/product caveat · Score treatment: note-only
Assurance: P2P node identity is not directly consensus, spend, bridge, or custody-critical in Solana's architecture. A quantum adversary compromising node identity could disrupt networking (DoS, eclipse attacks) but could not directly steal funds or compromise finality through this vector alone. However, spend authorization is also not PQ-signed, so the satisfied-by-design exemption does not apply.
The P2P layer is not satisfied-by-design because spend authorization is not PQ-signed. Node identity compromise could facilitate network-level attacks that compound other quantum vulnerabilities.
Production Cryptographic Protection
Critical wallet, custody, HSM, signer, and hardware-wallet workflows
Claim: No hardware wallet, HSM, or institutional custody solution supports PQ signatures for Solana. Winterwallet provides a software-only PQ path using WOTS but has no hardware-wallet integration. Mainstream Solana wallets (Phantom, Solflare, Backpack) do not support PQ signatures.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Even if protocol-level PQ support were activated, the custody infrastructure is entirely unprepared. No Ledger, Trezor, or institutional HSM supports Falcon or WOTS signatures for Solana.
Winterwallet is a positive step but is software-only, one-time-use (WOTS), and has negligible adoption. It does not represent a viable custody path for institutional or hardware-wallet users.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected
Claim: Less than 0.1% of Solana's economically relevant value is protected from quantum key-recovery attacks. The Winterwallet protects fewer than 300 accounts. All SOL, SPL tokens, DeFi TVL, staked SOL, bridge-collateralized assets, and protocol treasuries remain secured by Ed25519 signatures only.
Coverage basis: Migrated value / complete-by-design native coverage
Implementation score: 0.05 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: >99% of economic value on Solana is quantum-vulnerable with no migration, freeze, or protection path.
Assurance: Exact value-at-risk figures are not independently audited. The <0.1% estimate is based on Winterwallet adoption metrics (<300 accounts as of April 2026) relative to Solana's total account base (hundreds of millions).
Coverage is in the <25% band (score 1/20 of subfactor weight). The Winterwallet protects negligible value. No protocol-level protection exists. All long-exposure accounts (every account that has ever signed a transaction) are vulnerable.
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native
Claim: No evidence that any Solana treasury, exchange, custodian, bridge, foundation, or major protocol has migrated to PQ-protected controls.
Coverage basis: Migrated value
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) have migrated to PQ controls.
Assurance: No public attestations or on-chain evidence of PQ migration by any major Solana stakeholder.
This is a critical gap. Even if individual users could migrate, the largest value pools (protocol treasuries, bridge contracts, foundation wallets) remain entirely quantum-vulnerable.
Migration Status & Value-at-Risk
Legacy vulnerable pools identified, measurable, deprecated, migrated, frozen, or proven not to exist
Claim: Solana has clearly identified the vulnerable surface: all Ed25519 accounts. However, no deprecation, freeze, migration, or burn mechanism exists for vulnerable accounts.
Coverage basis: Migrated value
Implementation score: 0.25 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The identification of vulnerable surfaces is thorough and well-documented. However, identification without mechanism provides no protection.
Scored 0.25 because the vulnerable surface is well-identified and measurable, but no mechanism exists to address it. The SHA-512 seed derivation provides a theoretical path for willing migrators but no solution for lost/abandoned accounts.
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: Solana has published detailed migration roadmaps from multiple sources (Solana Foundation, Anza, Jump Crypto/Firedancer) with clear sequencing: SIMD-0296 (larger transactions) → address versioning → Falcon migration. The SHA-512 seed ZK-proof migration path is well-documented.
Coverage basis: PQ/hybrid usage
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: The roadmap is unusually detailed for a blockchain project, with convergence across independent teams (Anza, Firedancer) on Falcon as the PQC candidate. However, SIMD-0461 (Falcon syscall) was closed/paused, introducing uncertainty about the activation path.
The roadmap quality is a genuine strength. The SHA-512 seed derivation migration design is architecturally elegant. However, roadmaps are not production protection, and the closure of SIMD-0461 suggests the path is still evolving.
Migration Mechanism, Governance & Ecosystem Coordination
Migration accessibility and defaults
Claim: No PQ/hybrid account creation is available at the protocol level. Winterwallet provides opt-in PQ but is not integrated into mainstream wallets, not default, and not mandatory. No user-facing quantum vulnerability warnings or migration prompts exist in major Solana wallets.
Coverage basis: PQ/hybrid usage
Implementation score: 0.25 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Winterwallet exists and works on mainnet but is a third-party tool with negligible adoption. No major wallet (Phantom, Solflare, Backpack) supports PQ account creation or displays quantum risk warnings.
Scored 0.25 because a public design and prototype tooling exists (Winterwallet, Falcon implementations), but no production-grade, default, or widely-accessible PQ path is available to users.
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and coordination
Claim: No enforcement mechanisms exist for quantum migration. No deprecation of Ed25519 accounts, no freeze mechanism, no disabled legacy signing, no restricted withdrawals, no unsafe-path blocking, and no mandatory migration deadline.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No enforcement, deprecation, freeze, or mandatory migration mechanism exists. Users can create new quantum-vulnerable accounts by default.
Assurance: The Solana Foundation's quantum readiness page explicitly states 'no change is required today or likely anytime soon,' indicating that enforcement mechanisms are not currently prioritized.
This is a significant gap. Without enforcement mechanisms, even if PQ support were activated, vulnerable accounts could persist indefinitely.
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: Solana has general security programs (STRIDE, SIRN) and a bug bounty program, but no formal quantum-specific incident-response playbook, disclosure process, or emergency governance procedure has been published.
Coverage basis: PQ/hybrid usage
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: General security processes exist but are not quantum-specific. The absence of a quantum-specific incident-response playbook is an assurance gap rather than a current quantum-critical vulnerability.
Scored 0.25 because general security programs exist and the quantum risk is acknowledged at the organizational level, but no formal quantum-specific process has been published.
Algorithm & Implementation Assurance
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms
Claim: Falcon (FN-DSA) has been selected as the primary PQC candidate and is a NIST draft standard (FIPS 206). Winternitz/WOTS (used in Winterwallet) is a well-reviewed hash-based scheme. However, neither is deployed at the protocol level in production.
Coverage basis: PQ/hybrid usage
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Falcon is a NIST draft standard (FIPS 206) and is broadly reviewed. WOTS is a well-understood hash-based construction. However, the closure of SIMD-0461 and exploration of Keccak-f1600 syscall suggests the final algorithm choice may still evolve.
Scored 0.25 because appropriate NIST-track algorithms have been selected and prototyped, but none are used in production at the protocol level.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit exists for the quantum-critical scope
Claim: No independent cryptographic audit of any quantum-critical component (Falcon implementations, Winternitz Vault, or any PQ-specific code) exists as of 2026-08-13. The Code4rena audit (Aug-Sep 2025) covered Token22 confidential transfers only.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: High
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: The absence of any independent audit for quantum-critical code is concerning, particularly for the Winterwallet which is live on mainnet. The Winternitz Vault README contains a candid disclaimer from its author questioning their own cryptographic expertise. Per QRI guidance, missing audit is an assurance-only caveat that affects Confidence but not QRI Score directly since no quantum-critical property is in production to be audited.
Scored 0.00 because no audit exists. Treated as confidence-only rather than score-reducing because the PQ implementations are not yet in production and no quantum-critical property can be audited.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
Claim: Falcon implementations from Anza and Firedancer are available as open-source PRs on GitHub. Winterwallet/Winternitz Vault is open-source (MIT License). However, these are prototype-quality implementations, not production protocol code.
Coverage basis: PQ/hybrid usage
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Code is publicly available and open-source. However, the Falcon implementations are prototype PRs, not merged production code. The Winterwallet is more mature but is a third-party application, not part of the core protocol.
Scored 0.50 because open-source prototypes exist but are not production-grade protocol implementations. The Winterwallet is a more complete implementation but is application-layer only.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path are documented
Claim: Solana has documented algorithm agility considerations. The Anza blog explicitly states 'None of this constitutes a commitment to a specific post-quantum signature scheme' and discusses alternatives (SQIsign). Address versioning is planned to support multiple signature schemes.
Coverage basis: PQ/hybrid usage
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Algorithm agility is well-documented in design discussions. The Keccak-f1600 syscall approach (SIMD-0563) would support multiple PQC schemes. However, no upgrade path is implemented in production.
Scored 0.50 because the design documentation is thorough and the Keccak-f1600 approach shows genuine agility thinking, but nothing is implemented in production.
Algorithm & Implementation Assurance
Stateful-signature safety, side-channel, fault-injection, state-management, hardware-wallet, HSM, or custody implementation risks
Claim: Winterwallet handles WOTS one-time constraint automatically in the wallet layer. Falcon is stateless (no state-management concerns unlike XMSS/LMS). However, no formal side-channel analysis, fault-injection assessment, or HSM/custody integration analysis exists for any Solana PQ implementation.
Coverage basis: PQ/hybrid usage
Implementation score: 0.25 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: not applicable
Assurance: The WOTS one-time constraint is handled in Winterwallet's wallet layer. Falcon's stateless nature avoids XMSS/LMS-style state-management risks. However, no formal security analysis of side-channel resistance, fault-injection, or custody integration exists.
Scored 0.25 because design-level consideration of stateful-signature safety exists (WOTS rotation, Falcon statelessness), but no formal analysis or custody integration work has been published.
Algorithm & Implementation Assurance
Performance and resource-impact analysis exists where PQ signature/verification costs could affect safe deployment
Claim: Jump Crypto has published signature size comparisons (Falcon-512: ~666 byte signatures, ~897 byte public keys). Project Eleven demonstrated end-to-end PQ testnet performance. The IACR eprint (2025/1741) demonstrates STARK+PQC verification feasibility within Solana CU limits.
Coverage basis: PQ/hybrid usage
Implementation score: 0.75 · Evidence confidence: Medium
Issue classification: operational/product caveat · Score treatment: not applicable
Assurance: Performance analysis exists from multiple sources and is reasonably thorough for the prototype stage. However, no formal benchmark exists for PQ signature verification in a production validator context under realistic load.
Scored 0.75 because substantive performance analysis exists from multiple independent sources, but it is preliminary and not validated in production. The analysis correctly identifies that Solana's fee model, CU budget, and transaction size limits all need adjustment for PQ signatures.
Report metadata