Skip to content

Invest Widely confirmed8 publishers 2 min read Published Updated

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

Send a correction

Illustration accompanying Decade-old xrpld overflow bug could have minted XRP past its 100-billion cap
Generated illustration
XRP cap bug fixed Sept 25, made public only Oct 9 Key dates in the reporting, fix and public disclosure of the xrpld overflow flaw, 2026.

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.

XRP cap bug fixed Sept 25, made public only Oct 9
DateEventClaim
September 22, 2026Cayden Liao reports the bug via the XRPL Bug Bounty program7
September 25, 2026Emergency release xrpld 3.4.1 goes out9
October 9, 2026Flaw in xrpld 3.4.0 and earlier made public2

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.

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%
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [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.

    Reported SupportedView cited source
  2. [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.

    Reported SupportedView cited source
  3. [3]

    Investigators found no evidence the bug was ever used on a public network.

    Reported Supported Source: According to the disclosure, as reported by Crypto BriefingView cited source
  4. [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.

    Reported SupportedView cited source
  5. [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.

    Reported SupportedView cited source
  6. [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.

    Reported Supported Source: According to the disclosure, as reported by Crypto BriefingView cited source
  7. [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.

    Reported SupportedView cited source
  8. [8]

    RippleX reproduced the attack on a standalone server and confirmed that the excess XRP could be spent in follow-up transactions.

    Reported SupportedView cited source
  9. [9]

    An emergency release, xrpld 3.4.1, went out on September 25, 2026.

    Reported SupportedView cited source
  10. [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.

    Reported SupportedView cited source
  11. [11]

    The team reported no loss of funds, no compromised keys and no consensus problems tied to the bug.

    Reported SupportedView cited source
  12. [12]

    The flaw is thought to have existed since the payment engine was first built, around 2015.

    Reported SupportedView cited source
  13. [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.

    Reported Supported Source: Crypto BriefingView cited source
  14. [14]

    The attack outlay of a few hundred XRP was less than one hundred-millionth of the 100-billion XRP cap.

    Derived Supported
  15. [15]

    The flaw sat in the code for about 11 years before it was reported.

    Derived Supported
  16. [16]

    The emergency release shipped three days after the bug was reported.

    Derived Supported
  17. [17]

    Public disclosure came 14 days after the patched release.

    Derived Supported
  18. [18]

    The amount of XRP that could have been minted in a single transaction may have exceeded the token's entire total supply.

    Reported Contested Source: Crypto Briefing, citing the disclosureView cited source
  19. [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.

    Reported Contested Source: Crypto Briefing analysisView cited source

Sources

8 independent publishers whose own reporting we read for this story.

  1. coindesk.com

    1 article · October 12, 2026

    Why a bug that could have threatened XRP's 100 billion supply cap stayed hidden for years
  2. cointelegraph.com

    1 article · October 11, 2026

    XRP Ledger defends emergency patch for unlimited XRP bug
  3. crypto.news

    1 article · October 11, 2026

    XRP Ledger confirms 100B supply is safe after major security flaw
  4. cryptobriefing.com

    1 article · October 9, 2026

    XRP Ledger discloses overflow bug that could have minted XRP beyond its supply cap
  5. cryptoslate.com

    1 article · October 11, 2026

    AI discovers XRP Ledger flaw that could mint 18 trillion tokens and put $94 billion market at risk
  6. decrypt.co

    1 article · October 12, 2026

    XRP Ledger’s Payment Engine Had a Counterfeiting Bug Hiding Since 2015
  7. gizmodo.com

    1 article · October 11, 2026

    XRP Bug Could Have Let Hackers Print Billions in Crypto Out of Thin Air
  8. news.bitcoin.com

    2 articles · October 11, 2026

    A Decade-Old XRP Ledger Bug Could Have Minted XRP Out of Thin Air

Topics and entities

Topics