tokenized asset
Stellar XLM
Stellar remains fully dependent on Ed25519 for all production-critical cryptographic operations as of June 10, 2026, with zero post-quantum protection live on mainnet. The Stellar Development Foundation published a comprehensive Quantum Preparedness Plan (QPP) on June 9, 2026 — one day before this evaluation — outlining a well-structured three-stage migration roadmap targeting ML-DSA integration via Soroban host functions in 2026 and native classic-account PQ signer support via CAP in 2027. The QPP demonstrates serious institutional engagement with quantum risk: it identifies specific NIST-standard algorithms (ML-DSA-44, ML-DSA-65), provides a credible staged timeline, correctly diagnoses both the account-takeover and consensus-compromise threat vectors, and acknowledges unsolved problems (BN254 pairing dependency, dormant accounts). Stellar's architectural separation of account identity from signing keys represents a genuine structural advantage — once PQ signer types exist, users can add quantum-safe signers without changing addresses or migrating balances. However, Stellar's address format (G... addresses) directly encodes Ed25519 public keys, meaning 100% of the ~33.7B XLM circulating supply (~$6.6B market cap) is in the long-exposure attack window today. SCP consensus authentication also remains Ed25519-only. The X-Ray privacy system adds a separate BN254 pairing-based vulnerability with no defined mitigation path. The base ledger's SHA-256 hash chain provides PQ-safe state integrity, earning partial credit in Production Cryptographic Protection. CAP-77 (Quorum Freeze), live since May 2026, provides a protocol-native emergency governance tool that could potentially be applied to quantum scenarios. With no PQ code, testnet, prototype, or mainnet deployment, the project is correctly staged at Stage 2 (Mitigation/Development). The QRI score of 14 reflects strong assessment and planning work capped by the complete absence of production PQ protection.
Roadmap OnlyPartial ProtectionECC-Only Spend AuthorizationExposed Public KeysEd25519
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
2 / 20
Migration Mechanism, Governance & Ecosystem Coordination
1.5 / 15
Migration Status & Value-at-Risk
1.5 / 25
Production Cryptographic Protection
6 / 35
Security Assessment & Evidence Preparedness
3.25 / 5
Critical Quantum Blockers
- All production spend authorization is Ed25519-only — no PQ or hybrid signing path exists on mainnet (Readiness & Risk Cap 40: 'Active production spend authorization remains entirely ECC/BLS/Schnorr/EdDSA-only').
- 100% of Stellar account addresses (G... addresses) directly encode the Ed25519 public key, placing all ~33.7B XLM circulating supply (~$6.6B market cap) in the long-exposure attack window with no migration, freeze, or deprecation mechanism live (Readiness & Risk Cap 55: 'Material long-exposure quantum-vulnerable value exists with no migration path').
- Stellar Consensus Protocol (SCP) validator authentication relies entirely on Ed25519 signatures — a quantum-capable adversary could forge validator signatures to compromise quorum intersection and network finality (Readiness & Risk Cap 70: 'Consensus finality, validator authentication... remains quantum-vulnerable').
- X-Ray privacy system uses BN254 pairing-based elliptic curve for zero-knowledge proofs — quantum-vulnerable to Shor's algorithm with no defined PQ migration path. QPP explicitly acknowledges this as an open research challenge (Readiness & Risk Cap 70: 'Application-layer proof systems... depend on quantum-vulnerable pairings').
Key Risks
- All ~33.7B XLM in circulating supply is controlled by Ed25519-only keys with public keys directly exposed in account addresses from the moment of creation — a quantum adversary needs only to derive private keys from these exposed public keys to steal funds, and all accounts (including dormant ones that have never transacted) are perpetually vulnerable.
- SCP consensus can be compromised if an attacker forges sufficient validator Ed25519 signatures to control quorum intersection. Unlike account takeover, this is a network-liveness and finality threat that could affect all users simultaneously.
- Stellar's address format (G... addresses directly encoding Ed25519 public keys) is structurally more vulnerable than Bitcoin's or Ethereum's hashed-public-key approach, where keys are only exposed upon first spend. On Stellar, even accounts that have never transacted have fully exposed keys from the moment of creation.
- Dormant accounts with unreachable holders represent a permanent quantum-vulnerable value pool. The QPP acknowledges this as an unresolved challenge requiring community governance, but no freeze, recovery, or deprecation mechanism exists yet. CAP-77 could potentially be used but has not been designed for this purpose.
- X-Ray's BN254 dependency is quantum-vulnerable and has no defined mitigation path. The QPP explicitly acknowledges this as an open research challenge: 'there is no drop-in post-quantum replacement for pairing-based SNARKs with comparable performance.' While X-Ray is opt-in and does not threaten core asset ownership, any privacy-sensitive transactions could be retrospectively deanonymized by a future quantum adversary.
- The QPP is a strategic announcement with no reviewable code, testnet deployment, or detailed technical specification. Execution risk is material — the plan requires coordinated upgrades across stellar-core, Soroban host functions, SDKs, wallets, anchors, and custodians. Technical specifications are promised 'over the coming weeks' but have not been published.
- The QPP roadmap targets 2027 for native classic-account PQ support, but NIST guidance places the quantum danger zone at 2029+. If quantum capabilities advance faster than expected, the migration window could narrow dangerously. INRIA researchers recently showed breaking 256-bit ECC requires only 1,193 logical qubits — a 44% reduction from prior estimates.
- Soroban SDK v26.0.0 (May 2026) expanded BN254 and BLS12-381 host functions (CAP-80), increasing the quantum-vulnerable pairing-based cryptography surface on mainnet even as the QPP acknowledges no PQ replacement exists for these primitives.
Assurance Notes
- No independent PQ-specific cryptographic or implementation audit exists because no PQ implementation has been deployed on mainnet.
- The Quantum Preparedness Plan (QPP) was published on 2026-06-09, one day before the evaluation date. Technical specifications and CAP proposals have not yet been published; the QPP states these will be released 'over the coming weeks.'
- No PQ-specific testnet, devnet, prototype, or experimental code is publicly available in stellar-core or Soroban repositories as of the evaluation date.
- Existing security audits (Veridise Aug 2025 for Soroban Core, OpenZeppelin Apr 2026 for Stellar Contracts RC v0.7.0, Hacken for ecosystem projects) do not cover post-quantum cryptography and are scope-mismatched for PQ assurance.
- CAP-77 (Quorum Freeze) went live on mainnet on 2026-05-06 as part of Protocol 26 'Yardstick.' It provides a protocol-native, consensus-driven account freeze mechanism that could potentially be applied in a quantum emergency, though it has not been designed or governance-approved for that purpose.
- Soroban SDK v26.0.0 (May 2026) expanded BN254 and BLS12-381 host functions via CAP-80, increasing the quantum-vulnerable pairing-based cryptography surface on mainnet.
- Stellar's structural separation of account identity (G... address) from signing keys is a significant migration advantage acknowledged in the QPP: users can add PQ signers without changing addresses or migrating balances.
- The dormant account problem is acknowledged in the QPP as unresolved. Stellar has a large population of dormant accounts with exposed Ed25519 public keys whose holders are unreachable, and the QPP defers the deprecation/recovery decision to future community governance.
Non-Scoring Caveats
- The QPP was published only one day before the evaluation date (2026-06-09). While its depth and specificity are commendable — naming specific NIST algorithms (ML-DSA-44, ML-DSA-65), integration mechanisms (Soroban host functions, set_options), and staged timelines (2026-2027) — it remains a strategic announcement rather than a detailed technical specification with reviewable code.
- Stellar's architectural separation of account identity from signing keys provides a structurally advantageous migration path that does not require balance transfers or address changes. Once PQ signer types exist, users can add quantum-safe signers through the existing set_options operation. This is a genuine advantage over Bitcoin and Ethereum.
- CAP-77 (Quorum Freeze) is live on mainnet since May 2026 and provides a protocol-native, consensus-driven emergency governance mechanism that could potentially be used to freeze quantum-vulnerable accounts in an emergency. However, this application has not been designed, tested, or governance-approved for quantum scenarios.
- No formal quantum-specific incident-response playbook is documented. The QPP itself serves as a form of quantum-specific disclosure, and CAP-77 provides a general emergency tool, but no quantum-adapted IR framework exists.
- Dormant accounts with exposed Ed25519 public keys represent a permanent quantum-vulnerable value pool. The QPP acknowledges this as an unresolved challenge requiring community governance discussion before Stage 3 deprecation. No freeze, recovery, or deprecation policy exists yet.
- Soroban SDK v26.0.0 (May 2026) expanded BN254 and BLS12-381 host functions (CAP-80), increasing the quantum-vulnerable pairing-based cryptography surface on mainnet. The QPP acknowledges that pairing-based ZK has no drop-in PQ replacement.
- No formal performance/resource benchmark exists for the planned ML-DSA integration. ML-DSA-44 signatures are approximately 2.4 KB vs 64 bytes for Ed25519 (~38x larger), with material implications for SCP message propagation, ledger storage, transaction fees, and bandwidth.
- Future PQ-to-PQ upgrade uncertainty (e.g., adding Falcon/FN-DSA alongside ML-DSA, or migrating from ML-DSA to future standards) is a normal operational roadmap concern and does not affect current quantum-attack readiness.
Evidence record
Claims and Caveats
Security Assessment & Evidence Preparedness
Public cryptographic inventory of critical public-key mechanisms and public quantum threat model
Claim: QPP provides a comprehensive public inventory identifying Ed25519 for accounts and consensus, BN254 for ZK proofs, with a clear threat model distinguishing account takeover from network integrity compromise.
Coverage basis: Published risk assessment with algorithm identification and threat model
Implementation score: 0.75 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: The QPP is an official SDF publication authored by SDF core developer Nicolas Barry, providing high-confidence evidence of cryptographic inventory and threat assessment. No independent audit of the inventory exists, but the claims are directly verifiable from protocol documentation and source code.
The QPP is exceptionally thorough for a blockchain quantum assessment: it identifies specific curves (Ed25519, BN254, BLS12-381), attack vectors (Shor's algorithm key recovery, consensus forgery), affected layers (accounts, SCP, ZK), and references current research (INRIA 2026 qubit estimates, NIST 2029+ guidance). Published one day before evaluation; no independent review yet.
Security Assessment & Evidence Preparedness
Public evidence record supporting the assessment
Claim: QPP references INRIA research, NIST standards (ML-DSA, ML-KEM), Google's 2029 internal deadline, CNSA 2.0 and DORA regulatory frameworks, and comparable blockchain efforts (Ethereum emergency hard fork, Bitcoin BIP-360, Algorand Falcon state proofs).
Coverage basis: Published evidence record with standards citations and research references
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: The QPP references external research and standards but does not yet provide code-level evidence, reproducible analytics, or transaction examples for PQ migration (none exist yet). The classical Ed25519 dependency is fully verifiable from source code and documentation.
The evidence record is strong for threat assessment (references to INRIA, NIST, Google) but necessarily thin for PQ implementation evidence since none exists. The QPP states that detailed technical specifications will be published 'over the coming weeks.'
Production Cryptographic Protection
Spend authorization / transaction signatures are PQC or hybrid-PQC on mainnet
Claim: All Stellar transaction signing uses Ed25519 exclusively — no PQ or hybrid signing path exists on mainnet for either classic accounts or Soroban contract accounts.
Coverage basis: ECC-only production spend authorization
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: cap-applying
Quantum blocker: All production spend authorization is Ed25519-only. Triggers Readiness & Risk Cap 40 for 'Active production spend authorization remains entirely ECC/BLS/Schnorr/EdDSA-only.'
Assurance: Ed25519-only status confirmed by multiple primary sources: official documentation, stellar-core source code, and the QPP itself which acknowledges this as the problem to be solved. No contrary evidence exists.
QPP Stage 1 (2026) plans to add ML-DSA verification to Soroban host functions, enabling contract accounts to use PQ signatures. Stage 2 (2027) plans native PQ signer types for classic accounts. Neither is live. The structural separation of account identity from signing keys means that once PQ signer types exist, migration does not require address changes or balance transfers.
Production Cryptographic Protection
Account, address, public-key exposure, and key-derivation design prevents long-exposure quantum-vulnerable ownership paths or supports PQ/hybrid controls
Claim: Stellar G... addresses directly encode the Ed25519 public key. Every account on the network exposes its public key from creation, including dormant accounts that have never transacted.
Coverage basis: 100% long-exposure quantum-vulnerable public keys
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: cap-applying
Quantum blocker: 100% of Stellar accounts have long-exposure Ed25519 public keys. Unlike Bitcoin/Ethereum where addresses are hashes of public keys and only exposed on first spend, Stellar exposes the public key immediately upon account creation. Triggers Readiness & Risk Cap 55.
Assurance: The QPP itself explicitly acknowledges this: 'account addresses (G... addresses) directly encode the Ed25519 public key, which means every account address on the network is a target—including dormant accounts that have never authorized a transaction.'
This is a structural vulnerability that cannot be retroactively fixed — the public keys are already on-chain permanently. The mitigation path (adding PQ signers to existing accounts in Stage 2) protects against future quantum attacks on spend authorization but does not retroactively protect the exposed public keys.
Production Cryptographic Protection
Consensus-critical authentication is PQC or hybrid-PQC where applicable, including validator signatures, VRFs, randomness beacons, threshold signatures, or block certificates
Claim: SCP messages are authenticated with Ed25519 signatures by validators. An attacker who can forge enough validator signatures to control quorum intersection can compromise consensus.
Coverage basis: ECC-only consensus authentication
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: cap-applying
Quantum blocker: SCP consensus authentication is Ed25519-only. Triggers Readiness & Risk Cap 70 for 'Consensus finality, validator authentication... remains quantum-vulnerable,' but the more restrictive Cap 40 from Ed25519-only spend authorization is already binding.
Assurance: Confirmed by SCP documentation, stellar-core source code, and explicitly acknowledged in the QPP: 'Stellar Consensus Protocol messages are authenticated with Ed25519 signatures by validators.'
QPP identifies SCP migration as a separate protocol upgrade. The validator set is smaller (hundreds, not millions) making this a more tractable coordination problem than account migration.
Production Cryptographic Protection
State-integrity and data-availability mechanisms are quantum-safe where applicable, including commitments, nullifiers, accumulators, script authorization, supply-binding mechanisms, KZG/pairing-based commitments, and bridge verification
Claim: Stellar's ledger uses SHA-256 hash chains for state integrity. There are no KZG commitments, nullifiers, or pairing-based accumulators in the core protocol. Supply binding is enforced by consensus rules on hash-authenticated state.
Coverage basis: Hash-based state integrity — PQ-safe by design
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Hash-based state integrity is verifiable from SCP documentation and stellar-core source code. SHA-256 is widely accepted as quantum-safe for collision resistance.
The X-Ray system's BN254 dependency is a privacy-layer concern, not a state-integrity concern for the base ledger. Base-ledger state remains verifiable via hash chains regardless of X-Ray proof validity.
Production Cryptographic Protection
Privacy and proof layers are quantum-safe where applicable, including ZK proof assumptions, note encryption, viewing keys, stealth addresses, and shielded state
Claim: X-Ray, deployed on Stellar mainnet, uses BN254 elliptic curve for zero-knowledge cryptography with Poseidon hash functions. BN254 pairings are vulnerable to Shor's algorithm.
Coverage basis: Quantum-vulnerable pairing-based ZK (BN254)
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: X-Ray uses BN254 pairing-based cryptography which is quantum-vulnerable. QPP acknowledges this as an open research challenge: 'Unlike signature schemes, there is no drop-in post-quantum replacement for pairing-based SNARKs with comparable performance.' Triggers Readiness & Risk Cap 70, but the more restrictive Cap 40 from Ed25519-only spend authorization is already binding.
Assurance: BN254 usage is confirmed by the official End of Year 2025 Report and the QPP itself. X-Ray is an opt-in privacy layer and does not affect core asset ownership or consensus.
Since X-Ray is opt-in and does not threaten core asset ownership or consensus, the BN254 vulnerability does not create an additional Readiness & Risk Cap beyond those already applied for Ed25519. It does reduce the Production Cryptographic Protection category score for the privacy subfactor.
Production Cryptographic Protection
P2P transport, node identity, and peer authentication are PQC, hybrid-PQC, or satisfied by design
Claim: Stellar's overlay network uses Ed25519 for node identity and peer authentication. No PQ upgrade exists.
Coverage basis: ECC-only P2P node authentication
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Ed25519 usage for P2P node identity is verifiable from stellar-core source code. P2P node identity compromise does not directly enable asset theft or consensus compromise — it is a secondary attack surface. The more restrictive caps from spend authorization and consensus are binding.
P2P node identity is a lower-severity quantum vulnerability compared to spend authorization and consensus. Node impersonation could enable eclipse attacks but cannot directly forge transactions or consensus messages without also breaking those Ed25519 signatures.
Production Cryptographic Protection
Critical wallet, custody, HSM, signer, and hardware-wallet workflows support the production PQ/hybrid path or are protected by native satisfied-by-design controls
Claim: No PQ signing path exists for any wallet, custody, or HSM workflow on Stellar. Hardware wallets support Ed25519 for Stellar but have no PQ capability.
Coverage basis: No PQ wallet/custody support exists
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: No evidence of any wallet, custody, or HSM supporting PQ signing for Stellar. QPP mentions HSM support for cloud deployment as a future consideration. This is expected given no PQ protocol support exists yet.
This subfactor cannot be meaningfully scored until PQ protocol support exists. Current score of 0.00 reflects that no wallet or custody workflow can protect against quantum attacks because the protocol itself has no PQ path.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected from quantum key-recovery attacks across all attack windows
Claim: 0% of the ~33.7B XLM circulating supply (~$6.6B market cap) is protected from quantum key-recovery attacks. All accounts use Ed25519 keys with public keys directly exposed in addresses.
Coverage basis: 0% value-at-risk protected — <25% coverage tier
Implementation score: 0.05 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: 0% of value-at-risk is protected. <25% coverage tier yields Implementation Score 0.05 (1/20). All ~$6.6B in circulating value is in the long-exposure attack window.
Assurance: Market cap and circulating supply data from CoinMarketCap and CoinGecko as of June 10, 2026. The 100% vulnerability claim is confirmed by the QPP's explicit acknowledgment and the Stellar protocol's address format specification.
Value-at-risk includes all circulating XLM plus all issued assets on the Stellar network. The SDF mandate holds approximately 20.8B XLM (per the Dashboard API), which is also fully Ed25519-dependent. Dormant accounts with unreachable holders represent a permanent vulnerable value pool with no defined mitigation.
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native, including treasuries, exchanges, custodians, bridges, foundations, and major protocols
Claim: No critical wallets — including SDF treasury, exchanges, custodians, anchors, or major protocol treasuries — have migrated to PQ protection. No migration path exists yet.
Coverage basis: 0% critical wallet migration
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: QPP states that enterprise wallets can begin migrating in 2026 through Soroban contract accounts, but this is a future capability. No critical wallet has migrated as of the evaluation date because no PQ path exists.
Once Stage 1 delivers ML-DSA host functions in Soroban, enterprise wallets using contract accounts could theoretically migrate. Stage 2 will extend this to classic accounts.
Migration Status & Value-at-Risk
Legacy vulnerable pools/accounts/UTXOs/contracts are identified, measurable, deprecated, migrated, frozen, or proven not to exist by design
Claim: QPP identifies dormant accounts and 100% exposed public keys as a major challenge but provides no measurement methodology, deprecation mechanism, freeze policy, or recovery path.
Coverage basis: Vulnerable pools identified but not measured or mitigated
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: QPP identifies the dormant account problem and commits to community discussion, but provides no analytics, measurement, or policy proposal. The acknowledgment is a necessary first step but does not constitute a measurable deprecation or migration path.
QPP notes: 'Stellar has a large population of dormant accounts whose holders are unreachable. Any forced cutoff requires freezing these accounts and must choose between providing a recovery mechanism (Stellar, unlike many other chains supports seed-based proofs), or accepting that they become permanently locked.'
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: QPP provides a 3-stage roadmap: Stage 1 (2026) — ML-DSA host functions in Soroban; Stage 2 (2027) — native PQ signer types for classic accounts; Stage 3 — Ed25519 deprecation timed to quantum threat.
Coverage basis: Detailed public roadmap with algorithm selection and staged timeline
Implementation score: 0.25 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: QPP is an official SDF publication with specific algorithm choices (ML-DSA-44, ML-DSA-65), concrete integration points (Soroban host functions, set_options for classic accounts), and staged timelines. However, detailed technical specifications and CAP proposals are not yet published. The roadmap score of 0.25 reflects 'Public design, draft specification, roadmap' per the implementation score table.
QPP's specificity sets it apart from vague quantum roadmaps. Naming specific NIST standards, integration mechanisms, and staged timelines demonstrates serious planning. The structural advantage of separating account identity from signing keys is correctly identified as the key enabler.
Migration Mechanism, Governance & Ecosystem Coordination
Migration accessibility and defaults: PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, and migration prompts
Claim: No PQ account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, or migration prompts exist on mainnet. All defaults are Ed25519-only.
Coverage basis: No PQ migration accessibility exists
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The absence of any PQ migration tooling is directly confirmed by the QPP which states these capabilities are planned for 2026-2027, not yet available.
Once Stage 2 delivers native PQ signer types, Stellar's architecture enables users to add PQ signers through the existing set_options operation without changing addresses. This is a genuine advantage but requires the signer type to exist first.
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and coordination: enforcement mechanisms exist and exchange, custody, bridge, wallet, and infrastructure coordination prevents unsafe fallback into vulnerable systems
Claim: No enforcement mechanisms exist — no deprecation, freeze, disabled legacy signing, restricted withdrawals, unsafe-path blocking, or mandatory migration deadlines.
Coverage basis: No enforcement mechanisms exist
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: QPP acknowledges that Stage 3 deprecation 'will require community input' and that dormant accounts present a challenge requiring 'community design discussion rather than presenting a unilateral decision.' No enforcement mechanism is proposed yet.
Enforcement mechanisms are premature at Stage 2 — they become relevant in Stage 3 when Ed25519 deprecation is activated. CAP-77 (Quorum Freeze) could potentially serve as an enforcement mechanism but has not been designed for quantum migration enforcement.
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: Stellar has a bug bounty program and CAP-77 (Quorum Freeze) is live on mainnet, providing a protocol-native emergency governance mechanism. No quantum-specific incident-response playbook exists.
Coverage basis: General emergency governance exists (CAP-77); no quantum-specific IR process
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: CAP-77 is live and operational (since May 2026). It enables validator-consensus-driven account freezes in minutes. However, it was designed for exploit response, not quantum emergencies. No quantum-specific IR playbook or governance framework has been published. QPP itself serves as a form of quantum-specific disclosure.
CAP-77 could potentially be used to freeze quantum-vulnerable dormant accounts or respond to a quantum emergency, but this application has not been designed, tested, or governance-approved. SDF also maintains a standard bug bounty program.
Algorithm & Implementation Assurance
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms appropriate to the use case
Claim: QPP selects ML-DSA-44 and ML-DSA-65 — NIST FIPS 204 standardized algorithms — with plans to add FN-DSA (Falcon) as standards are finalized.
Coverage basis: NIST-standardized algorithm selection in roadmap
Implementation score: 0.25 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: ML-DSA-44 and ML-DSA-65 are NIST FIPS 204 standards (finalized August 2024). The algorithm selection is appropriate and standards-track. However, no implementation exists to verify correct algorithm usage, parameter selection, or integration.
QPP's algorithm selection is conservative and appropriate: ML-DSA (FIPS 204) is the primary NIST signature standard. The commitment to adding Falcon (FN-DSA) demonstrates awareness of the broader PQC standards landscape.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit exists for the quantum-critical scope
Claim: No PQ-specific cryptographic or implementation audit exists. Existing audits (Veridise Aug 2025, OpenZeppelin Apr 2026) cover Soroban but not PQ cryptography.
Coverage basis: No PQ audit exists
Implementation score: 0 · Evidence confidence: High
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: Existing audits are high-quality but scope-mismatched for PQ. Veridise (Aug 2025) covered Soroban Core's Rust implementation with 35 person-weeks of review and fuzzing but did not evaluate PQ algorithms. OpenZeppelin (Apr 2026) reviewed Stellar Contracts v0.7.0 including smart accounts and governance but again not PQ. No PQ audit is possible because no PQ implementation exists yet.
Audit absence is expected at Stage 2. Once ML-DSA host functions are implemented in Soroban, a PQ-specific audit will be critical.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
Claim: Stellar Core and Soroban SDK are fully open-source (Apache 2.0). No PQ implementation exists yet to evaluate for reproducibility.
Coverage basis: Open-source codebase exists; no PQ implementation yet
Implementation score: 0 · Evidence confidence: High
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: The existing codebase is well-structured, open-source, and actively maintained. However, since no PQ code exists, the open-source and reproducibility subfactor cannot be meaningfully scored for PQ yet.
Once PQ host functions are implemented, the existing open-source infrastructure and build systems should support reproducibility.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path are documented
Claim: QPP explicitly plans to add additional schemes over time (FN-DSA/Falcon) and acknowledges the need for HSM support. Stellar's architecture separates signing from identity, facilitating algorithm agility.
Coverage basis: Documented future algorithm agility plan
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: The architectural separation of account identity from signing keys is a genuine advantage for algorithm agility — signers can be added, removed, and rotated via set_options without changing the account address. The QPP's commitment to adding Falcon demonstrates awareness of crypto-agility. However, no implemented agility mechanism exists yet.
Stellar's multi-signer account model with weighted thresholds already supports multiple signer types. Extending this to PQ signer types is architecturally natural.
Algorithm & Implementation Assurance
Stateful-signature safety, side-channel, fault-injection, state-management, hardware-wallet, HSM, or custody implementation risks are considered
Claim: ML-DSA is a stateless signature scheme, so stateful-signature risks (XMSS/LMS-style state management) do not apply. Side-channel and custody risks are not yet evaluated as no implementation exists.
Coverage basis: Stateless algorithm selection avoids stateful-signature risks; no implementation to evaluate
Implementation score: 0 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: ML-DSA is stateless, avoiding the state-management risks of XMSS/LMS. However, ML-DSA implementations have known side-channel considerations (particularly regarding signing randomness and fault injection). No implementation exists to evaluate.
Choosing ML-DSA (stateless) over XMSS/LMS (stateful) is a sound decision for blockchain applications where state management across distributed signers would be error-prone.
Algorithm & Implementation Assurance
Performance and resource-impact analysis exists where PQ signature/verification costs could affect safe deployment, block validation, gas/fee markets, mempool policy, archival growth, or validator/node hardware requirements
Claim: QPP acknowledges the challenge of larger PQ signature sizes for SCP consensus messages but provides no detailed analysis, benchmarks, or resource-impact modeling.
Coverage basis: Performance concern acknowledged but not analyzed
Implementation score: 0 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: ML-DSA-44 signatures are approximately 2.4 KB (vs 64 bytes for Ed25519) and ML-DSA-65 signatures are approximately 3.3 KB. This ~38-52x size increase has material implications for SCP message propagation, ledger storage, transaction fees, and bandwidth. The QPP acknowledges this concern but provides no analysis.
Performance analysis is premature at Stage 2 but will be essential before mainnet deployment. Stellar's 5-second ledger close time and SCP's message-passing architecture make signature verification latency and message size important considerations.
Report metadata