Decade-old xrpld overflow bug could have minted XRP past its 100-billion cap
XRP Ledger developers disclosed an integer-overflow bug in xrpld 3.4.0 and earlier that could have minted XRP beyond its 100-billion supply cap. The patch skipped the validator vote, so the cap's defence rested on one team and on node operators upgrading fast.
The Investor · Invest desk

Timeline: on September 22, 2026, researcher Cayden Liao reported the bug through the XRPL Bug Bounty program; on September 25, 2026, emergency release xrpld 3.4.1 went out; on October 9, 2026, the flaw in xrpld 3.4.0 and earlier was made public.
| Date | Event | Claim |
|---|---|---|
| September 22, 2026 | Cayden Liao reports the bug via the XRPL Bug Bounty program | 7 |
| September 25, 2026 | Emergency release xrpld 3.4.1 goes out | 9 |
| October 9, 2026 | Flaw in xrpld 3.4.0 and earlier made public | 2 |
What happened
- The payment engine summed XRP amounts in a 64-bit integer when one payment drew on several offers, and any total past the integer's limit wrapped around to a far smaller number.
- The exploit needed crafted offers from hundreds of accounts and cost only a few hundred XRP in reserves and fees, most of it recoverable, according to the disclosure.
- Researcher Cayden Liao reported the flaw on September 22, 2026, through the XRPL Bug Bounty program, and RippleX reproduced the attack on a standalone server.
- The fix went out as emergency release xrpld 3.4.1 on September 25, and the flaw was made public on October 9.
- Investigators found no evidence that the bug was ever used on a public network.
Why it matters
- What it limits constraint For holders who value XRP on its 100-billion limit, a balanced ledger did not prove a capped supply, so the cap depends on the payment engine's code being correct.
- What it sets up precedent Validators now have a case of a ledger rule fix deployed without their vote, and can expect the core team to do it again when it judges a flaw too dangerous to wait on governance.
- Who's exposed exposure Any node operator still on xrpld 3.4.0 or earlier now runs code whose supply-breaking flaw is publicly documented, while a patch has been available since September 25.
Next story · Invest · 4d ago
Ripple's $250,000 bounty equals 0.0003% of the XRP value Veria says the bug put at riskConfirmed3 publishers
Even rounded up to 1,000 XRP, the attacker's few hundred XRP in reserves and fees comes to less than one hundred-millionth of the 100-billion cap [14]. According to the disclosure as reported by Crypto Briefing, a single transaction may have minted more XRP than the token's entire supply [18]. RippleX also confirmed that the excess could be spent in follow-up transactions [8].
The ledger's checks did not catch it either. The overflowed total came out smaller than the real one, so the books looked balanced while supply grew. When the inflated balances were spread across many accounts, the guardrails did not flag the discrepancy [5]. In our view, that means the cap was enforced by the same sum the bug corrupted.
The flaw is thought to date from the payment engine's construction around 2015 [12], about 11 years [15] before Cayden Liao reported it through the XRPL Bug Bounty program [7]. After the report the response was fast: three days to an emergency release [16], then 14 more days before the public disclosure [17]. Rule changes on the ledger normally go through a validator vote before taking effect, and this one was deployed immediately [10].
There are two readings of that sequence. One is that the process worked. The team reports no lost funds, no compromised keys and no consensus problems [11], and a bounty report became a shipped fix in three days [16]. The other is Crypto Briefing's: an emergency patch that skips normal procedure asks users to rely heavily on the core development team, and the network's security hinged on how fast validators and node operators upgraded [19].
We think both are right, and the second matters more to anyone who values XRP on a fixed supply. The cap held because a small team, or rather a small team plus whichever node operators upgraded in time, acted before any known use of the flaw [3][19]. The ledger's own accounting played no part in that [5]. The release itself shows where the effort went: no time on a governance vote [10], and two weeks between the quiet patch and the public disclosure [2][17].
We would be wrong if a reconciliation outside the payment engine, one that counts total XRP independently of the books the engine keeps, would have caught a mint like this anyway. The coverage does not describe one.
What to watch
- Whether anyone publishes an independent reconciliation of total XRP supply confirming the cap held through the roughly 11 years the flaw sat in the code.
- Whether the next emergency rule fix also bypasses the amendment vote, or validators move to formalise a procedure for such releases.
- How many nodes are still running xrpld 3.4.0 or earlier now that the flaw is public.
Information, not investment advice. This story is general information about companies and markets, drawn from cited reporting. It is not a recommendation to buy, sell or hold any security; check the cited sources before acting.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence70
- Adoption80
- Hype gap+25
- Incentives55
- Confidence74
Perspective Coverage
8 publishers- Builder
- Builder 36%
- Operator
- Operator 29%
- Investor
- Investor 35%
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The XRP Ledger disclosed a critical bug that could have let an attacker create XRP beyond the network's hard limit of 100 billion tokens.
- [2]
The flaw was in xrpld versions 3.4.0 and earlier; it was patched quietly in September and made public on October 9, 2026.
- [3]
Investigators found no evidence the bug was ever used on a public network.
- [4]
The software used a 64-bit integer to add up XRP amounts when a single payment pulled from multiple order-book offers; if the running total grew past the largest number the integer could hold, it wrapped around to a number far smaller than reality.
- [5]
The ledger's books would look balanced while the actual supply grew; existing safety checks did not catch it, and when inflated balances were scattered across many accounts the guardrails failed to flag the discrepancy.
- [6]
The exploit required specially crafted offers from hundreds of accounts, costing only a few hundred XRP in reserves and fees, most of which would have been recoverable.
- [7]
The vulnerability was reported on September 22, 2026, by researcher Cayden Liao through the XRPL Bug Bounty program, and RippleX, Ripple's developer arm, confirmed the issue.
- [8]
RippleX reproduced the attack on a standalone server and confirmed that the excess XRP could be spent in follow-up transactions.
- [9]
An emergency release, xrpld 3.4.1, went out on September 25, 2026.
- [10]
The fix skipped the usual amendment process; changes to XRP Ledger rules normally go through a validator voting procedure before taking effect, but this one was deployed immediately.
- [11]
The team reported no loss of funds, no compromised keys and no consensus problems tied to the bug.
- [12]
The flaw is thought to have existed since the payment engine was first built, around 2015.
- [13]
Node operators still running xrpld 3.4.0 or earlier are running software with a publicly documented supply-breaking flaw; the patched version 3.4.1 has been available since September 25.
- [14]
The attack outlay of a few hundred XRP was less than one hundred-millionth of the 100-billion XRP cap.
- [15]
The flaw sat in the code for about 11 years before it was reported.
- [16]
The emergency release shipped three days after the bug was reported.
- [17]
Public disclosure came 14 days after the patched release.
- [18]
The amount of XRP that could have been minted in a single transaction may have exceeded the token's entire total supply.
- [19]
Emergency patches that skip normal procedures put a lot of trust in the core development team, and the network's security depended on validators and node operators upgrading quickly.
Sources
8 independent publishers whose own reporting we read for this story.
- coindesk.comWhy a bug that could have threatened XRP's 100 billion supply cap stayed hidden for years
1 article · October 12, 2026
- cointelegraph.comXRP Ledger defends emergency patch for unlimited XRP bug
1 article · October 11, 2026
- crypto.newsXRP Ledger confirms 100B supply is safe after major security flaw
1 article · October 11, 2026
- cryptobriefing.comXRP Ledger discloses overflow bug that could have minted XRP beyond its supply cap
1 article · October 9, 2026
- cryptoslate.comAI discovers XRP Ledger flaw that could mint 18 trillion tokens and put $94 billion market at risk
1 article · October 11, 2026
- decrypt.coXRP Ledger’s Payment Engine Had a Counterfeiting Bug Hiding Since 2015
1 article · October 12, 2026
- gizmodo.comXRP Bug Could Have Let Hackers Print Billions in Crypto Out of Thin Air
1 article · October 11, 2026
- news.bitcoin.comA Decade-Old XRP Ledger Bug Could Have Minted XRP Out of Thin Air
2 articles · October 11, 2026
Topics and entities
Topics
- AI Vulnerability Discovery and Exploitation
- Blockchain security vulnerabilities
- Bug Bounty Programs
- Integer overflow and underflow bugs
- On-chain governance and parameter voting