tokenized asset
Stellar XLM
Stellar scores QRI 5/100 (Stage 0: Unassessed / No Evidence). The Stellar Development Foundation has not published a quantum risk assessment, cryptographic inventory, or PQ migration roadmap. All production-critical cryptography—transaction signatures and SCP consensus authentication—relies exclusively on Ed25519, which is fully vulnerable to Shor's algorithm. Approximately $6.7B in circulating XLM plus over $2B in tokenized RWAs are secured by quantum-vulnerable signatures. The protocol's SHA-256 state-integrity hash chain is quantum-safe, providing immutable ledger history but no protection against theft or consensus compromise. A third-party experimental Falcon-512 Soroban contract is in development (SCF grant) and the SDF has mentioned post-quantum security as a future consideration, but neither constitutes production protection. Stellar's Ed25519 seed-based key derivation (RFC 8032) provides a structural advantage for potential future ZK-based migration without address changes, distinguishing it favorably from ECDSA chains, but this remains a research finding with no deployed implementation.
Roadmap OnlyPartial ProtectionNot Assessed
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
4.44 / 20
Migration Mechanism, Governance & Ecosystem Coordination
0.75 / 15
Migration Status & Value-at-Risk
1 / 25
Production Cryptographic Protection
6.56 / 35
Security Assessment & Evidence Preparedness
0 / 5
Critical Quantum Blockers
- No public cryptographic inventory or quantum risk assessment published by the Stellar Development Foundation. Critical public-key mechanisms (Ed25519 for transactions, Ed25519 for SCP consensus) are documented in open-source code and specs but have not been formally inventoried in a quantum-threat context.
- All production spend authorization (transaction signatures) uses Ed25519 exclusively—fully quantum-vulnerable to Shor's algorithm. ~$6.7B+ in circulating XLM market cap, plus tokenized RWAs exceeding $2B, are secured by quantum-vulnerable signatures.
- Stellar Consensus Protocol (SCP) validator/node authentication uses Ed25519 signatures for all consensus messages (SCPEnvelope). A quantum adversary capable of running Shor's algorithm could forge consensus messages and compromise network finality.
- No PQ migration roadmap, Core Advancement Proposal (CAP), timeline, or technical specification exists. The SDF has acknowledged post-quantum security as a future priority but has published no concrete plan.
Key Risks
- Quantum key-recovery attack (Shor's algorithm): An adversary with a CRQC can recover Ed25519 private keys from public keys exposed in Stellar transactions, enabling theft of all XLM and tokenized assets from accounts that have ever signed a transaction.
- Consensus compromise: SCP validator node identities use Ed25519. A quantum adversary could forge SCPEnvelope signatures to manipulate consensus, potentially causing network halt, double-spends, or invalid state finalization.
- No migration path: Even if the protocol were upgraded tomorrow to support PQ signatures, there is no mechanism to migrate existing Ed25519 accounts. Accounts that have exposed their public keys (all accounts that have transacted) would remain vulnerable indefinitely unless a ZK-based seed-proof migration path (per IACR 2025/1368) is implemented.
- Tokenized RWA exposure: Over $2B in tokenized real-world assets (Franklin Templeton BENJI, Spiko EU T-Bills, etc.) on Stellar inherit the same Ed25519 vulnerability. High-value institutional assets are secured by quantum-vulnerable signatures with no migration plan.
- Dormant and lost accounts: Like all Ed25519-based chains, Stellar faces the problem of accounts whose owners have lost keys or are otherwise unable to migrate. These accounts would become trivially exploitable targets once Shor-capable quantum computers exist, with no protocol-level defense mechanism currently designed.
Assurance Notes
- Stellar Core and Soroban have been audited by Veridise (2025), Runtime Verification (2024), and OpenZeppelin (2025-2026), but none of these audits cover post-quantum cryptography because no PQC is implemented in production. These audits are assurance-relevant for general implementation quality but provide zero quantum-specific assurance.
- The protocol's PublicKey union type in the SCP specification includes cryptographic agility—the XDR schema supports future key types beyond Ed25519—but this agility has never been exercised for a PQC algorithm and no PQ key type has been defined or deployed.
- Stellar's Ed25519 key derivation (RFC 8032) uses seed-based deterministic derivation, which the 2025 IACR paper by Baldimtsi et al. identifies as a structural advantage for potential ZK-based post-quantum migration without address changes. This is a research finding, not a deployed or planned protocol feature, but it represents a meaningful structural advantage over ECDSA chains for future migration.
- SoundnessLabs received a $150K Stellar Community Fund grant (SCF #40) to deploy Falcon-512 signature verification as a Soroban smart contract. As of the evaluation date, this is in development/testnet phase and does not protect native XLM balances or consensus. It is a third-party effort, not an SDF-led protocol upgrade.
- The SDF 2025 Year in Review mentions 'post-quantum security' as a future consideration alongside agentic payments, but no CAP, timeline, working group, or technical specification has been published.
- Stellar's state-integrity hash chain uses SHA-256, which is quantum-safe (Grover's algorithm provides only quadratic speedup for hash preimages). This means ledger history cannot be retroactively forged by a quantum adversary, though active consensus and spend authorization remain fully vulnerable.
- Stellar has a documented security vulnerability disclosure and release process (security-protocol-release-notes.md), a bug bounty program, and demonstrated incident-response capability (e.g., recent Protocol 26 Yardstick/CAP-77 Quorum Freeze for asset containment). No quantum-specific incident-response playbook exists, but the general security infrastructure is operational.
Non-Scoring Caveats
- Stellar's Ed25519 RFC-8032 seed-based key derivation provides a structural advantage for potential future ZK-based migration without address changes (per IACR 2025/1368), but this is a theoretical research finding with no deployed protocol implementation. It does not reduce current quantum vulnerability.
- The SoundnessLabs Falcon-512 Soroban contract (SCF #40 grant) may reach mainnet deployment later in 2026, but even if deployed, it would only enable application-layer account abstraction for opt-in PQ signatures—it would not protect native XLM accounts, consensus, or the base protocol.
- Stellar's recent Protocol 25 (X-Ray) added BN254 pairing-friendly curve support for ZK applications. BN254 pairings are quantum-vulnerable, meaning ZK proof systems relying on BN254-based Groth16/PLONK verifiers on Stellar would be quantum-vulnerable at the application layer. This is an application concern, not a base-protocol vulnerability, but relevant for the ecosystem's ZK application security.
- No Stellar-specific quantum exposure dataset (analogous to the XRPL quantum exposure dataset by xVet) exists publicly. The percentage of XLM in accounts with exposed public keys (accounts that have signed transactions) is not systematically measured. Given Stellar's account model requires on-chain signature for most operations, exposure is likely very high.
- Stale but relevant audits (Veridise 2025, Runtime Verification 2024) cover Soroban and Stellar Core implementation quality but provide no quantum-specific assurance. This is recorded as a confidence limitation, not a score reduction, because the quantum-vulnerable Ed25519 implementation itself is not in question.
Evidence record
Claims and Caveats
Security Assessment & Evidence Preparedness
Public cryptographic inventory and quantum threat model
Claim: No public cryptographic inventory or quantum threat model has been published by the Stellar Development Foundation. Cryptographic mechanisms are documented in open-source code and protocol specifications but have not been formally inventoried in a quantum-threat context.
Coverage basis: Absence of published inventory
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No public cryptographic inventory or quantum risk assessment published
Assurance: The absence is confirmed by exhaustive search of stellar.org, GitHub stellar organization, SCP specification, and protocol documentation. The SDF 2025 Year in Review contains a single mention of 'post-quantum security' as a future priority with no supporting detail.
The cryptographic primitives are verifiable from public code and specs: Ed25519 for transactions and consensus, SHA-256 for state hashing. The gap is the lack of a structured inventory and threat model, not opacity of the cryptography itself.
Security Assessment & Evidence Preparedness
Public evidence record supporting quantum assessment
Claim: No quantum-specific evidence record (code references, specs, audits, transaction examples, or reproducible analytics focused on quantum risk) has been published by SDF.
Coverage basis: Absence of quantum-specific evidence record
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: General code and spec documentation exists but none is quantum-specific. Third-party analyses (Circle, EternaX, LayerQu, Project Eleven) provide quantum exposure assessments but these are not SDF-published evidence.
Third-party analyses confirm Ed25519 quantum vulnerability and critical risk rating, but the QRI category rewards project-published evidence, not external research.
Production Cryptographic Protection
Spend authorization / transaction signatures
Claim: All Stellar transaction signatures use Ed25519 exclusively. No PQC or hybrid-PQ signature scheme is available on mainnet. CAP-0051 confirms Ed25519 and ECDSA secp256r1 are the only supported signature types.
Coverage basis: Ed25519-only signatures in production
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All spend authorization uses Ed25519—fully quantum-vulnerable
Assurance: Primary source confirmation from official Stellar docs and CAP-0051. Ed25519 is vulnerable to Shor's algorithm; this is cryptographically well-established.
No hybrid-PQ, no optional PQ, no PQ testnet for native transactions. The SoundnessLabs Falcon-512 Soroban contract is a third-party experimental application-layer prototype, not a protocol-level signature scheme.
Production Cryptographic Protection
Account, address, public-key exposure and key-derivation design
Claim: Stellar accounts use Ed25519 public keys as account identifiers. Any account that has signed a transaction has its public key permanently exposed on-ledger. Stellar's account model requires on-chain signatures for most operations, making key exposure nearly universal for active accounts.
Coverage basis: Long-exposure Ed25519 public keys
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Stellar's RFC-8032 seed-based key derivation means the seed (not the scalar) is the root secret. Per IACR 2025/1368, this could enable ZK-based PQ migration without address changes. This is a structural advantage over ECDSA chains but does not reduce current quantum vulnerability—the exposed public key still allows scalar recovery via Shor's algorithm.
No systematic measurement of exposed vs. unexposed accounts exists for Stellar. Given the account model, exposure is likely very high (>90% of active accounts). The IACR 2025/1368 paper lists Stellar among EdDSA chains with favorable migration properties.
Production Cryptographic Protection
Consensus-critical authentication (validator signatures, SCP)
Claim: The Stellar Consensus Protocol (SCP) uses Ed25519 signatures for all consensus messages. Nodes sign SCPEnvelope structures (PREPARE, COMMIT, EXTERNALIZE, NOMINATE) with Ed25519. The SCP specification (IETF draft-mazieres-dinrg-scp) confirms Ed25519 as the sole signature algorithm for validator authentication.
Coverage basis: Ed25519-only consensus signatures
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: SCP consensus authentication uses Ed25519—fully quantum-vulnerable
Assurance: Primary source: SCP specification confirms Ed25519 for digital signatures with PublicKey union type supporting future extensibility. The PublicKeyType enum currently only defines PUBLIC_KEY_TYPE_ED25519 = 0.
SCP is a federated Byzantine agreement protocol. Each node's identity is its Ed25519 public key. A quantum adversary that recovers a validator's private key could forge SCP messages, potentially disrupting consensus quorums, causing forks, or finalizing invalid state. The SCP spec explicitly notes cryptographic agility via the union type but no PQ type has been defined.
Production Cryptographic Protection
State-integrity and data-availability mechanisms
Claim: Stellar's ledger state integrity relies on SHA-256 hashing. The SCP specification uses SHA-256 for quorum set hashing and slot value hashing. SHA-256 is quantum-safe (Grover's algorithm provides only quadratic speedup for preimage attacks, leaving effective security at 128 bits). There are no KZG commitments, pairings, or other quantum-vulnerable primitives in the base protocol's state-binding mechanism.
Coverage basis: SHA-256 hash-based state integrity, satisfied by design
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: SHA-256's post-quantum security is well-established. Grover's algorithm reduces effective preimage security from 256 to 128 bits, which remains computationally infeasible. The hash chain cannot be retroactively forged.
This is the only quantum-safe critical layer in Stellar's base protocol. Ledger history integrity is protected, but this does not prevent theft of assets via quantum key-recovery attacks on Ed25519 spend authorization or consensus manipulation.
Production Cryptographic Protection
Privacy and proof layers
Claim: Stellar is a transparent blockchain with no native privacy layer. Protocol 25 (X-Ray) added BN254 pairing-friendly curve and Poseidon hash function support for application-layer ZK proofs, but the base protocol has no shielded transactions, stealth addresses, or private state.
Coverage basis: No native privacy layer
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: BN254 pairings are quantum-vulnerable. Application-layer ZK proofs verified via BN254 precompiles on Stellar would be quantum-vulnerable, but this affects the application, not the base protocol.
N/A for base protocol scope. Ecosystem note: applications using BN254-based Groth16/PLONK verifiers on Stellar should be aware of quantum vulnerability of pairing-based proof systems.
Production Cryptographic Protection
P2P transport, node identity, and peer authentication
Claim: Stellar nodes identify themselves by their Ed25519 public key. P2P communication between nodes uses the same Ed25519 keys that are used for SCP consensus messages. Node identity is consensus-critical—the same keys sign SCPEnvelope messages.
Coverage basis: Ed25519 node identity (consensus-critical)
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Node identity uses the same Ed25519 keys as consensus authentication (subfactor above). The vulnerability is captured under both subfactors but represents the same cryptographic primitive. P2P transport itself uses standard TCP/XDR without additional cryptographic layer.
P2P node identity is consensus-critical on Stellar because node keys sign SCP messages. The QRI spec's 'satisfied by design' exception for P2P requires that network identity not be consensus, spend, bridge, or custody-critical. Stellar's node identity IS consensus-critical, so the exception does not apply.
Production Cryptographic Protection
Critical wallet, custody, HSM, and hardware-wallet workflows
Claim: No Stellar wallet, custody solution, HSM, or hardware wallet supports PQ or hybrid-PQ signatures. All wallet software (Lobstr, Solar, Ledger Stellar app, etc.) uses Ed25519 exclusively.
Coverage basis: No PQ wallet support
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: No systematic survey of Stellar wallet PQ support was conducted. The absence of any PQ signature scheme at protocol level makes PQ wallet support logically impossible.
Wallet support cannot exist until the protocol supports PQ signatures. This subfactor will remain 0 until protocol-level PQ signature support is deployed.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected
Claim: 0% of Stellar's circulating value is protected from quantum key-recovery attacks. All ~$6.7B in circulating XLM (~33.5B XLM) plus over $2B in tokenized RWAs on Stellar are secured exclusively by Ed25519 signatures. No PQ protection exists at any layer for any value.
Coverage basis: <25% coverage (effectively 0%)
Implementation score: 0.05 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: ~$6.7B+ circulating value with 0% quantum protection
Assurance: Market cap figures vary across sources ($4.8B–$8.7B depending on price and source). CoinGecko reports $6.74B as of 2026-06-05. Tokenized RWA figures from SDF Q1 2026 report: >$2B on-chain. Exact exposure percentage by account public-key visibility is not systematically measured for Stellar, but given the account model, effectively 100% of liquid value is in accounts with exposed keys.
Coverage threshold: <25% earns 1 point (out of 20) per QRI 9.3.1 table. Actual coverage is 0%, which maps to the <25% bucket. Score: 1/20 = 0.05 Implementation Score equivalent.
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native
Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) on Stellar are PQ-protected. All use Ed25519 signatures. SDF-controlled wallets, exchange hot/cold wallets, and institutional custody (Franklin Templeton, etc.) are all quantum-vulnerable.
Coverage basis: 0% of critical wallets protected
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: No comprehensive registry of Stellar critical wallets exists. The assessment is based on the absence of any PQ signature support at protocol level, which makes PQ-protected wallets impossible.
Even if individual wallets wanted to implement PQ protection, they cannot do so at the protocol level without a CAP and network upgrade. Application-layer account abstraction via Soroban (e.g., SoundnessLabs Falcon) could theoretically enable opt-in PQ for smart-contract wallets but would not protect native Ed25519 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: No systematic identification, measurement, deprecation, migration, freeze, or burn mechanism exists for quantum-vulnerable Stellar accounts. There is no public dataset classifying Stellar accounts by quantum exposure status.
Coverage basis: No legacy pool identification
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Unlike XRPL which has a comprehensive quantum exposure dataset (xVet, 7.81M accounts classified), no equivalent exists for Stellar. The absence of such measurement is itself a readiness gap.
A Stellar quantum exposure dataset would need to classify accounts by whether their Ed25519 public key has been revealed on-chain (i.e., whether the account has ever signed a transaction). Given Stellar's account model, virtually all active accounts would be classified as exposed.
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: No PQ migration roadmap, CAP, timeline, or technical specification exists. The SDF 2025 Year in Review mentions 'post-quantum security' as a future priority alongside agentic payments but provides no detail. Founder Jed McCaleb has publicly acknowledged the quantum threat and noted the protocol's crypto agility, but no formal plan has been published.
Coverage basis: No roadmap published
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No PQ migration roadmap or CAP exists
Assurance: The absence of a roadmap is confirmed by searching all Stellar CAPs (0001-0077), the stellar-protocol repository, and SDF publications. No CAP references post-quantum cryptography.
The founder's acknowledgment of crypto agility and the PublicKey union type in the SCP spec constitute awareness but not a roadmap. Roadmap requires sequencing, activation criteria, and dependencies per QRI 9.4.
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 are available, default, strongly preferred, mandatory, or complete by design
Claim: No PQ or hybrid-PQ account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, or migration prompts exist. Ed25519 remains the only option for account creation and transaction signing.
Coverage basis: No migration accessibility
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The SoundnessLabs Falcon-512 Soroban contract (SCF #40, in development) aims to provide optional PQ signature verification via account abstraction, but this is not yet deployed on mainnet and would require explicit user opt-in via smart-contract wallets.
Migration accessibility cannot exist before protocol-level PQ signature support. Third-party application-layer solutions cannot provide default protection for native Ed25519 accounts.
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and coordination: enforcement mechanisms exist (such as deprecation, freeze, disabled legacy signing, restricted withdrawals, unsafe-path blocking, or mandatory migration after a deadline) and exchange, custody, bridge, wallet, and infrastructure coordination prevents unsafe fallback into vulnerable systems
Claim: No enforcement mechanisms (deprecation, freeze, disabled legacy signing, restricted withdrawals, unsafe-path blocking, mandatory migration deadlines) exist. No exchange, custody, bridge, wallet, or infrastructure coordination for PQ migration has occurred.
Coverage basis: No enforcement or coordination
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Stellar has demonstrated protocol upgrade coordination capability (Protocol 25 X-Ray, Protocol 26 Yardstick), suggesting the governance infrastructure exists for future migration coordination, but no quantum-specific coordination has occurred.
Protocol 26 (Yardstick) introduced CAP-77 Quorum Freeze for rapid asset containment, which could theoretically be adapted for quantum emergency response, but this is speculative and not designed for quantum scenarios.
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: Stellar has a documented security vulnerability disclosure process, bug bounty program, and security release tracking (security-protocol-release-notes.md). No quantum-specific incident-response playbook exists, but the general security infrastructure is operational.
Coverage basis: General security process exists; no quantum-specific adaptation
Implementation score: 0.25 · Evidence confidence: High
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: The security release notes document demonstrates a mature vulnerability management process with regular releases, CVE-style tracking, and mitigation documentation. Protocol 26 (Yardstick) introduced CAP-77 Quorum Freeze for rapid validator-coordinated asset containment, showing governance capability for emergency response. No quantum-specific adaptation exists.
Scored 0.25 (public design/roadmap level) because general security infrastructure exists and could be adapted, but no quantum-specific IR playbook, tabletop exercise, or disclosure procedure has been developed. The gap between general and quantum-specific preparedness is material.
Algorithm & Implementation Assurance
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms appropriate to the use case
Claim: No NIST-standardized or broadly reviewed PQC algorithms are used in production. The only PQC work is the third-party SoundnessLabs Falcon-512 (NIST-standardized) Soroban contract, which is experimental/development-phase and not protecting production value.
Coverage basis: No PQC algorithms in production
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Falcon-512 is a NIST-standardized (FIPS 204 alternative) lattice-based signature scheme. SoundnessLabs' experimental implementation has not been independently audited and is not production-grade. No NIST PQC signature scheme (ML-DSA, SLH-DSA, Falcon, XMSS/LMS) is deployed in Stellar's production protocol.
The SoundnessLabs work demonstrates technical feasibility of Falcon-512 on Soroban and represents the closest thing to PQC activity in the Stellar ecosystem, but it is a third-party experiment, not protocol-level protection.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit exists for the quantum-critical scope; audit freshness and scope fit are reflected in Confidence
Claim: No quantum-specific cryptographic audit exists because no PQC is implemented. Existing audits (Veridise 2025, Runtime Verification 2024, OpenZeppelin 2025-2026) cover Soroban and Stellar Core but do not evaluate quantum security.
Coverage basis: No quantum-specific audit
Implementation score: 0 · Evidence confidence: High
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: Veridise (2025) and Runtime Verification (2024) conducted thorough audits of Soroban and Stellar Core covering metering, authorization, state handling, and fuzz testing. These audits confirm implementation quality of classical cryptography but provide zero quantum-specific assurance. OpenZeppelin audits cover the Stellar Contracts library at application layer.
Score is 0 because there is no quantum-critical implementation to audit. If/when PQC is implemented, these existing audit relationships provide a foundation for future quantum-specific review.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
Claim: Stellar Core is fully open-source (Apache 2.0 license) on GitHub. The protocol specification (SCP IETF draft) is publicly documented. Builds are reproducible and the codebase is actively maintained.
Coverage basis: Fully open-source codebase
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: The open-source nature of Stellar Core enables independent verification of cryptographic implementation. This is a strength for future PQC implementation auditability.
Full credit for open-source implementation. This does not compensate for the absence of PQC but means that if/when PQC is implemented, it will be publicly verifiable.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path are documented
Claim: The SCP specification defines PublicKey as a union type with extensible PublicKeyType enum, explicitly designed for cryptographic agility. The protocol has demonstrated upgrade capability through regular protocol version bumps (currently Protocol 26). No PQ-specific upgrade path is documented.
Coverage basis: Protocol-level crypto agility in design
Implementation score: 0.5 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: The PublicKey union type and PublicKeyType enum provide a clean extension point for adding PQ key types (e.g., PUBLIC_KEY_TYPE_FALCON_512). The protocol has demonstrated 26 successful version upgrades. However, no PQ key type has been defined, tested, or deployed, and the full migration path (address format, signature size implications, transaction fee impact) is unexplored.
Scored 0.50 (prototype/testnet equivalent for agility design). The agility infrastructure exists in protocol design and has been exercised for non-PQ upgrades, but has never been used for a PQ transition. The gap between 'agility exists' and 'PQ upgrade path is documented and tested' is significant.
Algorithm & Implementation Assurance
Stateful-signature safety (where applicable), side-channel, fault-injection, state-management, hardware-wallet, HSM, or custody implementation risks are considered, including anti-reuse controls and signing-state discipline for XMSS/LMS-style schemes
Claim: Ed25519 is a stateless signature scheme. No stateful PQC signatures (XMSS/LMS) are used. Stateful signature safety considerations are not applicable to the current production system.
Coverage basis: No stateful signatures in use
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
N/A for current evaluation. If Stellar adopts a stateful hash-based signature scheme (e.g., XMSS/LMS for validator keys), this subfactor will become applicable and critical.
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: No PQ performance or resource-impact analysis has been published by SDF. The SoundnessLabs SCF grant includes gas optimization milestones for Falcon-512 on Soroban, but this is third-party and application-specific, not a protocol-level analysis.
Coverage basis: No PQ performance analysis
Implementation score: 0 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: The SoundnessLabs Falcon-512 Soroban contract includes gas optimization as a deliverable, and founder Jed McCaleb noted that PQ signature sizes are 'too large currently' as a reason for delay. This suggests awareness of the performance challenge but no formal protocol-level analysis.
PQ signature sizes (Falcon-512: ~666-1280 bytes; ML-DSA-65: ~3309 bytes; SLH-DSA: ~7856+ bytes) are significantly larger than Ed25519's 64-byte signatures. A protocol-level analysis of transaction size impact, fee market implications, ledger growth, and validator hardware requirements is essential before migration planning can begin.
Report metadata