XRP Ledger Foundation Outlines Quantum Upgrade Targeting 2028
The XRP Ledger Foundation has outlined ML-DSA-44 post-quantum signatures for accounts, validators and list publishers. Base fees stay flat, transactions grow about 213%, and review costs are put at $215,000 to $255,000. No mainnet date is set.
The XRP Ledger Foundation has outlined a proposed upgrade to protect XRP accounts, validators and validator list publishers against future quantum attacks, using the NIST-approved ML-DSA-44 signature algorithm. The research was published as part of the foundation's 2027 protocol roadmap.
Accounts on the ledger currently use secp256k1 or Ed25519 keys. Both could theoretically be broken by quantum computers running Shor's algorithm. NIST approved ML-DSA-44, a lattice-based signature scheme, in 2024.
How the design works
Under the proposal, account owners would register a post-quantum key and disable the classical one. The address and balances stay unchanged, and funds would not need to be moved.
The trade-off is size. A protected transaction would need about 5,331 bytes of storage, against 1,704 bytes for a conventional payment, an increase of roughly 213%. Keys and signatures alone take 3,732 bytes, versus 105 bytes for a standard payment.
The base transaction fee would not rise. Because XRP Ledger fees are destroyed rather than paid to validators, the extra storage burden falls on network operators.
Cost and timeline
The work is estimated at about 640 development hours and 400 review hours. Review, audit and related expenses are put at $215,000 to $255,000, excluding initial development.
An implementation has been tested on AlphaNet, but more development and security review is needed. The proposed schedule calls for a migration study in the first half of 2027, followed by development, review and auditing in late 2027 or 2028. No mainnet activation date has been approved.
Open issues
Transaction fees, account migration and software compatibility remain unresolved. Adding a quantum-resistant regular key would not fully secure an account if the vulnerable master key stays enabled.
That makes user action the deciding factor. Owners must disable the old key, and accounts that keep both methods enabled stay partially exposed.
Developers are also fixing inconsistencies in which the Python, JavaScript and server implementations generate different keys from the same seed.
The larger transactions could affect bandwidth, history storage and operating costs. Validators must also approve any change, and auditors must review the code. The foundation also maintains a recommended validator list, which it updated in October to add Flare.
Context
The proposal follows Ripple's April announcement of a four-phase quantum security strategy targeting full post-quantum readiness by 2028. That plan includes experimental deployments, contingency planning and work with Project Eleven on hybrid signing, validator testing and custody wallet prototypes.
Other chains are preparing as well. Bitcoin has BIP 360, Ethereum is targeting around 2029, Solana has a Falcon scheme, and Starknet is also working on the problem. No quantum computer has yet shown it can break the cryptography securing major blockchains.
For XRP holders, the practical question is migration: the design keeps addresses and balances intact, but protection depends on each owner switching keys once the feature is live.



