XRP Ledger XRP

Claim: XRPL has published a comprehensive cryptographic inventory (secp256k1 ECDSA and Ed25519 signing algorithms, AccountID derivation via RIPEMD-160(SHA-256(pk))) and Ripple published a detailed quantum threat model covering affected assets and layers via the April 2026 roadmap blog and XLS-295 specification.

Coverage basis: Documented production cryptographic mechanisms and public threat model

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Primary protocol documentation and source code directly verify the cryptographic inventory. Threat model is from an official Ripple blog and XLS-295 specification; not an independent audit but comprehensive in scope.

XLS-295 explicitly enumerates all signing surfaces affected by quantum threat: validator manifests, validations, consensus proposals, UNL publisher signatures, peer-to-peer handshakes, node identities, and account-level transaction signing.

• https://xrpl.org/docs/concepts/accounts/cryptographic-keys
• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/
• https://github.com/XRPLF/XRPL-Standards/discussions/295

Claim: Public evidence includes official XRPL.org docs, XLS-295 formal specification (Draft, updated 2026-05-20), AlphaNet testnet running ML-DSA since Dec 2025, IEEE BCCA 2025 paper, rippled PR #6971 (PQC readiness tests), and validator Vet's ledger-wide quantum vulnerability audit.

Coverage basis: Code references, specifications, testnet evidence, and published analytics

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Evidence is comprehensive and publicly verifiable. Includes primary source code, formal XLS specification, academic paper, and independent ledger analysis. No independent PQ-specific audit exists, which limits Confidence to Medium for production readiness but does not reduce the evidence preparedness score.

Evidence record is unusually strong for a project without production PQ protection. Full credit for assessment preparedness.

• https://github.com/XRPLF/XRPL-Standards/discussions/295
• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/
• https://github.com/XRPLF/rippled/pull/6971
• https://cryptorank.io

Claim: Mainnet transaction signatures and payment channels rely exclusively on secp256k1 ECDSA and Ed25519. No PQC or hybrid-PQC spend authorization path exists on mainnet. AlphaNet has ML-DSA-44 for transaction signing but this is testnet-only and not merged into canonical rippled upstream.

Coverage basis: Classical-only production spend authorization

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Active production spend authorization remains entirely ECC/EdDSA-only (secp256k1 and Ed25519) on mainnet; no PQC or hybrid-PQC transaction signature path exists. Applies Readiness & Risk Cap of 40.

Assurance: Primary docs, source code, and XLS-295 specification directly verify the ECC/EdDSA-only production state. XLS-295 explicitly states 'Accounts that continue to sign with secp256k1 or Ed25519 retain their pre-quantum exposure.'

This is the binding quantum-critical vulnerability. The Stage 2 cap (40) and 'active production spend authorization remains entirely ECC/EdDSA-only' Readiness & Risk Cap (40) both apply.

• https://xrpl.org/docs/concepts/accounts/cryptographic-keys
• https://xrpl.org/docs/concepts/payment-types/payment-channels
• https://github.com/XRPLF/rippled
• https://github.com/XRPLF/XRPL-Standards/discussions/295

Claim: XRPL account IDs are double-hashed (RIPEMD-160(SHA-256(publicKey))), keeping public keys unexposed until an account sends its first transaction. Native RegularKey rotation allows key updates without moving funds. However, all accounts that have sent at least one transaction have permanently exposed public keys on-chain, and no PQ/hybrid controls exist.

Coverage basis: Hash-based address derivation with native key rotation (classical mitigation, not PQ protection)

Implementation score: 0.25 · Evidence confidence: High

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

Assurance: Source code and independent ledger analysis verify the double-hash design and its effect on dormant-account exposure. CryptoRank estimates only ~0.03% of circulating supply is in dormant accounts with exposed public keys.

Partial credit (0.25) for a meaningful design mitigation that reduces long-exposure attack surface for dormant receive-only accounts and native key rotation provides structural migration advantage. Not PQ protection: active accounts remain exposed.

