XRPL fixes payment overflow that could mint trillions of XRP

The XRP Ledger patched a payment-engine flaw that could have created spendable XRP beyond its 100 billion supply, RippleX said in its xrpld 3.4.1 vulnerability disclosure report. The fix shipped on September 25 and took effect as servers upgraded, bypassing the usual validator amendment process to close a critical exploit path.

The report says the bug appears to have been present since the current payment engine was written in 2015. RippleX reproduced the exploit on a standalone server and confirmed the resulting XRP could be spent in a later payment. It found no evidence that the issue had been exploited on a public network.

How could one payment create new XRP?

The payment engine added amounts across order-book offers using unchecked 64-bit integer arithmetic. A crafted payment could consume hundreds of offers, each individually valid but collectively large enough to exceed the integer’s limit. The total then wrapped around to a small value.

The engine still credited each offer owner the full XRP amount, while charging the buyer only the wrapped total—potentially a few hundred drops plus the transaction fee. An attacker could control the offer-owning accounts and spread the new XRP across them. The XRP Ledger’s “no XRP created” invariant also used a 64-bit counter; it wrapped in the same way, so the net change appeared to be only the fee. The per-account balance check did not catch it because no single account needed to exceed the total supply.

The attack required hundreds of deliberately priced offers and a payment constructed to consume them all. RippleX says normal payments and trades would not reach the overflow. Offers priced badly enough to trigger it would sit below real liquidity, so testing found they could not block ordinary payments or pathfinding. The Block reported that Veria Labs co-founder Cayden Liao estimated one exploit transaction could have created about 18 trillion XRP; that figure is his estimate, not a quantity observed on the network.

What changed in xrpld 3.4.1?

Starting with version 3.4.1, the payment engine checks for overflow when summing offer amounts and when combining results from multiple payment paths. If a sum would overflow, that part of the payment fails with a normal “path dry” or “partial payment” result. RippleX also changed the “no XRP created” invariant to use a wider counter that cannot wrap around, and hardened other balance-summing paths as a precaution.

The fix applies as each server upgrades. Normally, transaction-processing changes are gated by an amendment: more than 80% of trusted validators must support it for two weeks, after which the new rule activates at the same ledger across servers. RippleX said this fix was the first deliberate transaction-processing change shipped outside that system since it was introduced more than a decade ago.

Why skip the amendment process?

RippleX said an amendment would have exposed the fix in open-source code while leaving the vulnerability exploitable through the voting and activation period. The direct release shortened that window, but created a temporary mixed-version risk: upgraded servers would reject the exploit while older servers could accept it, potentially causing disagreement over ledger contents.

More than 80% of validators on the default Unique Node List were running 3.4.1 on release day, according to the report. RippleX judged the quick upgrade safer than leaving a public, working exploit open for weeks. The exception does not change the stated amendment process for ordinary transaction-rule changes.

Sources and documents

• xrpld 3.4.1 vulnerability disclosure report — xrpl.org
• The Block reported — theblock.co