XRP Ledger fixes flaw that could mint 18 trillion tokens

The XRP Ledger fixed a payment engine flaw that could have let an attacker create and spend XRP beyond the token’s 100 billion supply, according to the network’s vulnerability disclosure report. The bug was believed to date to 2015. Developers said they found no evidence it was exploited on a public network.

The flaw was in how a payment could consume many offers on the ledger’s built-in exchange. The Block reported that Veria Labs co-founder Cayden Liao estimated one exploit could have created about 18 trillion XRP, 184 times the total supply. That estimate came from Liao; the XRPL report confirms the minting mechanism, but does not state that figure.

How could one payment create new XRP?

Each account’s offer could be valid on its own. An attacker could set up hundreds of accounts, each offering a tiny amount of another token for an unusually large amount of XRP. Then a single payment could be made to consume all those offers.

The payment engine added up the XRP owed across the offers using a 64-bit integer. If the total exceeded the number that integer could hold, it wrapped around to a small value, like an odometer rolling back to zero. The engine still credited each seller account with its full offer amount, but charged the buyer only the wrapped total.

The ledger’s “no XRP created” safety check used the same kind of arithmetic, so its total wrapped too and failed to catch the mismatch. The XRP was spread across accounts, keeping each balance below the separate per-account limit. RippleX reproduced the exploit on a standalone server and confirmed the resulting XRP could be spent in another payment.

What changed in the patch?

RippleX added overflow checks to the payment engine’s offer totals and to the step that combines results from multiple payment paths. If a total would overflow, that part of the payment now fails. The “no XRP created” check also uses a wider counter that cannot wrap around in the same way.

The fix shipped in xrpld version 3.4.1 on September 25, 2026. More than 80% of validators on the default Unique Node List were running that version or later on release day, the disclosure report says. The project later published the report on October 9.

Why did the fix bypass the usual validator vote?

Normally, transaction rule changes take effect through an amendment: more than 80% of trusted validators must support the change for two weeks. This fix instead took effect on each server as its operator upgraded to version 3.4.1.

The report says developers chose that route because an amendment would have left the vulnerability publicly visible while it remained exploitable during the voting and activation period. The faster rollout carried a risk of different software versions disagreeing if the exploit were used during the upgrade. Developers judged that risk preferable to allowing a transaction that could create XRP, and said the exploit required deliberately crafted offers and a payment; normal trades could not trigger it.

Sources and documents

• vulnerability disclosure report — xrpl.org