XRPL patches bug that could have created 18 trillion XRP

RippleX fixed a decade-old XRP Ledger bug on Sept. 25 that Veria Labs says could have created about 18 trillion XRP in one transaction; the ledger’s vulnerability report says there is no evidence the flaw was exploited on a public network.

• About 18 trillion XRP could have been created in one transaction, according to Veria Labs co-founder Cayden Liao, cited by The Block.
• The XRP supply was capped at 100 billion when the ledger launched.
• The bug was reported on Sept. 22, 2026; the fix shipped three days later in xrpld 3.4.1.
• More than 80% of validators on the default Unique Node List were running the fixed release on Sept. 25.

The flaw was in the payment engine, which processes transactions through the XRP Ledger’s built-in exchange. A payment could consume hundreds of offers at once, and the software could miscount the total XRP owed.

How could one payment create new XRP?

An attacker could have spread offers across hundreds of accounts, each offering a tiny amount of another token for an unusually large amount of XRP. A single payment could then buy all the offers at once.

The engine paid each seller the full XRP amount but charged the buyer only a small amount, because the sum had exceeded the maximum its counter could hold. This kind of counting error is called an integer overflow: when the number gets too large, it wraps around to a much smaller one.

The ledger’s check for newly created XRP used similar arithmetic and missed the difference. Its per-account balance check also would not have stopped the attack, because the attacker could spread the XRP among many accounts.

The offers would have needed to be priced so badly that ordinary trades would not reach them. The attacker would have had to craft a payment specifically to consume them together, according to the [The Block report on the bug](https://www.theblock.co/news/ecosystems/2026-10-11-xrp-ledger-patches-decade-old-bug-that-could-have-minted-trillions-of-xrp).

What did the patch change?

The xrpld 3.4.1 software checks for overflow when it adds amounts across offers and payment paths. If a total would overflow, that part of the payment fails instead of creating XRP.

Developers also changed the “no XRP created” safety check to use a wider counter that cannot wrap around in the same way. The report says the bug appears to have been in the payment engine since it was written in 2015, but ordinary payments do not reach the values needed to trigger it.

Why did the fix skip a validator vote?

The fix took effect as individual servers upgraded, rather than waiting for the XRP Ledger’s usual amendment process. Ordinarily, a rule change needs more than 80% support from trusted validators for two weeks before it activates across the network.

The report says the team chose a direct release because making the fix public weeks before it took effect could have left the exploit available while operators upgraded and validators voted. That choice carried a risk: during the rollout, servers on different versions could have disagreed about an exploit transaction. The report says developers judged that risk lower than leaving a cheap attack open after disclosure.

Veria Labs reported the issue through the XRPL bug bounty program, and RippleX reproduced the exploit on a standalone server. Liao said the firm received the program’s maximum $250,000 bounty. The patch closed the route to creating spendable XRP; developers have not reported finding evidence that anyone used it on a public network.

Sources and documents

• vulnerability report — xrpl.org