XRP Ledger patches flaw that could have threatened its fixed supply

A flaw in the ledger’s exchange engine

The vulnerability involved the XRP Ledger’s built-in decentralized exchange and the way its software counted the combined value of multiple offers. In a disclosure published by the XRP Ledger Foundation, the project explained that an attacker could exploit an overflow in XRP payment calculations when a single transaction matched a large number of offers.

The potential attack was technically demanding but inexpensive. An attacker could create hundreds of accounts, then use those accounts to place offers involving very small amounts of another token in exchange for unusually large amounts of XRP. A later payment could attempt to match all of those offers at once.

The combined amount of XRP owed would exceed the software’s counting capacity. Instead of correctly rejecting the transaction, the vulnerable logic could calculate an incorrect total. The selling accounts could then receive the XRP promised by their offers, while the account executing the payment was charged little or almost nothing.

That created the possibility of XRP entering circulation without a corresponding payment. The newly received tokens could subsequently be spent in other transactions, turning an accounting failure into a potential supply-integrity crisis.

The issue was not simply that one account might receive too much XRP. The ledger’s normal post-transaction supply check also depended on the same miscalculated total. As a result, the safeguard intended to detect an imbalance could fail alongside the payment calculation.

Account-level receiving limits presented another obstacle, but researchers said those limits could potentially be bypassed by spreading the newly created XRP across many accounts. The attack reportedly required only a few hundred XRP to establish the necessary accounts. Most of that amount could be recovered, leaving transaction fees as the main cost.

Reproduced before disclosure

The vulnerability was reported internally on September 22 by security researcher Cayden Liao and Veria AI. CoinDesk reported that RippleX, Ripple’s developer arm, reproduced the issue on a standalone server after receiving the report.

The researchers’ account, published by Veria Labs and Cayden Liao, describes the incident as a potential “biggest hack in crypto history” that never occurred. The researchers said they used Veria AI during the investigation, reproduced the exploit, and received the maximum $250,000 bug bounty for reporting it.

Those claims describe the researchers’ position and the reported reward. No opposing account was provided in the supplied sources. RippleX said it found no evidence that the vulnerability had been exploited on a public network.

The timing of the fix limited the window between discovery and public disclosure. RippleX shipped the repair in the xrpld 3.4.1 server-software release on September 25, before the technical details became public.

The official xrpld 3.4.1 release identifies the update as a required security release. It documents the fix, the related fixBatchV1_2 amendment, and the accompanying vulnerability disclosure. Operators running XRPL servers were required to upgrade to the patched version.

Why supply integrity matters

The vulnerability was significant because XRP’s fixed supply is central to the asset’s monetary narrative. If an attacker had been able to create large quantities of XRP and move them through ordinary transactions, the consequences would have extended beyond one compromised account or application.

A successful exploit could have challenged confidence in the ledger’s accounting model, affected the value of existing holdings and created uncertainty for institutions using XRP for payments or liquidity. The incident also shows why decentralized exchanges are part of a blockchain’s core security surface, not merely optional trading infrastructure.

Exchange logic must reconcile individual orders, account balances, payment paths and network-wide supply rules. A failure in one calculation can undermine several safeguards at once, especially when the same value is reused for both transaction execution and validation after the transaction.

The episode also illustrates the difficulty of auditing long-lived financial software. The flaw dated back to 2015, meaning the vulnerable logic remained in the codebase for years without a publicly known exploit. Its discovery required researchers to combine an understanding of offer matching, account creation and integer overflow behavior.

A broader test for mature networks

The XRP Ledger’s response followed a familiar security pattern: private disclosure, reproduction, emergency remediation and public explanation after operators had time to upgrade. That process reduced the risk that technical details would become available before the patch was deployed.

Still, the episode raises questions for other mature blockchain networks. Supply checks should be tested not only against ordinary user activity, but also against transactions designed to stress numeric limits, aggregate hundreds of accounts and force several accounting paths to process extreme values simultaneously.

The incident may also encourage more security researchers to use artificial intelligence as an auditing aid. Veria Labs and Liao attributed their discovery to work involving Veria AI, although the supplied sources do not establish that AI independently found or proved the vulnerability.

There is no reported evidence of public-network exploitation. The more important lesson is preventive: fixed supply is not protected by a single rule. It depends on every payment, exchange and validation path preserving the same accounting assumptions.