RippleX Patched an XRPL Overflow Bug That Could Have Minted XRP

The XRP Ledger has published an account of an arithmetic flaw that let a single crafted payment hand out more XRP than the buyer paid for. RippleX, Ripple's developer arm, shipped the fix as xrpld 3.4.1 on 25 September and put out the disclosure report two weeks later, on Friday. The bug sat in the payment engine's handling of multiple trade offers, where a 64-bit running total could wrap around past its ceiling. Offer owners were credited in full while the buyer was charged almost nothing, and the ledger's own check against newly created XRP ran on the same unchecked sum, so it missed the gap. The report says no evidence of exploitation was found on any public network.

How the overflow worked

The attack ran through the ledger's built-in order book, where accounts post standing offers to swap one asset for another. An attacker would open hundreds of accounts, each offering a tiny quantity of some token for an unusually large quantity of XRP, then send one payment that consumed every offer at once. The total owed was too large for the software to add up correctly. Nothing about an ordinary payment could trigger it, and the per-account cap on incoming funds would not have fired either, because the proceeds were spread across hundreds of addresses.

The cost of trying was small. Opening the accounts took a few hundred XRP in reserves, most of which is recoverable, plus transaction fees. CoinDesk, which reported the disclosure early on Saturday, said RippleX reproduced the attack on a standalone server and confirmed the created XRP could be spent in a later transaction; that account is the only one of the five read for this story that describes the reproduction, so it is single-sourced. Cayden Liao and Veria AI reported the flaw through the bug bounty program on 22 September and supplied the proof of concept.

The fix skipped the usual vote

Changes to how the XRP Ledger processes transactions normally go through an amendment, a protocol change that validators vote on for two weeks before it takes effect. This one did not. The report describes the decision to apply the overflow checks on upgrade, outside that process, as deliberate and the first of its kind for a transaction-processing change. The practical effect is that the repair landed the moment operators installed the release. More than 80% of validators on the default trust list were running 3.4.1 on the day it came out, and servers still on older builds are now blocked from voting on amendments at all.

A second bug activated on Friday

The same release carried a fix for an unrelated problem in Batch, the feature that bundles several transactions into one. Servers running 3.3.0 and 3.4.0 did not insist that each inner transaction be wrapped in a RawTransaction field, which could break parsers and, on a network running mixed versions, leave validators reading the same bundle differently. That fix needed an amendment, and it activated on mainnet on Friday alongside the Batch feature itself, whose two-week countdown had already been reset once in September.

"No loss of funds, private key compromise, or consensus failure occurred," the disclosure report said of the Batch issue.

The gap in the account

Nobody has published how much XRP one exploitation could have produced. All 100 billion XRP were created when the ledger launched in 2012, and the software is built so that no more can be added; the report does not put a quantity on what the overflow could have added past that, and neither did any secondary account read for this story. The age of the bug is reported three ways. CoinDesk and TechFlow call it decade-old and trace it to 2015, one KuCoin wire item says 10 years and another says 11, which is what 2015 to 2026 actually comes to. They do not reconcile, and the disclosure report itself frames the flaw by affected version instead of by year. What remains is an upgrade notice: operators below 3.4.1 are out of sync and cannot vote.