The XRP Ledger quietly fixed a bug that could have created 18 trillion XRP

What happened

The fullest public account yet of the XRP Ledger's September emergency arrived in two installments this month: an October 9 technical disclosure from RippleX and the XRP Ledger Foundation, and an October 11 explainer from the Foundation answering the questions that disclosure raised. Together they describe a flaw in the ledger's payment engine, apparently present since 2015, that could have let an attacker create spendable XRP far beyond the network's fixed supply of 100 billion.

The flaw was an integer overflow. When the payment engine settles a payment that consumes several offers on the ledger's built-in decentralized exchange, it adds up the XRP amounts across those offers with a 64-bit integer to calculate what the buyer owes. The researchers found that an attacker could create hundreds of specially priced offers and arrange for one payment to consume them all. When the summed total exceeded the largest value the integer could represent, the total wrapped around to a much smaller number. The system still credited the individual sellers with the full XRP amounts their offers specified, even though the buyer paid only the reduced, wrapped-around amount. The difference was newly created XRP that the ledger accepted as valid.

The ledger's own defenses failed in two ways. The supply check meant to catch unauthorized XRP creation used the same vulnerable arithmetic as the payment calculation, so it could not detect the discrepancy. A separate account-balance check could be bypassed by spreading the new coins across many wallets.

The discovery came through the network's bug bounty program. Researchers at the security firm Veria Labs found the issue on September 21 while testing the ledger's open-source software, built a working proof of concept on a local test network the following day, and submitted it through the official bounty channel on September 22. Their demonstration showed that one specially designed transaction could create roughly 18.45 trillion XRP, about 184 times the intended total supply, spread across 256 accounts so that no single account crossed its cap. The setup was cheap: a few hundred XRP in refundable account reserves plus ordinary transaction fees. RippleX engineers reproduced the attack on a standalone server and confirmed that the newly created coins could be spent in a subsequent payment. The initial severity rating was major; the team raised it to critical after confirming the consequences. For the responsible disclosure, the researchers received the bounty program's maximum award of 250,000 dollars, paid on October 8.

The fix moved quickly and broke with normal procedure. RippleX built the patch between September 22 and 23 and shipped it in xrpld version 3.4.1 on September 25. The update adds checks that reject payment calculations exceeding the permitted integer range, returning an ordinary payment failure instead of creating coins, and it replaces the supply-verification arithmetic with a wider counter designed to catch this class of error. Additional balance calculations were reviewed as a precaution.

Under normal circumstances, changes to transaction processing on the XRP Ledger must pass through the amendment system, which requires support from more than 80 percent of trusted validators for two consecutive weeks before activation. The Foundation said it deliberately skipped that process. Because the ledger's software is open source, publishing the patch would have revealed the vulnerability's location while leaving it exploitable during the approval window. Instead the fix took effect as validators upgraded their software, and by September 25 more than 80 percent of validators on the default Unique Node List were running version 3.4.1. The public source code was released only after the network was protected.

The October 9 disclosure covered a second, separate flaw involving the Batch transaction feature, which lets developers combine up to eight transactions into a single operation. Researchers found that under certain conditions the software accepted alternative field names where the protocol required a specific RawTransaction field, and that different server versions could process those malformed transactions differently, creating a potential consensus risk. The fix came as the fixBatchV1_2 amendment, and it activated on mainnet on October 9 alongside the BatchV1_1 feature, with 30 validators supporting and five opposing, according to network figures cited in the reporting. Servers running older software are now amendment-blocked and must upgrade to version 3.4.1 or later to stay synchronized.

Then, on October 11, the Foundation published its explainer addressing the questions the disclosure had raised. Was any XRP created? No: the supply was fixed at 100 billion when the ledger launched, and the investigation found no evidence the flaw was ever exploited on a public network. Why did the patch ship before the full technical account? Because the normal approval process would have exposed the vulnerability while it was still exploitable. Who chose to install it? Validators, upgrading in consultation with the Foundation, RippleX and validator operators.

Why it matters

The incident is a case study in how much of a public network's security rests on assumptions nobody rechecks. A fixed supply is the most basic promise a cryptocurrency makes, and this bug sat in the payment engine for roughly a decade, surviving every review cycle since 2015, until an AI-assisted testing system chained two modest-looking issues into a catastrophic one. The overflow only became dangerous in combination: the payment total wrapping around was one flaw, and the supply guard using the same broken arithmetic was the other. Either alone would have been a footnote. Together they were a path to manufacturing 184 times the entire supply for the price of a few hundred XRP in refundable deposits.

That the flaw was never exploited is the official finding, and the public ledger makes that claim checkable in a way most security incidents are not: the supply and transaction history are visible to anyone. Still, the episode leaves a governance precedent worth examining. Skipping the amendment process was the right call under the circumstances the Foundation describes, and the validator set's rapid upgrade, with more than 80 percent on the new version within three days of the report, shows the coordination worked. But it also shows that emergency response on this network now depends on out-of-band coordination between a small set of actors: the developer division that writes the patch, the foundation that calls the emergency, and the validator operators who install it before the public can see what changed. The normal two-week amendment window exists to let the whole ecosystem, including dissenters, evaluate a change. This time there was no window, and the five validators that later opposed the Batch activation are a reminder that consensus about process is not automatic.

The disclosure also quietly documents how security work is changing. The flaw was found by an automated security testing system, the proof of concept was built in a day, and the bounty paid was the program's maximum. As AI-assisted testing gets better at chaining small issues into big ones, networks should expect more findings of this shape: not single dramatic bugs, but combinations of individually modest weaknesses that together break a core invariant.

What to watch

Watch the Foundation's new verification rule. It says previously reported security issues must now be tested again against release candidates before being classified as fixed, a procedure that will apply to audit findings, bounty reports and AI-assisted testing alike. Whether that catches the next chained flaw will be the real test of the lesson.

Watch the Batch aftermath. The October 9 activation means any server still on older software is now amendment-blocked and cut off from consensus until it upgrades. If stragglers cause validation hiccups in the coming days, the emergency will have had a visible cost.

Watch for the formal verification work the Foundation says is planned next. The October 11 explainer promised stronger security testing, and the interesting question is whether the payment engine gets machine-checked proofs of its arithmetic invariants rather than another round of manual review. An overflow bug is exactly the class of flaw formal methods are built to eliminate.

Finally, watch whether other networks audit their own payment arithmetic. The technique here, overflowing a sum across many offers while the guard uses the same math, is not specific to one codebase. Every ledger with an on-chain exchange and a supply invariant just got a free test case.