What it is. A payments-focused public ledger that has already built a working test network proving quantum-safe signing for accounts, transactions, and the way the network agrees on its records, and it has put a public date of 2028 on switching the real network over.
What we found. All of that proof runs on a test network only, so today every real account is still protected by the old kind of math that a future quantum computer could break, though any account here can swap its signing key without changing its address, which most chains cannot do.
Why it matters. Holders and institutions get an unusually clear plan and an easy way to move to safer keys later, but until the switch reaches the real network the old protection is what is actually guarding the money, and the 2028 timing leaves little room to slip.
XRPL has shipped a public roadmap with named dates (full PQC transition by 2028), a developer testnet (AlphaNet) running ML-DSA / CRYSTALS-Dilithium across accounts, transactions, and consensus, an IEEE-published implementation paper, and an active XRPL-Standard discussion (#295). None of this is yet on mainnet. The headline question is whether the December-2025 AlphaNet shipment plus the April-2026 four-phase roadmap activate at consensus before the rest of the L1 set catches up.
Summary
XRPL QRI 38 ± 7 (Band 4 Architected), Migration Stage 2 (Acknowledged with public testnet). The April-2026 Ripple roadmap names full PQC transition by 2028 across four phases. AlphaNet (December 2025) is a public developer testnet running ML-DSA across Quantum Accounts, Quantum Transactions, and Quantum Consensus, published, observable, but not on mainnet. Mainnet-Traffic cap binds. Native key rotation primitive (RegularKey on every account) is uniquely strong vs Bitcoin/Ethereum. Native multi-sig (SignerListSet, 1-32 signers, weights, quorum). The IEEE BCCA 2025 paper documents the integration; XRPL Standards discussion #295 frames the amendment as additive (new key type alongside existing schemes) rather than co-signed. Project Eleven is named as third-party PQC partner for validator testing and custody prototyping. Lattice-monoculture (only ML-DSA, no second family at 5b/5c) triggers Cryptographic-Diversity Cap. Hybrid composition is the single biggest architectural decision still open: AlphaNet's PQ-only choice is faster but means Stage 5 prerequisites (Gate 1a-Sig PASS) cannot be met without explicit hybrid-AND or hybrid-OR-with-commit-to-hash. Stage 2 with strong upside to Stage 3 within H2 2026 if Devnet hybrid integration ships per roadmap.
What the gates say
- Gate 1a, Hybrid signature: FAIL , no documented hybrid-AND or hybrid-OR-with-commit signature composition on mainnet; Discussion #295 frames Dilithium as additive new key-type, not co-signed; AlphaNet runs PQ-only; Phase 3 roadmap promises hybrid Devnet H2 2026, not yet delivered
- Gate 1a, Hybrid KEM: FAIL , validator gossip / RPC / peer transport TLS uses classical X25519/ECDHE; no IETF hybrid-KEM TLS deployment
- Gate 1b, Commit-to-hash: COND , no OR-composition declared
- Gate 2, Evidence reconstruction: PASS , every sub-score has ≥ 3 URLs reconstructible by independent third party
- Gate 3, Primitive naming: PASS , every primitive named with mechanism, ML-DSA / CRYSTALS-Dilithium lattice; ECDSA secp256k1 DL; Ed25519 DL; SHA-512Half
Burn-vs-rescue policy on file
Declared option a, Freeze/burn enforcement under Q-Day contingency, with optional migration pre-Q-Day. Public roadmap names Phase 1 'Q-Day readiness' with a 'hard shift' enforcement (classical sigs no longer accepted by network) and a PQ-based zero-knowledge-proof recovery path for revealing key ownership without exposing it. Pre-Q-Day path is rescue-favored via RegularKey rotation + amendment opt-in. Post-Q-Day path is the freeze-and-prove model.
Seven dimensions
Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.
1 Cryptographic Exposure weight 15% 56 / 100
All primitives named with mechanism. AlphaNet is not mainnet. Primitives publicly named in xrpl.org docs and rippled source.
ECDSA secp256k1 (default for wallet_propose admin RPC) · Ed25519 (default in xrpl.js client libraries) · SHA-512Half (transaction & ledger Merkle hashing, prefixed with 4-byte type code) · TLS for peer / RPC transport · ML-DSA / CRYSTALS-Dilithium signatures ~2,420 bytes/sig (AlphaNet developer testnet only, across Quantum Accounts, Quantum Transactions, Quantum Consensus) Mainnet is 100% Shor-vulnerable today.
ECDSA secp256k1→ Shor-break-via-DL-without-pairingsEd25519→ Shor-break-via-DL-without-pairingsSHA-512Half→ Grover-weaken (256-bit→128-bit effective)TLS classical key exchange (X25519/ECDHE)→ Shor-break-via-DLML-DSA-44 / CRYSTALS-Dilithium (AlphaNet only)→ PQ-safe (lattice, with confidence-discount per v3.1 lattice-monoculture exposure)
Mainnet has zero PQ family. AlphaNet (testnet) deploys exactly one PQ family: lattice (ML-DSA only). No hash-based, code-based, or isogeny fallback announced or shipped. Cryptographic-Diversity Cap (v3.1 lowered to 60) fires regardless of stage progression until a second family is deployed at 5b/5c. Roadmap states 'supporting multiple NIST-standardized algorithms rather than a single scheme' but no second-family scheme is named or deployed.
ECDSA secp256k1 ≈ 128-bit classical (no NIST PQ category, Shor-vulnerable); Ed25519 ≈ 128-bit classical; SHA-512Half ≈ 256-bit classical → 128-bit Grover; AlphaNet Dilithium signature size ~2,420 bytes matches ML-DSA-44 (NIST FIPS 204 Level 2 / NIST category 2). Sub-score reflects one NIST category 2 PQ primitive shipped on testnet only.
rippled (C++) is the dominant client; mature, audited via Ripple security program, long production track record at consensus. AlphaNet Dilithium integration lives on the dilithium-full branch of Transia-RnD/rippled (third-party R&D fork, not yet upstream). No public formal verification of the PQ integration. No public constant-time validation note. ML-DSA is stateless. Cryptanalytic tier mixed: ECDSA/Ed25519/SHA-512 = tier 1 (mature classical); ML-DSA = tier 3 (NIST FIPS 204 standardized 2024).
2 Quantum Recovery Exposure weight 10% 26 / 100
XRPL is ~12 years live. Every account that has signed a transaction has revealed its ECDSA-secp256k1 or Ed25519 public key on-chain. A 2026-04 third-party analyst report places 'at-risk' supply at ~0.03% (long-dormant accounts with revealed keys); active-account exposure is materially higher because every signed transaction reveals the pubkey. Ripple's own roadmap names this risk explicitly.
~0.03% of supply at long-dormant addresses cited by analyst report. XRPL's account model exposes pubkey on first-spend (similar to Bitcoin P2PKH spend), but XRPL does not have an unspent-pubkey-hash equivalent for accounts that have ever transacted. Ripple-controlled escrow and large institutional balances add structural concentration. RegularKey rotation provides a per-account migration path other chains lack natively.
Historical ECDSA / Ed25519 signatures are forgeable post-Shor. XRPL has no protocol-level signature retention/sunset declaration. Phase 1 ('Q-Day readiness') of the April-2026 roadmap describes a 'hard shift' where classical signatures are no longer accepted by the network and funds must move to quantum-safe accounts, with PQ-based zero-knowledge proofs as a recovery path, but no spec, no testnet, no dated milestone for this contingency.
Validator gossip, peer-to-peer transport, and RPC use TLS with classical key exchange (X25519/ECDHE) and classical certificate authentication. No hybrid PQ KEM declared in the peer protocol or RPC stack. The April-2026 roadmap mentions exploring 'post-quantum-friendly primitives for... homomorphic encryption' for confidential transfers but does not extend this to validator transport.
3 Metadata, Anonymity & Confidentiality weight 13% 28 / 100
Fully transparent ledger. Every account, balance, transaction history is publicly indexable. RippleNet institutional payment use case adds entity-level deanonymization context (ODL corridors, named institutional addresses).
RPC concentration: Ripple-operated public servers, Blockdaemon, and validator-cluster RPCs dominate; no published top-3 share split. Mempool/gossip observable to any peer joining the network. dUNL ('default UNL') is curated by XRP Ledger Foundation and Ripple, signed with a single-cryptographic-key-pair under XRPL Foundation control; September 2025 default-UNL migration; December 2025 dUNL update. Validator metadata retention undeclared.
Active bridges: XRPL-EVM sidechain, Axelar General Message Passing for XRPL. Public observers can correlate XRPL→bridge→destination flows. None of the listed bridges has a published PQC roadmap.
No shielded pool, no ring sigs, no zk-SNARK-protected sender set. Retroactive deanonymization risk via Shor on curves applies to identity linkage of long-revealed pubkeys but not to 'shielded balances' because there are none. Privacy is structurally absent rather than cryptographically protected.
None at protocol or wallet layer. No commit-reveal, no cMix, no shuffle network.
4 Migration Architecture weight 10% 85 / 100
XRPL natively supports multi-algorithm signatures (secp256k1 default in wallet_propose; Ed25519 default in xrpl.js; both interchangeable as master/regular/multi-sig keys via the 0xED-prefix convention). XRPL Standards discussion #295 proposes Dilithium as a third key-type via amendment, with backward compatibility. The amendment system itself is the protocol-level switch (no hard fork; 80%/2-week supermajority validator vote).
Native key rotation: RegularKey field on every account lets an account replace its signing key without changing its address, uniquely strong primitive vs Bitcoin/Ethereum. Native multi-sig: SignerListSet transaction, 1-32 signers with weights and quorum, signers can rotate keys independently. xrpl.js / xrpl-py default to Ed25519 for client-layer key generation, providing a documented client path. AA proper (smart-contract wallet model) is not the XRPL design; the protocol's native rotation primitives substitute. Client-layer PQC path documented but not deployed at volume on mainnet.
Amendment system is XRPL's coordinated-upgrade mechanism: dozens of amendments shipped via 80% validator supermajority over a 2-week window, no chain-split history of note. Default UNL migration (September 2025) executed cleanly; dUNL updates handled in-band.
The April-2026 roadmap explicitly commits to 'hybrid rollout that runs alongside existing systems before scaling' (Phase 3, second half of 2026, Devnet integration of PQ candidates alongside elliptic-curve signatures). Project Eleven is named as a partner building 'a proof-of-concept hybrid post-quantum signing implementation.' The AlphaNet shipment is PQ-only (Quantum Consensus replaces classical), not hybrid. Spec-level hybrid is announced; testnet hybrid is roadmapped for H2 2026 on Devnet (not yet verifiable).
ML-DSA is stateless. No XMSS / LMS / leanXMSS stateful scheme in scope.
XRPL Consensus Protocol uses validator-by-validator signed proposals/validations, not BLS-aggregated quorum certs. No BLS-aggregation path to migrate. Sub-score N/A per v3.1. Renormalized to /80 → 68/80 → 85/100.
5 Deployment Execution weight 22% 32 / 100
Zero. AlphaNet is a public developer testnet, not mainnet. No XRPL mainnet transaction has been signed under ML-DSA. Mainnet rollout target is 2028 per the four-phase roadmap. 5a = 0 → 5d voided to 0 per v3.1; Mainnet-Traffic Cap fires.
Dilithium integration code is merged in the Transia-RnD/rippled dilithium-full branch (third-party R&D fork) and runs in production on AlphaNet. Not yet merged into the canonical XRPLF/rippled upstream client. The IEEE paper documents the integration (key management, signing, verification modules). Implementation is real and running.
AlphaNet validator set runs PQC code (Quantum Consensus), that is the testnet's purpose. Mainnet UNL validators (~35 default UNL, ~150 active) do NOT operate any PQC key. Score reflects testnet-only adoption.
VOIDED to 0 per v3.1 (5a = 0). Note for completeness: roadmap publishes dated milestones, Phase 2 H1 2026, Phase 3 H2 2026, Phase 4 by 2028, but they're forward-looking and 5a-conditional.
Announced PQC items (trailing 12 months): four-phase roadmap (April 2026), Project Eleven partnership (April 2026), AlphaNet Quantum Consensus launch (December 2025), discussion #295 (open), IEEE BCCA 2025 paper. Shipped PQC items: AlphaNet running ML-DSA across Quantum Accounts/Tx/Consensus (testnet, observable), dilithium-full branch (public), IEEE paper (peer-reviewed). Ratio ≈ 1.0 (announced items map to delivered artifacts). No washing-tag deduction.
Dilithium signature size cited at ~2,420 bytes (matches ML-DSA-44 per FIPS 204) vs. ECDSA secp256k1 ≈ 64-72 bytes per signature on XRPL, multiplier ~33-38× raw. Public Ripple post acknowledges 'larger keys and signatures have real implications at ledger scale' (Phase 2 quote). Falls in 10-38× band per v3.1 rubric.
6 Supply Chain Vendor Readiness weight 22% 16 / 100
Top-3 XRPL wallets: Xaman (formerly Xumm), GemWallet, Crossmark / Ledger hardware. None has a public PQC roadmap mapping to ML-DSA / XRPL discussion #295 key types. Ledger hardware vendor has general PQC research notes but no XRPL-specific PQC firmware path.
Top bridges for XRPL: XRPL-EVM Sidechain (Peersyst), Axelar GMP, Wormhole (limited). None has published PQC roadmap. Multichain is defunct (since 2023), excluded.
Top-3 custody options for XRP: Ripple Custody (in-house), BitGo, Anchorage. Ripple Custody is named in the April-2026 roadmap as part of the post-quantum prep ('early custody prototypes' with Project Eleven). BitGo has general MPC-PQ direction; no XRPL-specific PQC declaration. Anchorage no public XRPL PQC roadmap.
Top RPC providers for XRPL: Ripple-operated public clusters, Blockdaemon, QuickNode (XRPL endpoints), Ankr. None published PQC RPC-TLS roadmap. HSM landscape (Thales, YubiHSM, AWS KMS) has general PQC roadmaps but no XRPL-specific HSM key-type. TEE attestation not a primary XRPL infrastructure pattern.
7 Governance & Coordination weight 8% 55 / 100
~150 active validators network-wide; ~35 on default UNL curated by XRPL Foundation. dUNL signed by single XRPL Foundation key pair (centralization point). Operator diversity is moderate (independent operators across regions); economic stake not the consensus driver (no protocol PoS rewards).
Amendment system has shipped dozens of features via 80%/2-week supermajority. dUNL migration (September 2025) and December 2025 dUNL update executed in-band. No coordinated emergency upgrade under active attacker on record at the consensus layer; SEC-litigation pressure (2020-2024) was financial-regulatory, not protocol-cryptographic.
Ripple's applied cryptography team is named publicly: Dr. Murat Cenk, Dr. Tamas Visegrady, Dr. Oleg Burundukov, Dr. Aanchal Malhotra, with Denis Angell on engineering. RippleX is the named program. XRPL Foundation curates dUNL and standards. Project Eleven is named as the third-party PQC partner. Mandate published via the April 2026 Ripple insights post and discussion #295.
SEC v. Ripple litigation (2020-2024) caused material institutional pressure but no protocol-level cryptographic coordination event. No precedent on record of XRPL coordinating a crypto-primitive change under active on-chain attacker. Roadmap Phase 1 (Q-Day readiness) defines a contingency procedure but is unspec'd and untested.
None declared at protocol level. No rate-limited spending rule, no cryptographic tripwire, no automated response. Phase 1 roadmap describes a 'hard shift' enforcement but no canary/honeypot precedes it.
X + Y vs Z, when does the math turn against you?
v3.1 demotes the X+Y vs Z timing test to a secondary signal, the headline output is Migration Stage. The timing test still answers the question: can this chain finish migrating before the threat lands?
Verdict
X+Y best-case beyond 2030, Crisis Zone (vs Z10 2030); inside the 2035 band on best-case execution (vs Z25 2035)
Z-compliance
On-target for 2035 disallowance if 2028 transition holds; outside 2030 deprecation window for any classical key still active
Source-disagreement disclosure
v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.
AlphaNet Dilithium signature size cited at ~2,420 bytes by CryptoSlate / BingX / MEXC, which matches ML-DSA-44 (NIST FIPS 204 Level 2 / NIST category 2; reference public-key 1,312 B + signature 2,420 B). ML-DSA-65 signatures are ~3,309 bytes and ML-DSA-87 are ~4,627 bytes; neither matches the cited size. Public Ripple roadmap does not name the parameter set explicitly, primary sources are the IEEE paper and discussion #295.
Analyst report places 'at-risk' supply at ~0.03% (long-dormant accounts). LayerQu reads active-key exposure as materially higher because every signed transaction reveals the public key on-chain (Ripple's own roadmap states this). A TVL-only Forge sub-total would score ~0.03% supply at risk (lower); LayerQu's active-key-includes-revealed-pubkeys weighting captures the broader Forge surface.
Delta-QRI under alternative weighting
Under TVL-only alternative weighting, QRI shifts ~+4 (raw 38 → ~42); after-caps unchanged (Mainnet-Traffic still binds).
Announcement-to-shipped ratio
Announced: 5. Shipped: 1. Ratio: 5.
Tag: borderline, not 'narrative-only' because AlphaNet is real testnet shipment. Not 'none' because mainnet shipment count is zero. Conservative: no deduction (5e = 12). Flag for re-evaluation when mainnet activates.
Peers in the L1 profile
9 chains closest to XRP Ledger (XRPL) by Stage then QRI.