XRPL fixes payment bug that could mint 18 trillion XRP

The XRP Ledger patched a payment-engine bug that could have created spendable XRP beyond the token’s intended supply, XRPL developers disclosed on Oct. 9. The flaw was fixed in the xrpld 3.4.1 release on Sept. 25, and developers said they found no evidence it was exploited on a public network.

How could one payment create XRP?

The payment engine can fill a payment by taking offers from the ledger’s built-in order book. It adds up the XRP owed across the offers, but the total used a fixed-width 64-bit integer without an overflow check. When a total exceeded the number that type could hold, it wrapped around to a small number instead of producing an error.

An attacker could create hundreds of accounts, each offering a tiny amount of another token for an enormous amount of XRP. A payment from a separate account could then consume those offers at once. The engine would credit each offer owner the full XRP amount, while charging the buyer only the wrapped total. The analogy is an odometer rolling over: the displayed total becomes small even though the underlying distance keeps adding up.

XRPL’s vulnerability disclosure report says the ledger’s “no XRP created” safety check used similar arithmetic, so it could wrap around in the same way and miss the extra XRP. The attacker could spread the credited balance across many accounts, avoiding the separate check that rejects a single account holding more XRP than the total supply.

Who found the flaw, and how much XRP was at stake?

The report says the vulnerability was submitted through the XRPL Bug Bounty program on Sept. 22. It credits Cayden Liao and Veria AI with the original report and proof of concept. RippleX reproduced the mint on a standalone server and confirmed the created XRP could be spent in another payment.

The report does not give a maximum amount. The Block, reporting on Liao’s estimate, said one exploit transaction could have created about 18 trillion XRP—184 times the 100 billion XRP created at launch. That figure is Liao’s estimate, rather than a total specified in the XRPL disclosure.

How did the patch reach the network?

In xrpld 3.4.1, the payment engine checks whether adding offer amounts would overflow and fails that part of a payment cleanly if it would. The “no XRP created” check now uses a wider counter. The release shipped Sept. 25, and more than 80% of validators on the default Unique Node List were running it that day, according to the report.

Usually, a transaction-rule change waits for support from more than 80% of trusted validators over two weeks. This fix took effect on each server when it upgraded. Developers said a normal amendment process would have exposed the fix in public source code while the flaw remained exploitable during the voting and activation period. The quicker rollout carried a different risk: during upgrades, old and new servers could have disagreed about an exploit payment. The report says validators upgraded quickly to limit that window.

Sources

• vulnerability disclosure report — xrpl.org
• reporting on Liao’s estimate — theblock.co