Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
An XRP Ledger payment-engine bug could have created XRP beyond the intended 100 billion supply limit, but the vulnerability disclosure says there is no evidence it was exploited on a public network. The flaw was an unchecked integer overflow when a payment summed XRP amounts across many offers: the total could wrap to a small number, letting offer owners receive more XRP than the buyer was charged. The fix shipped in xrpld 3.4.1 on September 25, 2026.
Could the bug really have broken XRP’s 100 billion supply cap?
Potentially, yes. The vulnerability could have made the ledger credit more XRP to offer owners than it collected from the buyer, creating spendable XRP that should not exist. That was a software accounting flaw in payment processing—not a change to the published supply arrangement or to escrow.
The XRP Ledger Foundation’s 2026 disclosure describes a possible minting path, not a confirmed increase in Mainnet supply. It says investigators found no evidence of exploitation on a public network. That supports “could have created XRP,” not a claim that the cap was actually exceeded.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How did the overflow create XRP?
A payment can consume offers from an order book. Each offer’s amount could be valid on its own, but the payment engine added XRP amounts across offers using unchecked 64-bit integer arithmetic. If the combined mathematical total exceeded the integer’s maximum, the recorded sum could wrap around to a small value.
#1 Best Overall
The engine could then pay each offer owner the full amount while charging the buyer only the wrapped total. The gap between what was credited and what was collected would be newly created XRP.
What an attacker would have needed to do
- Create hundreds of accounts and offers selling tiny amounts of another token for enormous amounts of XRP.
- Arrange the offers so their combined XRP amounts crossed the 64-bit limit when added together.
- Make a single payment that consumed those offers in the same transaction.
The offers could all belong to the attacker. Because their prices were so poor, they would sit below real liquidity, making it unlikely that ordinary payments would reach them. According to the disclosure, routine trading could not trigger the issue accidentally; exploitation required a deliberately constructed set of offers and payment.
Why did the flaw stay hidden for years?
The Foundation’s investigation suggests the bug had been present since the current payment engine was written in 2015. Normal payments and trades did not add together XRP amounts remotely close to the 64-bit limit, so they did not reach the faulty calculation. The unusual bundle of offers needed to force that path was the key difference.
The flaw also survived two checks because neither independently caught the same pattern of distributed, overflowing balances:
- The “no XRP created” invariant: This check used the same kind of 64-bit sum as the payment engine. It wrapped in the same way, so the apparent net change could look like an ordinary transaction fee rather than newly created XRP.
- The per-account balance check: It would only fail if one account held more XRP than the total supply. An attacker could spread the created XRP among hundreds of accounts, keeping every individual balance below that threshold.
Why didn’t the ledger’s safeguards catch it?
The design goal of an invariant is to detect transaction results that violate system properties before those results are committed. The XRPL Community Blog’s 2017 explanation of the EnforceInvariants amendment describes those automatic checks as a way to help catch incorrect transaction changes and identify logic flaws. In this case, however, the “no XRP created” check reused arithmetic that failed in tandem with the payment engine.
This illustrates an important limitation of a safeguard: if the main calculation and the check depend on the same narrow arithmetic, they can share the same failure mode. The per-account check looked at a different condition, but it did not compare the total XRP across all the attacker’s accounts.
How was the bug discovered and fixed?
The vulnerability was reported through the XRPL Bug Bounty program on September 22, 2026. RippleX engineers reproduced the mint on a local standalone server and in unit tests, then confirmed that the created XRP could be spent in a follow-up payment. The disclosure says the team raised the severity from the original report’s Major rating to critical. It acknowledges Cayden Liao and Veria AI for the report and proof of concept.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →The fix shipped in xrpld 3.4.1 on September 25, 2026. It addressed both the faulty sums and the check that had failed alongside them:
- The payment engine now checks for overflow while summing amounts across offers and combining payment paths. If a sum would overflow, the affected path fails cleanly instead of minting XRP.
- The “no XRP created” safety check now uses a wider counter that does not wrap in the same way.
- The disclosure also describes precautionary hardening of other code that sums balances.
The fix took effect as individual servers upgraded rather than waiting for the usual amendment activation process. The disclosure reports that more than 80 percent of default UNL validators were running version 3.4.1 or later on release day, before the fix’s source code was published. That figure is the Foundation report’s account of the upgrade response, not an independently verified validator census.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What the escrow figures do—and do not—tell you
Ripple said in 2017 that 55 billion XRP, or 55% of the total possible supply, had been placed in escrow. Those figures were presented as background for supply predictability and scheduled releases. Escrow was not the mechanism that detected this overflow or the fix that prevented it; the bug concerned how payment software calculated and recorded amounts across offers.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
