A Decade-Old Overflow Could Mint XRP Past 100 Billion. The Invariant Built to Catch It Overflowed the Same Way

What Happened

RippleX, Ripple's developer arm, published a vulnerability disclosure report on the XRP Ledger community blog on Friday, October 9, covering 2 bugs fixed in the xrpld 3.4.1 release. On September 22, researcher Cayden Liao and Veria AI reported through the XRPL bug bounty program that an integer overflow in the payment engine could create XRP from nothing.

The submission rated the finding Major. RippleX reproduced it the same day on a standalone server, confirmed the minted XRP could be spent, and raised it to critical. The fix was merged on September 23 and shipped on September 25 under a changelog line reading 'Assorted integer-arithmetic hardening in the payment engine and ledger helpers.'

The source code was withheld until the report came out.

When a payment crosses the ledger's built-in order book, the engine takes every offer at the best price in 1 pass and adds up what the buyer owes, using plain 64-bit integer addition. Each offer was valid on its own, but a few hundred offers, each selling a tiny amount of some token for an enormous amount of XRP, add up to more than a 64-bit integer holds.

The total wrapped around to a tiny value. The engine credited each offer owner in full and charged the buyer only the wrapped total plus the fee; the difference was XRP that had never existed. Per the report, the attacker needed a few hundred XRP in refundable reserves, every account involved could belong to 1 person, and the flaw dates to the payment engine written in 2015.

RippleX says it found no evidence the bug was exploited on any public network.

A supply cap is a claim that every node re-checks on every block. For 10 years the XRP Ledger's checker used the same broken sum as the code it watched, and the only reason anyone knows is that someone outside finally ran the numbers.

2 Safety Checks Looked at the Mint and Saw a Fee

The XRP Ledger has had invariant checking since July 2017, when the EnforceInvariants amendment activated with rippled 0.70.0. Nik Bougalis, writing for Ripple at the time, said the new checks, 'which we believe will never trigger,' would protect the ledger 'from bugs yet to be discovered, or even created.'

One of them, XRPNotCreated, enforces the rule that a transaction may destroy XRP only up to its fee and may never create any. It exists to catch what this bug did.

It did not trigger, and the disclosure explains why in 1 sentence: the invariant summed the net change across the transaction with the same kind of 64-bit counter, so it wrapped around identically and reported a net change equal to the fee, which is what every normal payment looks like.

The invariant was added 2 years after the engine and built on the same unchecked arithmetic. A second check, which fails any transaction leaving 1 account with more than the total supply of about 100 billion XRP, was sidestepped by spreading the proceeds across hundreds of accounts.

The lesson is not that invariants are useless; it is that a safety check is only as independent as its arithmetic, and one that shares a bug with the code it guards produces confidence rather than safety. The fix widens the invariant's counter so it cannot wrap and makes the summing step fail 'path dry' instead of minting.

The Fix Skipped the Vote Because the Vote Would Have Published the Exploit

Changes to how the XRP Ledger processes transactions normally ship as amendments: the code ships but stays off until more than 80 percent of trusted validators have supported it for 2 weeks, then every server switches at the same ledger. This fix took effect on each server the moment that server upgraded, and the report states this is the first time a transaction-processing change has deliberately shipped that way since the amendment system was introduced more than 10 years ago.

The reasoning: xrpld is open source, so a release containing the fix shows where the bug is, and on the amendment timeline the exploit would have been public and live for weeks. RippleX writes that a network halt during the upgrade window 'would actually be preferable' to a ledger with exploit transactions in it.

The obvious objection is that this is the centralization critics describe: the XRPL Foundation, RippleX, and the operators of the default Unique Node List agreed among themselves, upgraded within a day, and ran a consensus-relevant change with no vote and no published source for 2 weeks.

The report does not dispute the facts; it calls the bar 'very high' and says the case does not change how the ledger makes protocol changes. It cuts both ways. The concentration that put more than 80 percent of the UNL on 3.4.1 on release day is what made the no-amendment path survivable; a more distributed validator set would have faced a longer exposed window.

