XRP Ledger XRP

Claim: XRPL has published a thorough cryptographic inventory covering secp256k1 (ECDSA) and ed25519 (EdDSA) signing algorithms, SHA-512Half hashing, RIPEMD160/SHA-256 address derivation, and has publicly acknowledged quantum vulnerability via Shor's algorithm since at least July 2022 (Discussion #79). The April 2026 Ripple roadmap provides an updated quantum threat model.

Coverage basis: Official documentation and standards discussions

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Official XRPL.org documentation and XRPLF GitHub standards discussions serve as primary sources. IEEE academic paper provides independent peer review. Roadmap is an official Ripple publication. All sources are consistent.

Cryptographic inventory is comprehensive and publicly maintained. Quantum threat is explicitly acknowledged in Discussion #79 (2022) and the 2026 roadmap. Ed25519 validator key limitations (cannot be used for P2P or validation votes) are documented.

• https://xrpl.org/docs/concepts/accounts/cryptographic-keys
• https://github.com/XRPLF/XRPL-Standards/discussions/79
• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/
• https://xplorestaging.ieee.org/servlet/opac?punumber=11229428

Claim: XRPL maintains open-source code (rippled), official documentation, standards discussions, vulnerability disclosure reports, and an academic paper. However, no quantum-specific cryptographic audit exists.

Coverage basis: Open-source code, official documentation, published incident reports

Implementation score: 0.75 · Evidence confidence: Medium

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

Assurance: Strong evidence for classical cryptography claims. No quantum-specific cryptographic audit exists; IEEE paper provides academic review but is not a formal audit. Vulnerability disclosure process is well-documented but covers non-quantum bugs.

Evidence record is strong for classical crypto assessment. The absence of a quantum-specific formal cryptographic audit limits evidence confidence for PQ implementation claims.

• https://github.com/XRPLF/rippled
• https://xrpl.org/docs/concepts/accounts/cryptographic-keys
• https://xrpl.org/blog/2026/vulnerabilitydisclosurereport-bug-mar2026
• https://xrpl.org/blog/2026/vulnerabilitydisclosurereport-bug-feb2026
• https://xplorestaging.ieee.org/servlet/opac?punumber=11229428

Claim: XRPL Mainnet transaction signatures use only ECDSA (secp256k1) or EdDSA (ed25519). No PQC or hybrid-PQC signature support exists on Mainnet.

Coverage basis: Mainnet production transaction signing

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Active production spend authorization remains entirely ECC/BLS/Schnorr/EdDSA-only — Readiness & Risk Cap 40 applies

Assurance: Confirmed by official documentation, source code (rippled C++ codebase), and Ripple's own roadmap acknowledgment. High confidence.

AlphaNet testnet supports Dilithium (ML-DSA) signatures since December 2025, but this does not protect Mainnet users. The XLS #295 standards proposal defines the Dilithium signature format but is not activated on Mainnet.

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

Claim: XRPL public keys are exposed on-chain with every transaction. Native key rotation allows changing signing keys without changing account addresses, and SHA-512-based seed derivation provides theoretical recoverability. However, no PQ/hybrid controls exist on Mainnet to prevent quantum-vulnerable ownership paths.

Coverage basis: Mainnet account and key infrastructure

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: Native key rotation is verified in protocol documentation and code. The SHA-512 seed derivation recoverability argument (taghi.io) is theoretically interesting but the ZK-proof mechanism is not implemented — treated as a recoverability note, not active protection.

Public keys are exposed on-chain for every transaction, creating a long-exposure attack surface. Key rotation provides migration infrastructure but does not prevent quantum attacks on currently exposed keys. ~77 billion XRP have exposed public keys.

• https://xrpl.org/docs/concepts/accounts/cryptographic-keys
• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/
• https://taghi.io/post/2025/08/20/Getting-Ready-to-Transition-to-Post-Quantum-Security-in-XRPL.html

Claim: XRPL Mainnet validator authentication and consensus messages (proposals, validation votes) use classical ECDSA (secp256k1) signatures. Ed25519 cannot be used for validation votes or P2P communication. No PQC or hybrid-PQC validator signing exists on Mainnet.

Coverage basis: Mainnet validator consensus authentication

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Consensus finality, validator authentication remains quantum-vulnerable — Readiness & Risk Cap 40 applies

