XRP Ledger developers said on X that bypassing the network’s normal two-week validation process was necessary when fixing a 10-year "infinite mint" vulnerability. In their view, following the standard path would have left the patch public for weeks and given attackers a window to act.
The emergency fix went live on Sept. 25 and marked the first time XRPL had skipped its standard amendment procedure. Developers said that was only the first step. Independent nodes later used the same approach to identify four additional vulnerabilities, confirming that the system contained multiple integer overflow issues.
Why the patch bypassed the usual process
Developers described the move as a necessary evil. Their argument was straightforward: if the patch had been disclosed first and then left to sit through the normal review window, the vulnerability details would have been exposed in public for several weeks.
That decision opened a second debate. Independent validators said the patch process revealed traces of centralization in blockchain governance, especially in an emergency, when the questions become who coordinates an upgrade and how node operators are pushed to update quickly.
How the flaw could create XRP out of thin air
The mechanism described in the report is relatively simple. XRP balances are stored in a 64-bit integer with a fixed upper bound. When the total exceeds that limit, the calculation wraps around to a small number instead of failing.
Under the scenario outlined in the article, an attacker could place hundreds of offers on the ledger at specific prices, each asking for an extremely large amount of XRP, and then submit a payment that consumes all of them. The engine would record the full amount of each offer on the ledger, while deducting only the tiny wrapped value. The difference would become newly created XRP that could be spent immediately.
Justin Bons attacks XRPL’s decentralization claims
Cyber Capital founder Justin Bons said on Thursday that marketing XRP to retail investors as decentralized amounted to "outright fraud." He said the Sept. 25 emergency release was distributed only as a binary at first, with the source code temporarily withheld, while node operators were pressured to upgrade.
That criticism shifted part of the discussion away from the bug itself and toward how XRPL handles governance during urgent security events.
XRPL Foundation says no single party made the call
The XRPL Foundation responded quickly. It said the decision to skip the normal amendment process was made after a joint assessment by the foundation, RippleX, core developers, and validators.
The foundation said, "No single entity can make this decision on its own. Each validator and node operator independently chooses what software to run."
Independent validator accepts coordination, with limits
XRP Kuwait, an independent validator node in Kuwait, also rejected the idea that a coordinated upgrade automatically proves centralized control. It said, "Coordinating an update among operators is not, by itself, evidence of centralized control. Coordination is not control. Independent operators can assess the situation, communicate with one another, and reach the same conclusion without giving up their independence."
Still, the argument did not disappear. The article says the real issue is how to define "communicate with one another." If five major nodes privately align on an upgrade timetable without a consensus rule requiring it, the line between coordination and decentralization remains open to challenge. The piece also notes that Bitcoin Core developers communicate privately about block difficulty adjustments before mining.
Disclosure report says the bug dates back to 2015
According to XRPL’s vulnerability disclosure report, the integer overflow existed in XRP Ledger’s payment engine and had been present since 2015. The report said the exploit required deliberately constructed offers and would not be triggered by ordinary transaction activity.
Developers said they found no evidence that the flaw had been exploited on the public network. That, they added, does not mean the vulnerability was not real; it only means no one had noticed it.
The report also said the same 64-bit integer stores both XRP balances and currency precision. When the precision bits are filled, the calculation wraps instead of throwing an overflow error.
The numbers behind the fixed-supply claim
The article ties that design to a more specific supply question. XRP’s theoretical fixed supply is 100 billion tokens, but the actual usable upper bound is 524,710,599, according to the report cited in the piece. The remaining roughly 94.7 billion XRP are not actively used and instead sit on the ledger as a buffer.
Later in the article, the author says the fixed-supply assumption depends on a 5.2 billion XRP buffer never being exhausted. If two or three more overflow flaws of the same kind were found, that assumption would no longer hold.
Two issues now stand out
The article says the incident leaves two threads worth watching.
- First, the degree of decentralization depends heavily on definition. If backstage coordination among nodes during an upgrade counts as centralization, then almost no major chain would qualify as meaningfully decentralized.
- Second, the fact that an integer overflow bug remained hidden for 10 years in an 11-year-old system suggests there may be other issues in the XRPL codebase that have not yet been noticed.
Taiwan market angle
The article adds that XRP is one of the most commonly held tokens in Taiwan’s crypto market, largely because of its fast transaction speed and low fees. If XRPL’s internal mechanics run into trouble, the most direct impact would fall on exchanges and payment institutions that use XRP as a payment rail, and those firms hold a meaningful share of the local market.
The piece says the patch did not cause actual losses, but it did serve as a reminder that the market’s working definition of decentralization may be looser than many users assume.