A Decade-Old Bug Could Have Minted Billions of Extra XRP

iEXExchanger
A Decade-Old Bug Could Have Minted Billions of Extra XRP

XRP Ledger developers rushed out a patch for a bug that sat in the code for almost a decade and could have let someone mint tokens past the network's hard cap of 100 billion. No sign it was ever exploited.

XRP has always been sold on one simple promise: a hard, fixed supply of 100 billion coins, pre-mined in a single block back in 2012, no mining and no gradual inflation. For over a decade that number anchored the pitch against Bitcoin's slow-drip issuance. It turns out the cap had been resting on arithmetic nobody had seriously tried to break.

The flaw lived in the payment engine's offer-settlement code since 2015. When a single payment swept up a large batch of orders from XRP Ledger's built-in exchange, the amount owed was computed as a 64-bit integer. Stack enough mispriced offers together and that number could overflow and wrap around to something far smaller — sellers still got paid in full, while the buyer was charged next to nothing. The gap between what was owed and what was actually paid was, in effect, XRP that had never existed.

Pulling it off wouldn't have been expensive. RippleX estimated an attacker would need only a few hundred XRP for account reserves, spread across a cluster of accounts offering tiny amounts at absurd prices, plus ordinary transaction fees.

It wasn't an internal audit that caught it — researcher Cayden Liao, working with Veria AI, reported it through the XRPL Bug Bounty program on September 22. What happened next moved unusually fast for a decentralized network: RippleX reproduced and rated it critical within a day, and the fix shipped as xrpld 3.4.1 on September 25 — skipping the network's normal amendment vote, which usually needs over 80% of trusted validators on board for two straight weeks. For a chain that markets itself on distributed governance, that was a deliberate exception: closing the exposure window took priority over waiting out the usual process.

The bug only became public on October 9, two weeks after it was actually fixed. XRPL Operations said it found no evidence the flaw was ever exploited on a live network — though that's hard to verify from the outside, since a successful attack would simply look like an oversized, perfectly ordinary payment.

None of this is really about one close call. It's a reminder that even a mature, decade-plus-old blockchain, sold on the idea of a locked and predictable supply, can still carry arithmetic that nobody had genuinely tried to break until a bounty hunter did. A fixed cap is only as solid as the code nobody has stress-tested yet.

Questions and answers

Frequently asked questions about this article

What exactly was the XRP Ledger vulnerability?

A flaw in the payment engine let the 64-bit integer used to calculate a trade's total overflow under the right conditions, so the seller got paid in full while the buyer paid almost nothing — the gap became new, unaccounted-for XRP.

Who found the bug and how?

Independent researcher Cayden Liao, working with the Veria AI team, found it and reported it on September 22, 2026 through the XRPL Bug Bounty program, which pays outside researchers for finding critical flaws.

Did anyone actually lose money or get affected?

XRPL Operations said it found no evidence the bug was exploited on the public network. That's hard to verify independently, though, since a successful attack would simply look like a large, otherwise ordinary payment.

Why was the patch released without the usual validator vote?

A normal protocol change on XRP Ledger needs over 80% of trusted validators on board for two straight weeks. Given how critical the bug was, developers pushed out xrpld 3.4.1 as an emergency release to close the exposure window as fast as possible, rather than waiting out the full voting process.