Assurance: Confirmed by official consensus documentation and Discussion #79 which explicitly notes Ed25519 cannot be used for validation votes. AlphaNet Quantum Consensus is testnet-only.

Validators use secp256k1 for ephemeral keys even when their master keys are Ed25519. The UNL (Unique Node List) mechanism and validator identity are tied to classical signatures. A quantum adversary compromising a UNL validator could disrupt consensus.

• https://xrpl.org/docs/concepts/consensus-protocol/consensus-principles-and-rules
• https://github.com/XRPLF/XRPL-Standards/discussions/79
• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/

Claim: XRPL uses SHA-512Half for ledger hash chaining and data integrity, which is quantum-safe. XRP supply is enforced at the protocol level (conservation checks). However, state transitions are authorized by quantum-vulnerable classical signatures. No KZG/pairing-based commitments are used.

Coverage basis: Satisfied by design (hash-based)

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Hash-based integrity is inherently quantum-safe. No vulnerable commitment schemes identified. Invariant checking provides additional supply integrity.

Partial credit: the hash-based data integrity layer is quantum-safe, and supply enforcement is protocol-level. However, the authorization layer that gates state changes (transaction signatures) is quantum-vulnerable — that vulnerability is scored under spend authorization and consensus subfactors.

• https://xrpl.org/docs/concepts/consensus-protocol/consensus-principles-and-rules
• https://github.com/XRPLF/XRPL-Standards/discussions/79
• https://xrpl.org/blog/2017/invariant-checking

Claim: XRPL has no native privacy layer or shielded transactions in the current Mainnet production scope. Confidential Transfers for MPTs are mentioned in the roadmap (Phase 3) as future exploration.

Coverage basis: Not applicable — no privacy layer in evaluated scope

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Correctly marked N/A. Future privacy features (Confidential Transfers for MPTs) are roadmap items and not part of the current production scope.

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

Claim: XRPL P2P node identity and peer authentication use classical cryptography. Validator node identity is tied to the same classical key infrastructure used for consensus. Non-validator P2P identity compromise does not directly enable fund theft but could enable network-level attacks.

Coverage basis: Mainnet P2P and node identity

Implementation score: 0 · Evidence confidence: High

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

Assurance: Validator P2P identity is tightly coupled with consensus identity. For non-validator nodes, P2P compromise risk is limited to network-level attacks (eclipse, censorship) rather than direct fund theft. Scored under consensus authentication for the validator path.

Discussion #79 notes that validators' ephemeral keys must be secp256k1. P2P transport uses classical crypto. The quantum vulnerability here is primarily consequential for validators, which is already captured under the consensus authentication subfactor.

• https://github.com/XRPLF/XRPL-Standards/discussions/79
• https://xrpl.org/docs/concepts/consensus-protocol/consensus-principles-and-rules

Claim: No PQ wallet, custody, HSM, or hardware-wallet workflows exist on XRPL Mainnet. All wallet interactions (Ledger, XUMM, etc.) use classical ECDSA/EdDSA signing. Project Eleven partnership is prototyping a PQ custody wallet but this is not production.

Coverage basis: Mainnet wallet and custody ecosystem

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Hardware wallet support (Ledger) for XRP is confirmed but uses classical algorithms only. Project Eleven PQ custody wallet is in early prototype stage — not production. DFNS custody documentation confirms classical-only signing.

No Mainnet PQ wallet path exists. The Project Eleven partnership (announced May 2026) for a PQ custody wallet prototype is future work and does not affect the current production scope.

• https://support.ledger.com/article/115005177349-zd
• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/
• https://docs.dfns.co/networks/xrpl

Claim: Approximately 76.82 billion XRP tokens (76.83% of supply) have public keys exposed on-chain with no Mainnet PQC protection. 0% of circulating value is protected from quantum key-recovery attacks. ~300,000 accounts (~2.4B XRP) have never exposed public keys.

Coverage basis: On-chain public key exposure analysis (validator dataset April 2026)

Implementation score: 0.05 · Evidence confidence: High

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

Quantum blocker: Material long-exposure quantum-vulnerable value (~76.82B XRP) exists with no Mainnet migration, freeze, deprecation, or protection path currently live

