Did a bug in the XRP Ledger let anyone create XRP from nothing, and was the 100 billion supply changed?

The full answer

The XRP Ledger developer blog published a vulnerability disclosure report on October 9, 2026, covering two bugs fixed in xrpld 3.4.1 [1]. One of them, a payment engine XRP overflow, could be exploited to create XRP from nothing, according to that report [1]. The fix shipped in xrpld 3.4.1, which XRPL.org released on September 25, 2026 as an emergency release for security-sensitive issues [2].

Whether any XRP was minted through it is not publicly established as of October 12, 2026.

How could the bug create XRP?

The report says a single payment that consumed many offers from the order book could trigger the overflow [1]. XRP balances are stored as integers with a fixed maximum. When a sum passed that maximum, it did not fail with an error. It wrapped around to a small number instead [1].

The engine then paid each offer owner their full amount but charged the buyer only the wrapped-around total, the report says. The difference was new XRP that should never have existed [1]. An attacker using specially crafted offers and one payment could mint XRP in violation of the ledger’s intended rules and spend it like any other XRP [1].

The ledger has a built-in safety check, called an invariant, that confirms no transaction creates XRP. According to the October 9 report, that check summed balance changes the same way, so it wrapped around identically and detected nothing [1].

Who found it, and how long was it there?

A researcher reported the flaw through the XRPL Bug Bounty program on September 22, 2026, the report says [1]. Affected versions were xrpld 3.4.0 and earlier. The report adds that investigation suggests the bug had been present since the current payment engine was written in 2015, and that it surfaced only now because of that bug bounty report [1].

The same report covers a second bug, in the Batch feature, reported September 18, 2026. That one affected xrpld 3.3.0 and 3.4.0 through the BatchV1_1 amendment, which was not activated on Mainnet when it was found [1].

Was the 100 billion XRP supply changed?

XRPL.org’s documentation says that at the time of XRP’s creation there were 100 billion XRP [3]. Its introduction to XRP says there were 100 billion XRP at the time of creation [4]. The overflow was a path around that rule in the server code.

As of October 12, 2026, no public source establishes whether anyone used the overflow on Mainnet before the fix. Supply trackers still count against the 100 billion figure: in its September 26, 2026 weekly supply report, XRP Insights said Ripple’s on-ledger escrow held 31.98 billion XRP, 32.0% of the fixed 100 billion supply [5]. A tracker using that total does not by itself show that no XRP was minted, because the ledger’s own check could not have flagged it. For how XRP is removed through fees and whether new units can appear, see whether the XRP Ledger burns XRP and can create new XRP.

How was it fixed?

Under the fix, if a total would overflow, that part of the payment fails cleanly and the transaction ends with a normal “path dry” or “partial payment” result, the report says [1]. The no-new-XRP check now uses a wider counter that cannot wrap around. Other places that add up balances across many accounts were hardened as a precaution [1]. XRPL.org’s 3.4.1 changelog lists “Assorted integer-arithmetic hardening in the payment engine and ledger helpers,” and credits RippleX Engineering and the XRP Ledger Foundation [2].

This fix did not go through the usual vote. Ledger rule changes normally ship switched off and turn on only after more than 80 percent of trusted validators support them for two weeks, as the report explains [1]. The overflow fix instead applies immediately upon upgrade [1]. That vote process is described in how XRP Ledger amendments are approved.

Do server operators need to upgrade to xrpld 3.4.1?

Yes. XRPL.org’s September 25, 2026 release notes told anyone running an XRP Ledger server to upgrade to 3.4.1 as soon as possible [2]. They warned that once fixBatchV1_2 became enabled, servers not updated would become amendment blocked and unable to stay in sync [2].

The October 9 report says fixBatchV1_2 became enabled on Mainnet on October 9, 2026, that all operators must run 3.4.1 or newer to maintain sync, and that older servers are now amendment blocked [1]. The background to the emergency release is covered in why the September 2026 emergency update was released.

What do critics point to?

The strongest critique comes from the report itself. The safety check meant to catch new XRP failed in the same way as the code it guarded, and the flaw may have sat in the payment engine since 2015 [1]. The Batch fix had a similar history: the report’s timeline says a fix was confirmed incomplete on September 18, 2026 [1].

Transparency was delayed too. When 3.4.1 shipped, XRPL.org said on September 25, 2026 that the source code for the release had not been published yet because of the security-sensitive nature of the fix, and that it would be published along with a retrospective on a future date [2]. The October 9 report says the source code has now been published, and that every security finding marked as fixed will be re-tested against release candidates before it is closed [1]. Earlier faults on the network are listed in the XRP Ledger’s outages and incidents. For the case that the supply cap holds, see how many XRP exist and whether Ripple can create more.