XRP Ledger’s Quantum Roadmap Is Back in Focus – Now Comes the Hard Part

Ripple’s April roadmap is back in view as Bitcoin and Ethereum advance quantum-security work, but XRPL’s real challenge begins after an account rotates its key.
Key Takeaways
- Ripple wants migration prepared before Q-Day.
- AI weakened an undeployed post-quantum signature candidate.
- XRPL can rotate keys without replacing accounts.
- Mainnet activation requires sustained validator agreement.
Why quantum security is back in focus
Ripple does not want the XRP Ledger waiting for a working cryptographic quantum computer before preparing its response. “The goal is not to wait until quantum computing becomes an immediate threat,” RippleX Senior Director of Engineering Ayo Akinyele told CoinDesk.
Researchers use “Q-Day” to describe the point at which a quantum computer becomes capable of breaking public-key cryptography used by production systems. No publicly known machine has reached that capability.
Preparation has nevertheless become more visible across major networks. Bitcoin recently tested two different quantum-security approaches, while Ethereum has moved quantum safety higher in its architectural planning.
A separate development has complicated the choice of replacement cryptography. Anthropic’s Claude Mythos Preview found an improved key-recovery attack against HAWK, a post-quantum signature candidate under consideration by the National Institute of Standards and Technology.
For the smallest HAWK-256 configuration, expected attack work fell from approximately 264 operations to 238, a reduction of roughly 67 million times. The model produced the result after about 60 hours, according to Anthropic’s research report.
HAWK was not deployed on XRPL or any other production system, so the finding did not expose live accounts. It instead showed how quickly a candidate can lose ground even after surviving years of expert review.
AI does not bring Q-Day closer. It can, however, disqualify proposed defenses sooner. XRPL therefore needs more than one secure replacement for its current signatures; it needs a reliable way to change cryptography again if later research weakens the first choice.
Why exposed public keys create the risk
XRPL currently relies on elliptic-curve signatures to prove that the account holder authorized a transaction. Signing reveals the public key used to verify that authorization.
A sufficiently capable quantum computer could theoretically calculate the corresponding private key from the public key. An attacker could then produce signatures that satisfy the network’s existing rules.
The threat is not practical today. The concern is the time required to move active accounts away from exposed classical keys before such an attack becomes possible.
XRPL can rotate the key without replacing the account
An XRPL account address and the key authorized to control it are separate. Accounts have a master key pair, but they can also assign and later replace a regular key through a SetRegularKey transaction.
The address remains unchanged after another signer is assigned. Balances, trust lines, settings and ledger history stay connected to the same account.
During a planned post-quantum migration, that separation could reduce the need to transfer assets solely to adopt stronger cryptography.
What that could spare users
- Creating and registering another account address.
- Moving every asset during the migration.
- Updating addresses across connected financial services.
- Rebuilding account history around another identity.
The limitation is that XRPL can rotate only into signature systems mainnet already recognizes. Accounts cannot select a post-quantum signer until developers implement one and the network activates it.
Keeping the same address also works best when migration begins before an emergency. Ripple’s contingency planning allows for a harder response if classical signatures fail unexpectedly, potentially requiring funds to move under post-quantum protection.
Sui is examining the same user problem through another design. Its planned post-quantum signers could preserve existing account addresses, showing why account continuity is becoming part of migration planning across multiple networks.
XRPL has two possible migration scenarios
Ripple’s original post-quantum roadmap prepares for an orderly transition while keeping an emergency route available if quantum hardware advances faster than expected.
A planned transition
Ripple plans to compare several NIST-standardized signature schemes against real XRPL workloads. Security is only one test. Public-key size, signature size and verification speed determine whether a candidate can operate without placing excessive pressure on ledger storage or transaction processing.
Work with Project Eleven includes Devnet benchmarking, validator tests and an early custody-wallet prototype. Candidate post-quantum signatures are expected to operate beside the existing systems during this stage.
That overlap would give service providers time to update their signing infrastructure before classical signatures are retired. It would also reveal whether the new format creates problems for transaction throughput or validator hardware.
Ripple is targeting full post-quantum readiness by 2028, although that target does not guarantee when a mainnet amendment will activate.
An emergency recovery
The second scenario begins if quantum hardware threatens classical signatures before the planned transition is ready.
XRPL could stop accepting the affected signatures, but a valid classical private key might no longer establish who owned an account first. An attacker could possess a mathematically correct key calculated from public information already visible on the ledger.
Ripple is investigating whether seed-derived information and post-quantum zero-knowledge proofs could provide a separate ownership test. That method remains exploratory; no finished recovery specification or user process has been released.
Mainnet activation requires validator agreement
Individual accounts can choose an authorized key, but they cannot decide which signature algorithms XRPL accepts. Adding another verification system changes the network’s transaction rules and therefore requires an amendment.
Under the official XRPL amendment process, a protocol change must maintain more than 80% support from trusted validators for two weeks before activation.
The new code must already be included in the software those validators run. Servers that lack support after activation can become amendment-blocked because they can no longer process the ledger under the updated rules.
Akinyele told CoinDesk that the transition would reach beyond swapping one algorithm for another. The supporting infrastructure must let accounts and financial services adopt new security without interrupting payments or access to funds.
HAWK explains why that process must be repeatable. An algorithm can survive extensive review and still be weakened later. XRPL cannot build its migration around the assumption that the first post-quantum system it selects will remain the final one.
What XRP holders should watch today
Ripple has not asked XRP holders to move funds, create replacement accounts or rotate into post-quantum keys. Ordinary XRPL accounts do not yet have that option on mainnet.
- Do not trust unsolicited “quantum-safe” wallet instructions.
- Continue protecting seeds and signing devices normally.
- Separate Devnet experiments from mainnet protection.
- Use only officially supported future migration tools.
- Follow amendment votes through official XRPL sources.
Four developments would show that migration is approaching: a selected signature scheme, published performance benchmarks, supported wallet tools and a live amendment vote. Until those appear, XRP holders have no quantum-specific transaction to perform.
XRPL can replace the key controlling an account without rebuilding the account around it. That could prevent an orderly security upgrade from turning into a mass address migration.
The roadmap succeeds when ordinary accounts can adopt the new signer through supported software on a network whose validators already agree on the rules.