Assurance: The ~76.82B XRP figure is from a comprehensive validator dataset (April 2026) analyzing all 7.81M XRPL accounts. This is primary-source evidence with reproducible methodology. The 0% protection figure is confirmed by all primary sources.

Per QRI 9.3.1: <25% coverage → Implementation Score 0.05 (1/20). No Mainnet PQC protection exists, so coverage is effectively 0%. The roadmap and testnet work do not constitute Mainnet protection.

• https://github.com/xVet/xrpl-quantum-exposure-dataset
• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/
• https://xrpl.org/docs/concepts/accounts/cryptographic-keys

Claim: No critical wallets (Ripple treasury, exchanges, custodians, bridges, foundation wallets, major protocol-controlled value) have been migrated to PQC or hybrid-PQC on XRPL Mainnet.

Coverage basis: Mainnet critical wallet infrastructure

Implementation score: 0 · Evidence confidence: High

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

Assurance: No evidence of any Mainnet critical wallet migration. The roadmap states Phase 4 (targeting 2028) will address ecosystem-wide transition. Ripple's own acknowledgment confirms no current migration.

Critical wallets including Ripple's escrowed XRP, exchange-held XRP, and protocol-controlled assets remain entirely on classical signatures.

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

Claim: The ~76.82B XRP figure indicates awareness of the quantum-exposed value pool. However, no deprecation, freeze, migration, or burn mechanism exists on Mainnet. Dormant accounts with exposed public keys have no policy path for protection.

Coverage basis: Legacy vulnerable account identification

Implementation score: 0.25 · Evidence confidence: High

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

Assurance: The ~76.82B figure is from a primary-source validator dataset with reproducible methodology. No deprecation, freeze, or burn policy exists for unmigratable dormant accounts.

Partial credit (0.25): the quantum-exposed nature of XRPL accounts is acknowledged in the roadmap, and the validator dataset provides comprehensive identification. However, no formal deprecation, freeze, burn, or migration policy mechanism has been implemented or proposed for dormant/unmigratable vulnerable accounts.

• https://github.com/xVet/xrpl-quantum-exposure-dataset
• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/

Claim: Ripple published a four-phase roadmap (April 2026) with sequencing: Phase 1 (Q-Day readiness/recovery), Phase 2 (experimentation, H1 2026), Phase 3 (PQ primitives exploration, H2 2026), Phase 4 (full transition targeting 2028). Activation criteria and dependencies are described at a high level.

Coverage basis: Official Ripple roadmap publication

Implementation score: 0.5 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: The roadmap is an official Ripple publication. It provides phase sequencing and target dates. Testnet implementation (AlphaNet, December 2025) demonstrates that Phase 2 work is underway. However, the roadmap is a plan, not a committed protocol upgrade — XRPL amendments require validator voting.

Implementation Score 0.50 reflects that this is more than a proposal (testnet exists) but not yet Mainnet support. The roadmap has clear phases but activation depends on future amendment proposals and UNL validator adoption.

• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/
• https://thequantuminsider.com/2026/04/21/ripple-outlines-plan-to-protect-xrpl-from-quantum-computing-risks/
• https://www.coindesk.com/markets/2026/04/21/ripple-wants-the-xrp-ledger-to-be-quantum-proof-by-2028-here-is-its-plan

Claim: XRPL has native key rotation (protocol-level support for changing signing keys without changing account addresses). AlphaNet testnet supports Quantum Accounts with Dilithium. However, no Mainnet PQ account creation, wallet tooling, custody paths, migration prompts, or user education exists.

Coverage basis: Mainnet and testnet migration tooling

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Native key rotation is a verified protocol feature and structural advantage. AlphaNet Quantum Accounts demonstrate testnet PQ account creation. No Mainnet migration tooling or prompts exist. XLS #295 proposal defines the Dilithium key format and account flag mechanism.

Implementation Score 0.25: design and prototype exist (key rotation + AlphaNet Quantum Accounts), but no Mainnet accessibility. The key rotation feature means users won't need to change their r-addresses when migrating to PQ keys, which is a significant migration UX advantage.

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

Claim: No Mainnet migration enforcement mechanisms exist. The roadmap describes a future hard shift where classical signatures would no longer be accepted, but no amendment proposal, validator voting, or enforcement timeline exists on Mainnet.