• https://github.com/XRPLF/rippled/blob/5b6e8b6f93b19c1e3f6a3467a25639031d9d9a53/src/libxrpl/protocol/AccountID.cpp
• https://github.com/XRPLF/XRPL-Standards/discussions/420
• https://cryptorank.io
• https://xrpl.org/docs/concepts/accounts/cryptographic-keys

Claim: Validator manifests, validations, consensus proposals, and UNL publisher signatures use classical secp256k1/Ed25519 signing keys on mainnet. XLS-295 confirms the validator signing surface uses the same classical key types and would introduce dilithium only under the future 'Quantum' amendment.

Coverage basis: Classical-only consensus authentication on mainnet

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Consensus-critical validator authentication remains classical on mainnet.

Assurance: The exact validator signature algorithm is inferred from account-level key types and XLS-295's description of the signing surface; primary docs enumerate 33-byte secp256k1 and 32-byte+prefix Ed25519 public keys for validators. XLS-295 confirms dilithium would be gated behind the future 'Quantum' amendment.

XRPL's federated-consensus model (UNL-based trust) provides some structural resilience vs. pure cryptographic consensus (e.g., PoS with BLS), but a quantum adversary could still forge validator signatures to propose invalid ledgers.

• https://xrpl.org/docs/concepts/consensus-protocol/consensus-principles-and-rules
• https://xrpl.org/docs/references/http-websocket-apis/peer-port-methods/validator-list
• https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md
• https://github.com/XRPLF/XRPL-Standards/discussions/295

Claim: XRPL uses hash-based ledger hashing (SHA-512Half family) and transaction Merkle trees for state integrity. No KZG commitments, pairings, nullifiers, or quantum-vulnerable public-key-dependent state-binding mechanisms exist in the protocol.

Coverage basis: Hash-based state integrity (quantum-safe by design)

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Verifiable from protocol specification, source code, and official documentation. No independent audit specifically verifies the absence of hidden quantum-vulnerable state-binding primitives, but the protocol is well-documented and extensively reviewed.

State integrity is quantum-safe by design. This does not extend to transaction authorization or consensus authentication, which remain classical and are scored separately.

• https://xrpl.org/docs/references/protocol/binary-format
• https://xrpl.org/docs/concepts/consensus-protocol/consensus-principles-and-rules

Claim: XRPL has no native shielded transactions, ZK proof system, note encryption, or stealth-address privacy layer in production. Confidential Transfers for MPTs are mentioned in Ripple's roadmap as future R&D exploration.

Coverage basis: No privacy/proof layer exists in production

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: N/A marked per QRI applicability rules because the architectural layer genuinely does not exist in production.

Ripple's roadmap mentions exploring post-quantum-friendly ZK proofs and homomorphic encryption for future Confidential Transfers (MPTs), but this is forward-looking R&D, not a current production feature.

• https://xrpl.org/docs/concepts/accounts/cryptographic-keys

Claim: P2P node identity and peer handshake authentication use classical cryptography (secp256k1/Ed25519). XLS-295 proposes adding dilithium for peer handshakes and node identities but this is not active on mainnet.

Coverage basis: Classical-only P2P identity

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: XLS-295 confirms peer handshakes and node identities use the same classical key types and would become dilithium-capable only under the 'Quantum' amendment. Classified as operational/product caveat because P2P identity compromise does not directly enable asset theft, though it could enable eclipse or network disruption.

P2P node identity compromise could enable network-level attacks (message injection, Sybil) but is not directly spend-critical. Classified as operational/product caveat rather than quantum-critical vulnerability.

• https://xrpl.org/docs/infrastructure/configuration/server-modes/run-xrpld-as-a-validator
• https://github.com/XRPLF/XRPL-Standards/discussions/295

Claim: No production PQ wallet, custody, or HSM workflow exists on mainnet. All existing custody infrastructure uses classical secp256k1/Ed25519. Project Eleven is named as a partner for early custody prototyping but no deliverables are publicly available.

Coverage basis: No production PQ custody path

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Project Eleven custody prototype is future work, not a production artifact. No public evidence of PQ-capable custody or wallet tooling for XRPL mainnet.

Recorded as confidence-only caveat because the underlying account control path is already ECC/EdDSA-vulnerable and scored under spend authorization. XRPL's native key rotation (SetRegularKey) provides a structural advantage for future custody migration.

• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/
• https://www.projecteleven.com/blog/project-eleven-collaborates-with-ripple-to-secure-xrp-ledger-for-the-quantum-era

Claim: No mainnet PQ protection exists; zero percent of XRP value is protected by PQC. Double-hashed addresses protect dormant receive-only accounts from long-exposure key recovery, but this is a structural design property, not PQC protection. All actively transacted XRP has exposed classical public keys.

Coverage basis: Negligible PQ protection on mainnet; structural design mitigation for dormant accounts

Implementation score: 0.05 · Evidence confidence: Medium

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

Quantum blocker: No mainnet PQ protection exists; value-at-risk coverage is <25%.

Assurance: Value-at-risk figures rely on CryptoRank analysis and validator Vet's ledger audit (secondary/medium confidence). Only ~0.03% of supply is in dormant accounts with exposed keys, but active supply remains fully vulnerable on-spend. The <25% threshold for PQ-protected value applies.

Maps to <25% coverage (experimental/negligible protection) per Section 9.3.1. Implementation Score 0.05 reflects negligible PQ coverage with awareness of structural design advantages. PK hashing is a classical mitigation, not PQ protection.

• https://cryptorank.io
• https://xrpl.org/docs/concepts/accounts/cryptographic-keys
• https://github.com/XRPLF/XRPL-Standards/discussions/420

Claim: No evidence that any treasury, exchange, custodian, bridge, foundation, or major protocol-controlled wallet on XRPL has migrated to or supports PQC signing keys.

Coverage basis: No critical wallet migration

Implementation score: 0 · Evidence confidence: Low

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

Assurance: No public evidence of any PQ wallet migration on XRPL mainnet. Cannot verify absence of private migration efforts, but no PQ signing path exists on mainnet anyway.

Absence of evidence is treated as no migration. This is a quantum-critical uncertainty because critical wallet migration status cannot be verified and no PQ path is available.

Claim: XRPL's PK hashing design prevents creation of new long-exposure accounts by default (public keys unexposed until first spend). Validator Vet's ledger audit identified ~21M XRP (0.03% of supply) in dormant accounts with exposed keys and ~2.4B XRP across ~300k receive-only accounts. No formal deprecation, freeze, or migration policy exists for exposed dormant accounts.

Coverage basis: Partially identified legacy exposure with structural design mitigation but no remediation policy

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: Dormant exposed account estimate (~21M XRP, 0.03%) is from CryptoRank third-party analysis corroborated by validator Vet's independent ledger audit. Not independently verified against mainnet ledger state in this evaluation.

Score of 0.25 reflects that the protocol design structurally prevents new long-exposure accounts (PK hashing), the dormant exposed pool is partially identified and measurable, but no deprecation, freeze, burn, or migration policy exists for the identified vulnerable value.

• https://cryptorank.io
• https://xrpl.org/docs/concepts/accounts/cryptographic-keys
• https://github.com/XRPLF/XRPL-Standards/discussions/420

Claim: Ripple published a 4-phase roadmap (April 2026): Phase 1 Q-Day recovery contingency, Phase 2 experimentation (H1 2026), Phase 3 Devnet integration (H2 2026), Phase 4 full transition (targeting 2028). XLS-295 provides a formal specification with amendment gating, sequencing, and dependencies.

Coverage basis: Published roadmap with formal specification

Implementation score: 0.75 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Roadmap is published with named dates and phases. XLS-295 is a formal specification (Draft status, updated 2026-05-20) with detailed implementation guidance. Roadmaps are not production protection and timelines may shift.

Score of 0.75 reflects a well-documented public roadmap with formal specification, named phases, and timelines. Not scored at 1.00 because the roadmap remains at the design/planning stage and has not reached default/mandatory/enforced implementation.

• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/
• https://github.com/XRPLF/XRPL-Standards/discussions/295

Claim: XRPL supports native key rotation (SetRegularKey) and multi-signing (SignerListSet, 1-32 signers), providing structural migration infrastructure. However, no PQ account creation, PQ wallet tooling, PQ custody paths, or user-facing migration prompts exist on mainnet. AlphaNet has ML-DSA key generation but this is not available to mainnet users.

