A Decade-Old Bug That Could Have Minted Unlimited XRP: Is the 100 Billion Cap Safe Now?
A flaw hiding in the XRP Ledger since 2015 could have let an attacker conjure spendable XRP out of nothing, bypassing the 100 billion coin cap entirely. What it took to trigger it, and whether any extra coins were ever…
This post may contain links from our sponsors and affiliates, and Flywheel Publishing may receive compensation for actions taken through them.
A vulnerability in the XRP Ledger’s payment processing system could have allowed an attacker to create new, spendable XRP (CRYPTO: XRP) out of thin air, potentially violating the XRP supply cap of 100 billion coins. This flaw, present since 2015, went unnoticed for nearly ten years, according to a vulnerability disclosure report published by RippleX, the development arm of Ripple, on October 9, 2026.
Fortunately, the report reassures users that no evidence shows anyone exploited this vulnerability on the public network. Researchers Cayden Liao and Veria AI reported the bug on September 22 through the XRP Ledger’s bug bounty program, and RippleX released the fix just three days later, on September 25—two weeks before the information was made public.
As of October 10, XRP trades around $1.40, reflecting the same range it was in shortly after the 2024 election. On the day the report was released, XRP opened at $1.38 and closed at $1.39, suggesting traders reacted minimally. However, if a long-standing bug could have created new XRP, can holders trust the supply is accurate?
How an Integer Overflow Bug Could Have Created XRP From Thin Air

Computers manage data using fixed-size “boxes” for each number. When a total exceeds the box’s limit, it wraps around to the beginning, much like an old car’s odometer rolling from 999,999 back to 000,000. This phenomenon, known as an integer overflow, lets the software keep running as if the total were correct.
In the case of the XRP Ledger, the overflow occurred when the engine added up various offers fulfilled by a single transaction. If the total amount surpassed the limit, it rolled over to a smaller number. While the system still paid each offer owner the full amount, it charged the buyer only the rolled-over total, effectively creating new XRP that could be spent without any oversight.
The ledger includes a safety check designed to prevent creating new XRP. However, this check calculated balances the same way as transaction processing, so it also overflowed and missed the new coins. Furthermore, a separate check only triggers if one account exceeds the total supply, allowing an attacker to distribute the minting across multiple accounts and evade detection.
This bug remained undiscovered for years because typical transactions never approached the overflow threshold. To trigger it, an attacker would need to create hundreds of offers at unrealistic prices and execute a payment designed to fill them all at once. Even so, the attack would require only a few hundred XRP in refundable reserves and fees. The researchers classified the flaw as Major, while RippleX elevated its rating to Critical after confirming that the bug could generate spendable XRP.
Why RippleX Fixed the XRP Bug Without a Validator Vote

RippleX took an unusual approach in addressing the bug. Normally, changes to how the XRP Ledger processes transactions must go through a lengthy amendment process in which validators—independent servers that verify transactions—vote before implementing any change. In this case, RippleX bypassed the usual vote for the first time in over a decade.
The decision stemmed from practical concerns: the software is open source, so publicly disclosing the fix during the normal process could have revealed the flaw to potential attackers. Instead of following the traditional route, RippleX applied the patch immediately and published the updated code afterward.
According to RippleX, over 80% of the default trusted validators—servers that most XRP Ledger nodes rely on—applied the patch on the day of its release. This self-reported statistic highlights a unified group’s ability to act swiftly, raising valid questions about how decentralized the ledger truly is.
The report also addressed a smaller bug in the Batch feature that could cause discrepancies between servers running different software versions and stall ledger validation. Denis Angell of the XRPL Foundation reported this bug on September 18, but because Batch was never active on the main network, no funds were at risk. The fix was activated on October 9.
RippleX Found No Evidence of Extra XRP Being Minted

Regarding supply concerns, the report provides strong reassurance. RippleX stated, “We have found no evidence that this issue was exploited on any public network.” The safety check has now been improved to employ a wider counter that cannot overflow, ensuring that the same trick would now trigger an alarm.
However, RippleX’s wording is deliberate. “Found no evidence” means their review of the ledger’s history revealed nothing suspicious, which strongly supports the claim that no exploitation occurred but does not provide absolute mathematical proof that no exploit ever happened. The report stops short of making that claim.
Is the XRP Supply Cap Now Secure?
Yes, the XRP supply cap appears secure after the known vulnerability was closed and safeguards were strengthened. Ripple stands to benefit the most, since its bug bounty program caught a critical bug before it could be exploited, which may bolster trust as the company seeks to engage with banks and other institutions.
Contact [email protected] for any questions or corrections.








