A bug sitting quietly in XRP Ledger code since 2015 could have let an attacker create potentially large amounts of XRP beyond the intended supply, violating a foundational monetary rule. No one exploited it on a public network, but the fix required something arguably as notable: what the XRP Ledger Foundation’s own disclosure describes as the first deliberate bypass of the amendment system for a transaction-processing change since that system launched.
The incident carries implications beyond XRP holders. A blockchain’s supply cap is only as solid as the software enforcing it.
How the Bug Worked
An arithmetic ceiling, a near-zero charge, and newly created XRP.
The payment engine uses 64-bit arithmetic to calculate totals when a single payment consumes many order-book offers. When those totals exceeded the maximum value a 64-bit integer can hold, the number didn’t error out. Instead, it wrapped around to a tiny figure, like an odometer rolling past 999,999 back to zero.
That wraparound meant a buyer got charged almost nothing while every offer seller received full credit. The attacker could pocket the difference as newly created, spendable XRP.
According to the XRP Ledger Foundation’s disclosure, pulling this off required:
- Hundreds of specially priced offers placed on the ledger’s built-in order book
- A single payment transaction constructed to consume all of them
- Roughly a few hundred dollars’ worth of XRP in reserves and transaction fees
- No compromised private keys or validator access, only valid-looking ledger activity
The vulnerability appears to date to 2015, when the current payment engine was written.
An Emergency Patch, and a Governance First
Three days from report to release, and one longstanding rule set aside.
Researcher Cayden Liao, associated with Veria AI and Veria Labs, reported the issue on September 22, 2026, through the XRPL bug bounty program. RippleX reproduced it on a private test server and classified it as critical. Version 3.4.1 shipped three days later, on September 25, described publicly as “assorted integer-arithmetic hardening” with a strong recommendation for operators to upgrade immediately.
The patch added overflow checks that cause the affected calculation to fail cleanly rather than wrap around, rejecting the vulnerable condition instead of creating new XRP. Notably, the overflow fix applied immediately upon installing 3.4.1, while a second fix in the same release, addressing a potential network halt in the not-yet-activated Batch feature, was handled through the standard amendment process.
What made the response unusual was the governance decision behind it. Protocol changes on the XRP Ledger ordinarily require supermajority validator support sustained over two weeks before taking effect, according to the network’s amendment system. Developers skipped that process for the overflow fix, making it live on any server that installed 3.4.1.
Developers reasoned that a public validator vote would have advertised the vulnerability before most operators could patch. They judged a temporary network split, or even a halt, preferable to processing an inflation transaction and producing an incorrect ledger state. More than 80% of validators on commonly used trusted lists upgraded on release day, according to CoinTelegraph.
Both readings of that outcome are defensible. Rapid coordination across most of the validator set demonstrates effective incident response. It also reflects how much influence a relatively small group of validators and list publishers holds over the network when a genuine emergency demands fast action.
Not the First Time Fixed Supply Turned Out to Be a Software Problem
Cryptocurrency history shows that supply caps depend on implementation, not just protocol rules.
Bitcoin’s 2010 overflow event briefly created more than 184 billion BTC in a single transaction before developers patched and reorganized the chain. Zcash separately disclosed a serious counterfeiting vulnerability. Both cases underscore what the XRP Ledger incident reinforces: a fixed supply is ultimately a software guarantee, not a mathematical certainty. Protecting password vaults and other critical user data faces similar risks when exploits remain hidden in software.
What This Actually Means for You
Ordinary holders faced no confirmed loss, but operators and validators had to move fast.
No evidence has been reported that the flaw was exploited on a public network or that fraudulent XRP entered public circulation. Ordinary XRP holders who used the canonical ledger faced no confirmed loss of funds. The parties who needed to act were validators, node operators, exchanges, and custodians, and those running trusted infrastructure largely did.
The bug apparently existed for roughly eleven years. One researcher and a bug bounty program surfaced it, and the released fix was designed to reject the vulnerable overflow condition. Cases like files exposed through long-dormant software flaws show how common it is for such vulnerabilities to go undetected for years. What remains an open question is whether emergency response in a system that positions itself as decentralized can always move this fast, and who exactly gets to make that call.