Bitcoin's own history shows that quiet coordination among a small group is how its inflation bugs were handled too. What differs is what each network lets an outsider verify afterward.

Bitcoin Has Been Here Twice

On August 15, 2010, block 74,638 contained a transaction that created roughly 184 billion BTC across 2 outputs, because the validation code did not check whether the outputs' sum overflowed. A patched client appeared within about 5 hours, adding a rule that rejects overflowing outputs and any output above 21 million, and the corrected chain overtook the bad one at block 74,691.

That is the overflow half of the XRP story, except that Bitcoin's was exploited and 53 blocks had to be abandoned.

The second half came in September 2018. CVE-2018-17144 reached developers as a denial-of-service report on September 17; within hours they realized the same root cause, a duplicate-input check removed as an optimization in 0.14.0 and an assertion rewritten in 0.15.0, would let a miner spend the same coins twice and inflate the supply.

Bitcoin Core shipped 0.16.3 on September 18 describing only the denial-of-service fix and published the inflation detail on September 20. It was never exploited on mainnet, though someone did exploit it on testnet after disclosure. The 'integer-arithmetic hardening' line in xrpld 3.

4.1's notes is the same move: ship under a modest description, disclose when the network is protected. Both projects judged that a quiet 2 weeks beat an advertised exploit, and both were right on the evidence; neither episode is a reason to assume the next bug will be found by defenders first.

What This Means for You

The number in a whitepaper does not enforce a supply cap. The software running on nodes does, 1 transaction at a time, and for about a decade the XRP Ledger's software would have accepted a mint and its safety check would have signed off. For a Bitcoin holder, your supply guarantee is exactly as strong as the node you validate with.

If you hold private keys in self-custody but trust an exchange's or a wallet vendor's node to tell you what the chain says, you have outsourced the one check that matters here. Running your own node, keeping it on a supported release, and reading the notes when a version ships ahead of schedule is the whole action item.

For anyone holding XRP on an exchange there are 2 layers of exposure: the familiar custodial risk, and the fact that minted coins 'could be moved, traded, or sent to exchanges,' in the report's words, clearing the checks an exchange's node would run. Self-custody does not protect you from an inflation bug either, but it ends your exposure at the protocol rather than at a counterparty whose balance sheet absorbed the fake coins.

A hardware wallet and a multi-sig quorum are unchanged by this disclosure; what they protect is key control, not the arithmetic of the chain they sign for.

2 habits follow. Read vague security changelogs as what they usually are: 'Assorted integer-arithmetic hardening' in an emergency release with unpublished source means something serious was fixed, as Bitcoin Core's 2018 'denial-of-service' wording did, so upgrade on those words rather than on the retrospective.

And treat 'no evidence of exploitation' as the ceiling of what a team can say in the first weeks; RippleX's report does not describe how it reached that conclusion, and a reconciliation of ledger balances against issued supply would be the stronger statement. A Bitcoin node operator can run that reconciliation with 1 RPC call (gettxoutsetinfo), and that ability, more than any audit, is what self-verification means.

What to Watch

The xrpld 3.4.1 source is now published, so independent reviewers can confirm from the diff that the invariant's new counter cannot wrap. RippleX says every finding marked fixed will now be re-tested against the release candidate before it is closed. The finder credit is the wider signal: this is the second critical XRPL bug this year credited jointly to a researcher and a firm with 'AI' in its name, after a Cantina AI tool found the Batch signature flaw in February.

The report does not say how this one was found; what it does say is that a 10-year-old flaw in the ledger's payment path was caught by an outside bounty submission, not by the invariant designed for it. Bitcoin Core 32.0, whose final tag was scheduled for October 10 and had not shipped as of this writing, carries a fix for a command-injection flaw in the walletnotify option present since version 24.

0.

Tracked entities this report names, with total coverage across the archive. Follow one into the Actor Network to see every report it appears in.