Coverage basis: Mainnet enforcement mechanisms

Implementation score: 0 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: The roadmap envisions enforcement (hard shift rejecting classical signatures) in Phase 4 but this is a future plan. No amendment draft, validator vote, or Mainnet enforcement exists. The XLS #295 proposal includes `lsfForceQuantum` flag concept but notes it may be unnecessary given key rotation design.

XRPL amendment process requires supermajority validator approval. No quantum-related amendment has been proposed for Mainnet voting. Ecosystem coordination (exchanges, custodians, bridges, wallets) is acknowledged in the roadmap as a Phase 4 concern but has not begun.

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

Claim: XRPL has a demonstrated vulnerability disclosure and incident response process (multiple published reports for non-quantum bugs, 2024-2026). The Phase 1 'Quantum-Day' contingency plan describes a ZK-proof-based recovery mechanism for quantum compromise scenarios, but implementation details are still in exploration.

Coverage basis: Published vulnerability disclosure reports and roadmap

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: The general vulnerability disclosure process is well-demonstrated with multiple published incident reports (Common Prefix consensus bugs, Batch amendment bug, xrpl.js supply chain compromise, November 2024 crash). Incident response timelines are documented. The quantum-specific 'Quantum-Day' ZK-proof plan is still conceptual — no proof system has been selected or implemented.

Implementation Score 0.50: general incident response process is mature and demonstrated, quantum-specific contingency is designed but not implemented. The ZK-proof recovery approach (proving seed knowledge without exposing keys) is architecturally promising but unproven.

• https://xrpl.org/blog/2026/vulnerabilitydisclosurereport-bug-mar2026
• https://xrpl.org/blog/2026/vulnerabilitydisclosurereport-bug-feb2026
• https://xrpl.org/blog/2025/vulnerabilitydisclosurereport-bug-nov2024
• https://xrpl.org/blog/2025/vulnerabilitydisclosurereport-bug-apr2025
• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/

Claim: XRPL has selected CRYSTALS-Dilithium (NIST-standardized as ML-DSA / FIPS 204) for its PQ signature algorithm. This is implemented on AlphaNet testnet for Quantum Accounts, Transactions, and Consensus. The XLS #295 proposal and implementation branch use the pq-crystals/dilithium reference implementation.

Coverage basis: AlphaNet testnet PQ implementation

Implementation score: 0.5 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: ML-DSA (FIPS 204) is a finalized NIST standard. The algorithm selection is appropriate for digital signatures. The reference implementation (pq-crystals/dilithium) is widely used. However, the implementation is testnet-only and has not undergone independent cryptographic audit.

Implementation Score 0.50 reflects testnet deployment. The XLS #79 discussion (2022) also considered FALCON and SPHINCS+ as alternatives. ML-DSA selection aligns with NIST's primary recommendation. The roadmap mentions supporting multiple NIST algorithms for cryptographic agility.

• https://github.com/XRPLF/XRPL-Standards/discussions/295
• https://github.com/XRPLF/XRPL-Standards/discussions/79
• https://coinedition.com/xrp-ledger-alphanet-tests-quantum-resistant-security-upgrade/

Claim: No independent quantum-specific cryptographic audit of XRPL's core signing, consensus authentication, or AlphaNet Dilithium implementation has been identified. An IEEE academic paper (October 2025) provides peer-reviewed analysis but is not a formal audit. General security audits exist for non-quantum components.

Coverage basis: Audit coverage of quantum-critical implementation

Implementation score: 0.25 · Evidence confidence: Low

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

Assurance: IEEE paper (October 2025) provides academic peer review of XRPL quantum vulnerabilities and proposes Dilithium integration — this is valuable but is not a formal cryptographic implementation audit. General security audits (Common Prefix, Softstack, Cantina AI) cover non-quantum components. Per QRI v3.1, the absence of a quantum-specific audit does not by itself reduce the QRI Score since the quantum-critical vulnerability (ECC-only Mainnet) is independently verifiable. It does limit Confidence.

Implementation Score 0.25 for the academic review. A formal quantum-crypto audit of the AlphaNet Dilithium implementation and planned Mainnet integration would strengthen evidence quality significantly. The Project Eleven partnership (May 2026) includes an audit component but results are not yet available.