Coverage basis: Structural migration primitives exist but no PQ-specific tooling on mainnet

Implementation score: 0.25 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Key rotation and multi-signing are verifiable from official docs and source code. XLS-295 notes that 'exchanges, wallets, and custodians SHOULD provide rotation tooling' but none exists yet.

Score of 0.25 reflects that structural migration primitives (key rotation, multi-sig) exist and are well-documented, but no PQ-specific migration tooling, wallet support, or user-facing prompts are available on mainnet.

• https://xrpl.org/docs/concepts/accounts/cryptographic-keys
• https://github.com/XRPLF/XRPL-Standards/discussions/295

Claim: No enforcement mechanism exists for PQ migration. Classical signatures will remain valid indefinitely. XLS-295 proposes an additive amendment (new key type alongside existing schemes) rather than mandatory replacement. Ripple's Phase 4 mentions 'enforcing a hard shift' where classical signatures are no longer accepted, but this is a future contingency concept, not a current mechanism.

Coverage basis: No enforcement or coordination mechanisms active

Implementation score: 0 · Evidence confidence: High

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

Assurance: XLS-295 explicitly states: 'This XLS makes the post-quantum scheme available at the account level; it does not migrate existing accounts. Accounts that continue to sign with secp256k1 or Ed25519 retain their pre-quantum exposure.'

The additive (non-mandatory) approach in XLS-295 means classical signing paths will persist post-amendment. No deprecation timeline, freeze mechanism, or mandatory migration deadline has been proposed.

• https://github.com/XRPLF/XRPL-Standards/discussions/295
• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/

Claim: Ripple's Phase 1 describes a 'Q-Day readiness' contingency plan: if classical cryptography breaks, activate a contingency to allow safe migration to PQC using PQ-based zero-knowledge proofs for seed-based key recovery. However, no formal quantum-specific incident-response playbook, emergency governance process, or disclosure mechanism has been published.

Coverage basis: Contingency concept described but no formal process published

Implementation score: 0.25 · Evidence confidence: Low

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

Assurance: Phase 1 contingency concept is described in a blog post but lacks formal specification, governance approval, activation criteria, or enforcement mechanism.

Score of 0.25 reflects that a Q-Day contingency concept is publicly described (roadmap/design level) but no formal incident-response process, disclosure mechanism, or governance-approved emergency procedure has been published.

• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/

Claim: XLS-295 specifies ML-DSA-44 (CRYSTALS-Dilithium2, NIST FIPS 204, security category 2) as the PQ signature scheme. ML-DSA is NIST-standardized (August 2024) and broadly reviewed. The specification explicitly references FIPS 204 and uses the pqcrystals reference implementation.

Coverage basis: NIST-standardized algorithm specified in formal proposal, tested on AlphaNet

Implementation score: 0.75 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: ML-DSA-44 is NIST FIPS 204 standardized. Algorithm choice is well-documented and appropriate for the use case. Scored at 0.75 (optional mainnet support) rather than 1.00 because the algorithm is specified and tested on AlphaNet but not yet deployed on mainnet.

XLS-295 notes ML-DSA-44 is the 'lowest parameter set, NIST security category 2' chosen to 'fit the volume and latency profile of XRPL signatures.' Ripple's roadmap mentions testing multiple NIST-recommended schemes and supporting cryptographic agility.

• https://github.com/XRPLF/XRPL-Standards/discussions/295
• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/

Claim: No independent audit of the PQ implementation or quantum-critical cryptographic scope exists. The Softstack audit (December 2024) covered MPT (Multi-Purpose Token) implementation only, not cryptographic algorithm migration or PQ signatures. The IEEE BCCA 2025 paper documents the AlphaNet integration but is not a security audit.

Coverage basis: No PQ-specific independent audit

Implementation score: 0 · Evidence confidence: High

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

Assurance: No independent audit of PQ implementation exists. Softstack audit is scope-mismatched (MPT only). IEEE paper provides academic documentation but not security audit. Per QRI Section 6.4, absence of audit does not reduce QRI Score when the quantum-security property is verifiable from other evidence, but it caps Confidence at Medium.

