The XRP Ledger’s quantum-resistant accounts would make every payment that uses them carry about 3.6 KB more data than today, and the fee would stay the same. The figures come from the XRPL Foundation, whose protocol roadmap, updated on 4 November 2026, lists a proposed amendment called Quantum that would let accounts sign with ML-DSA-44, the post-quantum signature scheme NIST standardised in August 2024. The foundation’s own study puts the extra load at 3,627 bytes of key and signature per transaction and the price tag of the work at $215,000 to $255,000.
None of this is live, approved or even numbered. The amendment has no XLS number yet, the specification is still a draft under public review, and the roadmap places development, review and audit in late 2027 or 2028.
The design is not new either. Denis Angell opened the specification as a GitHub discussion on 8 July 2025 and last edited it on 20 May 2026. Ripple published a four-phase post-quantum plan on 20 April 2026. What brought the topic back this week was a CoinDesk write-up posted late on 9 November, New York time, and a comment thread on GitHub where outside developers were still reporting problems in the reference code that same day.
For holders of XRP, there is nothing to do today. XRP traded near $1.099 at 05:13 UTC on 10 November, 12.7% lower over seven days according to our market snapshot, and nothing in the sources links that move to the quantum design.
What the XRP Ledger quantum amendment would change
Today an XRP Ledger account signs with one of two classical schemes, secp256k1 or Ed25519. Both have the same weakness against a large quantum computer: every signature published on the ledger reveals the account’s public key, and the threat model behind post-quantum work assumes that a powerful enough machine could work back from a public key to the private key. Any account that has ever sent a transaction, exchange hot wallets included, has its public key on the ledger. Our explainer on private and public keys covers why that link matters.
The draft adds a third key type, labelled dilithium after the scheme’s name before NIST renamed it. It sits behind an amendment called Quantum whose default vote is no, so nothing changes unless validators choose to support it. Addresses would be derived the same way as now. Until activation, the draft says, peers must refuse any signature made with such a key.
The switch itself reuses a tool the ledger already has. An owner would set a regular key derived from an ML-DSA-44 key pair with the existing SetRegularKey transaction, then sign with it, or move the funds to a fresh account derived from such a key. Existing accounts are not migrated by the network. Each holder, exchange or custodian has to act, and the draft asks wallets, exchanges and custodians to provide tools for it. It also warns against moving early: a quantum regular key used before activation would produce transactions no peer accepts, so holders should keep their classical key as a fallback until then.
ML-DSA-44 is the smallest of the three parameter sets in FIPS 204, the standard NIST published on 13 August 2024. It is already in commercial use outside crypto: AWS made ML-DSA-44, ML-DSA-65 and ML-DSA-87 signing keys generally available in its key management service on 13 June 2025, according to the foundation’s study.
How big ML-DSA-44 signatures are on the XRP Ledger
Size is the price of the new scheme. A classical payment carries a 33-byte public key and a signature of about 72 bytes, 105 bytes in all. An ML-DSA-44 payment carries a 1,312-byte public key and a 2,420-byte signature. That is 3,732 bytes, about 35 times the classical pair. FIPS 204 fixes the signature at exactly 2,420 bytes, yet the draft still describes it as variable, “up to 2420 bytes”, and accepts consensus signatures from 64 bytes. The foundation’s study says verification should reject any other length, and an outside reviewer made the same request on GitHub on 2 November.
Counted the way a node stores it, with transaction history and database overhead, one such signed transaction comes to 5,331 bytes, against 1,704 bytes for the ordinary XRP payment the study uses as its baseline: about 3.1 times as much.
| Item | Classical payment | ML-DSA-44 payment |
|---|---|---|
| Public key | 33 bytes | 1,312 bytes |
| Signature | about 72 bytes | 2,420 bytes |
| Key plus signature | 105 bytes | 3,732 bytes |
| Stored per signed transaction | 1,704 bytes | 5,331 bytes |
| Extra history, 1 such transaction per ledger | n/a | about 42 GB a year |
| Extra history, 1,000 per ledger | n/a | about 42,029 GB a year |
Source: XRPL Foundation quantum feasibility study. The secret key, 2,560 bytes in the draft, stays in the wallet and never reaches the ledger.
The design creates no new ledger objects, so the state that every validator keeps in memory does not grow. The cost lands elsewhere: bandwidth between nodes, the size of full history, and the time needed to verify each signature. At one quantum-signed transaction per ledger the extra history is modest. At a thousand per ledger, a level the network would reach only if the scheme became the norm, it adds about 42 terabytes a year.
The fee stays the same, and node operators carry the weight
The draft says plainly that it does not change the fee schedule. A transaction about 3.7 KB larger would pay the same base fee as a classical one. That is the “no extra fees” in CoinDesk’s headline. The draft leaves pricing to the usual process: operators “SHOULD price reserves and fees accordingly through standard fee-voting mechanisms”, it says, without proposing any number.
It does not mean the extra data is free. Fees on the XRP Ledger are burned, not paid to anyone, so they never compensated node operators for storage in the first place. The bytes that quantum-safe signatures add would be paid for by whoever runs validators and full-history servers, in disks and bandwidth.
The foundation’s study flags that fees on the ledger do not scale with transaction size and leaves open whether ML-DSA-44 transactions need a size-based rule of their own. That question goes to a later piece of work. “A post-quantum migration study in the first half of 2027 feeds the spec,” the roadmap says.
A $215,000 to $255,000 line on a $5 million roadmap
The roadmap rates Quantum as an XL job: 640 hours of building, 400 hours of review by Ripple, complexity 3 out of 3 and a market-fit score of 7 out of 12. Its cost breaks down as follows.
| Item | Estimate |
|---|---|
| Ripple review, 400 hours at $100 to $200 an hour | $40,000 to $80,000 |
| External audit | $100,000 |
| Reference implementation | $50,000 |
| Ledger and wallet work | $25,000 |
| Total, on top of 640 build hours | $215,000 to $255,000 |
For scale, the whole roadmap lists 24 amendments, 2 approved and 22 proposed, for $5.08 million to $5.74 million and 6,240 build hours. Quantum alone is about a tenth of the build time.
Code exists, but only on branches. The roadmap points to xrplf/quantum in the XRPLF rippled repository; the draft’s own header lists another rippled branch, dilithium-full, plus branches of xrpl.js and the list publisher. A branch is not a release, and none of this has been merged into the server software that validators run.
Holders must switch off their old master key, and the draft says nothing about it
The foundation’s study puts it plainly: a dilithium regular key does not protect an account whose classical master key is still enabled. The ledger’s own rules explain why. A master key can be disabled but never changed or removed, according to the XRP Ledger documentation, and once a regular key is set, either one can authorise transactions. An attacker who recovered the classical master key could keep signing with it.
The fix exists today, as a separate step. An owner sends an AccountSet transaction with the asfDisableMaster flag, signed with the master key itself, and the ledger accepts it only if the account already has a regular key or a multi-signing list, according to the documentation’s how-to. The draft never mentions this step; it names only the regular-key route and moving funds to a new account. “Accounts that never rotate stay exposed,” the study adds, and that covers lost wallets, forgotten accounts and holders who never hear about the change.
Ripple’s April plan covers the worst case in a separate phase. If classical signatures were broken before most accounts had moved, the network would stop accepting them, and holders would prove ownership of their old keys with zero-knowledge proofs to move funds to post-quantum accounts. That phase has no date in Ripple’s plan, and the draft specification does not cover it.
Validators have their own exposure. Their manifests, the keys of the publishers of the recommended validator lists and the identities of nodes all use classical signatures. The study notes that a recovered list-publisher key would let an attacker replace the publisher’s list, and that a validator’s node identity changes when it rotates keys, so peer reservations and cluster settings would need updating across the network.
Open bugs in the reference code
The draft itself admits some faults in the current code, and the foundation’s study repeats them. The Python publisher of validator lists derives the ML-DSA seed from 48 bytes of SHA-512, while the server and the xrpl.js library use 32 bytes. The same seed therefore produces different keys depending on the software, so an operator who rebuilt a list-publisher key from its seed with another tool would get a different key pair. The draft says the Python module must be fixed before the specification becomes final.
The shared test-vector file the specification requires does not exist yet, according to the study. The admin commands sign and wallet_propose still reject the dilithium key type, which the draft acknowledges.
Comments on the GitHub discussion add more. On 15 October, the account quantova-inc, which used the same comment to promote its own memo-based proposal, argued that the ledger should name the signature scheme with an identifier rather than infer it from key length, so that a second post-quantum scheme could be added later without another format change. On 2 November, douglasborthwick-crypto argued that test vectors generated by the server only prove the code agrees with itself, noted that the round-3 Dilithium2 scheme and final ML-DSA-44 derive different keys from the same seed, and suggested NIST’s official ACVP vectors. On 9 November, quantova-inc, reviewing the quantum branch on a fork run by Transia-RnD, reported that the check behind a flag meant to force an account onto quantum signatures never fires for classical keys in checkSign, and that the multisign and batch paths have no such check at all. The same comment says the build pins the pre-standard round-3 Dilithium code, holds 2,528-byte secret keys instead of 2,560 and lacks the domain separation FIPS 204 calls for, so its keys would not work with other FIPS 204 software. It links a proposed fix on that fork.
Each of these is one commenter’s claim. Maintainers had not confirmed them in the thread as of the morning of 10 November. CoinDesk also notes that no network test with every validator running the new signatures has been published.
From a GitHub draft in 2025 to a 2028 target
The dates below show how slowly the pieces have come together, and why the deadlines that matter are set outside crypto.
- 13 August 2024: NIST publishes FIPS 204, the ML-DSA standard.
- 13 June 2025: AWS makes ML-DSA signing keys generally available in its key management service.
- 8 July 2025: Denis Angell opens XRPL-Standards discussion #295, Post-Quantum Signatures (ML-DSA-44).
- 20 April 2026: Ripple publishes its four-phase plan, with experiments in the first half of 2026 and a full transition through a new amendment no later than 2028.
- 20 May 2026: the draft specification is last updated.
- October 2026: NIST’s final IR 8547 says quantum-vulnerable public-key cryptography will be deprecated after 2030 and disallowed after 2035.
- 4 November 2026: the XRPL Foundation updates its roadmap with the Quantum amendment and its budget.
- 9 November 2026: CoinDesk reports on the design.
The G7 Cyber Expert Group asks financial firms to move their most critical systems to post-quantum cryptography between 2030 and 2032. Those targets, more than any estimate of when a machine will exist, explain why ledgers that serve banks and fund managers are planning now. How far away that machine is remains disputed; our report on the Alice & Bob estimate for breaking Bitcoin’s curve shows how many assumptions sit behind the shortest timelines. The industry has not agreed on what “quantum-resistant” should mean either, which is the question the nine-firm Quantum Alliance set out to answer in October.
What happens next for XRPL post-quantum signatures
The next step on paper is the migration study in the first half of 2027, which is meant to settle the open design questions, the fee treatment of large transactions among them. Development, review and an external audit follow in late 2027 or 2028. Ripple’s own plan sets 2028 as the latest date for the full transition.
Even then, the amendment would go live only if validators vote for it, like every change to the XRP Ledger’s rules. Votes do not always run smoothly; the network’s recent cleanup amendment slipped to 4 November after a short dip in validator support. No activation date exists for Quantum.
The nearer marker is the GitHub thread. The 9 November report on checkSign and the seed-length mismatch are specific enough to be confirmed or rejected in code, and a maintainer reply there would be the first sign of how fast the draft is moving.