• https://xplorestaging.ieee.org/servlet/opac?punumber=11229428
• https://softstack.io/case-study/xrp-ledger-security-audit-of-ripples-mpt/
• https://xrpl.org/blog/2026/vulnerabilitydisclosurereport-bug-mar2026

Claim: XRPL's rippled is fully open-source (ISC license). The Dilithium PQ implementation branch (Transia-RnD/rippled, dilithium-full) is publicly available with unit tests, integration tests, and performance benchmarks. The pq-crystals/dilithium reference library is open-source.

Coverage basis: Open-source codebase and PQ implementation branch

Implementation score: 0.75 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: The main rippled repository is actively maintained with public releases. The PQ branch is in a fork (Transia-RnD/rippled) rather than the main XRPLF repository. The code is publicly accessible and includes tests. The main rippled release does not yet include PQ code.

Implementation Score 0.75: the codebase is fully open-source and the PQ implementation is publicly available in a working branch. Deduction from 1.00 because the PQ code is not yet in the main rippled release and is maintained in a fork.

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

Claim: The Ripple roadmap mentions supporting multiple NIST-standardized algorithms (cryptographic agility). The XLS #79 discussion (2022) compared Dilithium, FALCON, and SPHINCS+ parameters. However, formal parameter agility mechanisms and upgrade paths are not yet specified or implemented.

Coverage basis: Roadmap and standards discussion

Implementation score: 0.25 · Evidence confidence: Low

Issue classification: none · Score treatment: not applicable

Assurance: The principle of cryptographic agility is stated in the roadmap as a guiding principle. Discussion #79 provided early parameter comparison. No formal specification for algorithm negotiation, key type versioning, or upgrade path exists.

Implementation Score 0.25: design consideration exists but no formal specification or implementation. The variable-length encoding of SigningPubKey and Signature fields in XRPL transactions provides natural extensibility for new key types.

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

Claim: ML-DSA (Dilithium) is a stateless signature scheme, so stateful-signature concerns (XMSS/LMS-style) are not applicable. However, side-channel and fault-injection risks for lattice-based schemes, as well as hardware-wallet and HSM integration challenges due to large key/signature sizes, are not yet formally addressed for XRPL's PQ implementation.

Coverage basis: PQ implementation risk analysis

Implementation score: 0.25 · Evidence confidence: Low

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

Assurance: ML-DSA being stateless eliminates state-management risks, which is positive. However, lattice-based schemes have known side-channel considerations (e.g., timing attacks on sampling). The large key sizes (1312 bytes public, 2528 bytes secret, ~2420 bytes signature) present practical challenges for hardware wallets and HSMs. No formal side-channel analysis or HSM integration assessment has been published.

Implementation Score 0.25: the stateless nature of ML-DSA is a design advantage, and the key/signature size implications are acknowledged in the roadmap (Phase 2). Formal side-channel analysis, fault-injection assessment, and HSM integration evaluation remain future work.

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

Claim: ML-DSA signatures at ~2,420 bytes (vs. 64 bytes for EdDSA) will significantly impact XRPL throughput, storage, and bandwidth. The roadmap acknowledges these trade-offs and states that AlphaNet testing is generating data. No formal published benchmark exists.

Coverage basis: Roadmap acknowledgment of performance impact

Implementation score: 0.25 · Evidence confidence: Low

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

Assurance: The ~37x increase in signature size (64→2420 bytes) and ~40x increase in public key size (33→1312 bytes) is well-documented. The roadmap acknowledges storage, bandwidth, and validator hardware implications. No formal benchmark report has been published. AlphaNet testing is ongoing. Per QRI v3.1, missing formal benchmarks do not reduce the QRI Score by themselves unless they prevent safe use — recorded as assurance note.

Implementation Score 0.25: performance implications are acknowledged and testnet data collection is underway. The XLS #295 proposal documents exact key/signature sizes. This is an operational/product caveat that will become more important as Mainnet deployment approaches.

• https://ripple.com/insights/post-quantum-readiness-on-the-xrp-ledger/
• https://cryptoslate.com/xrpl-flips-to-quantum-safe-signatures-2420-byte-proofs-replace-elliptic-curves/
• https://github.com/XRPLF/XRPL-Standards/discussions/295