XRPL fixed a bug that could have minted 18 trillion XRP

The XRP Ledger’s September 25 software release fixed a payment-engine bug that could have let an attacker create spendable XRP beyond the supply limit. The XRPL Foundation’s vulnerability report says the flaw had likely been present since 2015, and developers found no evidence it was exploited on a public network.

The payment engine handles transactions that buy through offers in the ledger’s order book. With a specially built set of hundreds of offers, the engine could add the XRP amounts using a 64-bit counter that was too small for the total. Instead of returning an error when that counter overflowed, it wrapped around to a much smaller number.

The engine would credit each offer owner the full amount, while charging the buyer only the wrapped total. The separate “no XRP created” safety check used similar arithmetic and also failed to catch the difference. The Block’s report, citing Veria Labs co-founder Cayden Liao, says one demonstrated transaction could have created about 18 trillion XRP—roughly 184 times the original 100 billion supply.

How could a payment create XRP from nothing?

An attacker could control a few hundred accounts, each offering a tiny amount of another asset for an enormous amount of XRP. A payment routed through all those offers would make the engine total the large XRP amounts. The engine would pay each seller in full but charge the buyer only the small wrapped sum, leaving newly created XRP spread across the seller accounts.

Think of an odometer rolling over after it passes its maximum reading: the displayed total becomes small even though the underlying distance keeps growing. Here, the payment engine’s total rolled over, but the individual seller credits did not. The offer prices would have been far outside normal trading, and the attack required a payment designed to consume them all at once.

What does the 3.4.1 fix change?

The release checks whether totals across order-book offers or payment paths would overflow. If they would, that part of the payment fails instead of creating XRP. The report also says the network’s supply-check counter was widened so it cannot wrap around in the same way.

XRPL transaction-rule changes usually wait for more than 80% of trusted validators to support an amendment for two weeks. This fix instead took effect separately on each server as its operator upgraded to 3.4.1. The report says more than 80% of validators on the default Unique Node List were running the release on September 25, the day it shipped.

Why did the patch skip the usual validator vote?

XRPL’s disclosure report says the ordinary amendment process would have exposed the fix in open-source code while the vulnerability remained exploitable during the voting and activation period. The direct release reduced that window, but created a temporary risk: upgraded and older servers could process a deliberately crafted payment differently. Developers judged that risk lower than leaving a publicly visible exploit open for weeks.

Sources and documents

• XRPL Foundation’s vulnerability report — xrpl.org
• The Block’s report — theblock.co