XRP Ledger Proposes Quantum-Resistant Accounts With No Added Transaction Fees

The XRP Ledger Foundation is developing a proposal for quantum-resistant accounts, aimed at a security risk that remains prospective. The feature would let account holders register signing keys using NIST-approved ML-DSA-44 and deactivate their existing authentication keys. The stated goal is to strengthen account security without raising transaction fees.

The timing matters because some XRPL public keys have already been exposed on the network. Transaction signing can reveal a public key, creating a potential point of attack if sufficiently advanced quantum computers can break current cryptographic protections. That threat isn't described as practical today; the proposal is intended to give users a path to strengthen security before it becomes one.

New keys, familiar account access

Adopting the proposed protection wouldn’t require users to change how they store, hold, or access XRP. The stated cost advantage is straightforward: accounts could gain quantum-resistant signing without additional transaction fees. That combination could lower the friction of adoption, since users wouldn't have to accept a new account routine or a higher transaction cost just to improve their signing security.

Here's the thing: keeping the familiar account experience is only one part of a successful migration. Users also need a clear way to register the new key, confirm that it works, and deactivate the old authentication key without losing access. The proposal's description doesn't yet settle those operational details, so the convenience claim depends on how the feature is ultimately implemented.

This is more significant than it looks. Account security upgrades often succeed or fail on the practical steps users must take, not on the cryptographic design alone. If you're working in this space, the key question is whether the migration process can make those steps clear enough for ordinary account holders to complete confidently.

Migration research is planned for 2027

The next stated step is a migration study planned for the first half of 2027. It will examine how existing XRPL accounts could move to the new security framework and what account holders would need to do. That makes the study a practical checkpoint: it should help turn a proposed capability into a process that can be evaluated by developers and users.

Developers are also working to resolve differences in cryptographic key generation across Python, JavaScript, and server implementations. Consistent behavior across those environments will be necessary for the proposed system to work reliably. A key generated in one environment must be handled predictably by the others, or developers could face avoidable compatibility problems as they build support for the feature.

There’s a less visible challenge here: a security upgrade has to be understandable as well as technically sound. Account holders need to know which key controls access, what changes when the old authentication key is deactivated, and how the new arrangement affects their usual use of XRP. (And this is the part most people overlook.) The migration study could clarify those questions, but its findings aren't available yet.

What the proposal signals for XRPL security

Ripple has set 2028 as its target for making the XRP Ledger ready for post-quantum security, within a four-phase roadmap. The proposed account feature is an early piece of that effort, while the planned 2027 study is meant to examine how existing accounts could migrate before that target date. The schedule gives the work a defined direction, though a target date alone doesn't show how much implementation remains.

That said, the proposal is a concrete response to a long-range security concern: it identifies a signing method, an account-level change, and a migration study as parts of the work. The remaining questions are practical ones. How users will register and manage the new keys, and how consistently those keys will be generated across supported environments, will shape whether the feature can be adopted safely.

For now, the proposal is still under development. The 2027 study should offer a clearer account of migration requirements; until then, the promise of unchanged fees and familiar access is a design aim, not a complete description of the finished user experience.