XRP Ledger Eyes 2028 Quantum Security With $255,000 Plan, No Added User Fees

The XRP Ledger (XRPL) Foundation has outlined a proposal to protect cryptocurrency accounts against future quantum-computing attacks without increasing users’ transaction fees. The proposed upgrade would allow account holders to introduce quantum-resistant signing keys and disable their existing cryptographic keys. Included in the Foundation’s November 4 update to its 2027 protocol roadmap, the initiative represents an important step toward strengthening blockchain security, although development, testing and approval remain outstanding.

XRPL Develops Quantum-Resistant Accounts

The proposed upgrade addresses a potential weakness in conventional blockchain cryptography. When an XRP Ledger account signs a transaction, its public key becomes visible on the network. A sufficiently advanced quantum computer could theoretically use that information to derive the corresponding private key, potentially allowing an attacker to access the account’s funds.

The Foundation’s proposed solution would enable users to add a new quantum-resistant signing key and deactivate their original key. This would reduce exposure to future attacks while allowing existing accounts to migrate without abandoning their established addresses.

The proposal uses ML-DSA-44, a post-quantum digital signature algorithm standardized by the U.S. National Institute of Standards and Technology (NIST) in 2024. Previously known as CRYSTALS-Dilithium, the algorithm is designed to resist attacks from both conventional and sufficiently powerful quantum computers.

The approach is particularly relevant for cryptocurrency exchanges, institutional custodians and individual investors whose accounts have previously signed transactions.

$255,000 Budget Keeps Fees Unchanged

Quantum-resistant cryptography requires considerably more data than conventional signature systems. According to the Foundation’s technical estimates, the proposed implementation would increase transaction-related storage requirements.

The figures highlight the difference:

• 3,732 bytes: Combined size of the new public key and signature.
• 105 bytes: Corresponding size under the conventional payment comparison.
• 5,331 bytes: Estimated total storage per protected payment, including historical and database overhead.
• 1,704 bytes: Baseline storage requirement for a conventional payment.

Despite the additional data requirements, the proposal would leave the XRP Ledger’s base transaction fee unchanged. Because XRPL transaction fees are permanently destroyed rather than distributed to validators, network operators would effectively absorb the additional storage burden.

The Foundation has allocated between $215,000 and $255,000 for external review and security auditing, alongside approximately 640 hours of development work. Its broader 2027 roadmap covers 24 amendments, with estimated spending ranging from $5 million to nearly $6 million.

2028 Quantum Transition Faces Testing

The upgrade remains under development, with several technical challenges requiring attention before deployment. Developers are addressing inconsistencies between Python, server and JavaScript implementations that currently produce different keys from the same initial seed.

Testing is also needed to establish how validators perform when the proposed signatures are used across the network. Validator participation is essential because amendments require sufficient support through the ledger’s consensus-based voting process.

The Foundation’s planned milestones include:

• First half of 2027: Complete the quantum migration study.
• Late 2027 or 2028: Advance development, technical reviews and security audits.
• By 2028: Target a broader transition toward quantum-resistant signatures.

Ripple separately outlined its four-phase quantum-security strategy, targeting full post-quantum readiness by 2028.

Conclusion

The XRP Ledger’s proposed quantum-resistant upgrade could strengthen long-term account security without increasing transaction fees. However, successful implementation will depend on resolving technical inconsistencies, completing independent audits and securing validator approval. The 2028 target remains a development objective rather than a confirmed deployment date.