Audit absence is recorded as an assurance caveat. Project Eleven has announced a collaboration involving a full audit of XRPL's validator, custody, networking, and wallet layers for quantum vulnerabilities, but no published artifact exists.

• https://softstack.io/case-study/xrp-ledger-security-audit-of-ripples-mpt/
• https://www.newsfilecorp.com/release/233317/XRP-Ledger-Security-Audit-Softstack-Validates-Ripples-MultiPurpose-Token-Implementation

Claim: rippled is open-source (GitHub XRPLF/rippled). ML-DSA integration code exists in a third-party fork (Transia-RnD/rippled 'dilithium-full' branch) and runs on AlphaNet. PR #6971 adds PQC readiness tests to canonical repo. However, PQ code is not merged into canonical upstream.

Coverage basis: Open-source with PQ code in fork and testnet, not in canonical upstream

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: PQ implementation code is publicly available in a third-party fork and verifiable on AlphaNet. Not merged into canonical XRPLF/rippled upstream. XLS-295 references specific branch names and commit identifiers.

Score of 0.50 (prototype/testnet level) reflects that PQ code is open-source and running on a public testnet, but resides in a third-party fork rather than the canonical upstream repository.

• https://github.com/XRPLF/rippled
• https://github.com/XRPLF/XRPL-Standards/discussions/295
• https://github.com/XRPLF/rippled/pull/6971

Claim: XLS-295 proposes adding dilithium as a new KeyType alongside existing secp256k1 and Ed25519, gated by a 'Quantum' amendment. Ripple's roadmap emphasizes 'cryptographic agility, supporting multiple NIST-standardized algorithms rather than a single scheme.' The protocol's amendment system provides a governance mechanism for future algorithm additions.

Coverage basis: Documented upgrade path via amendment system and extensible key type design

Implementation score: 0.5 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Parameter agility is documented in XLS-295 and Ripple roadmap. The amendment system provides a clear governance path for future algorithm additions.

Score of 0.50 (design/roadmap level) reflects documented parameter agility and upgrade path. Not scored higher because the upgrade path is not yet activated on mainnet.

• https://github.com/XRPLF/XRPL-Standards/discussions/295
• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/

Claim: ML-DSA is a stateless signature scheme (unlike XMSS/LMS), so stateful-signature safety and anti-reuse controls are not applicable by design. No evidence of side-channel analysis, fault-injection testing, or HSM/hardware-wallet integration testing for the ML-DSA implementation.

Coverage basis: Stateless scheme eliminates primary risk; no side-channel or custody analysis published

Implementation score: 0.5 · Evidence confidence: Low

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

Assurance: ML-DSA is stateless by design, eliminating the most critical stateful-signature risk. However, no side-channel, fault-injection, or custody implementation analysis has been published for the XRPL ML-DSA integration.

Score of 0.50 reflects that ML-DSA's stateless design inherently avoids stateful-signature risks (the primary concern in this subfactor). Side-channel and custody risks are not yet addressed but are less critical for a testnet implementation.

• https://github.com/XRPLF/XRPL-Standards/discussions/295

Claim: AlphaNet testing has produced concrete performance data: ML-DSA-44 signatures are ~2420 bytes (vs. 64 bytes ECDSA/Ed25519), public keys are 1312 bytes (vs. 33 bytes), creating ~3.7 KB per-transaction overhead. XLS-295, ForkLog, and Ripple's roadmap document throughput, storage, and bandwidth implications.

Coverage basis: Testnet-based performance analysis with documented trade-offs

Implementation score: 0.5 · Evidence confidence: High

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

Assurance: Performance data is from AlphaNet testing and XLS-295 specification. Ripple's roadmap acknowledges that 'larger keys and signatures have real implications at ledger scale' and commits to 'tightening performance, throughput, minimizing overhead.'

Score of 0.50 (testnet level) reflects that performance analysis exists with concrete measurements, but mainnet-scale impact (validator hardware requirements, archival growth, fee market effects) has not been fully assessed.

• https://github.com/XRPLF/XRPL-Standards/discussions/295
• https://forklog.com
• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/