XRP Ledger developers have defended an emergency security patch released on September 25 to fix a bug capable of creating XRP beyond the network's fixed supply. The patch took effect immediately on servers that installed it and marked the first deliberate bypass of the normal amendment process since the system's introduction over a decade ago.
The developers stated that using the standard two-week validator vote would have left the vulnerability public for weeks, risking network security. "With a normal amendment vote, the fix would have been public for weeks before it took effect, risking network security," XRPL developers said in a statement.
Decentralization Questions Raised
The expedited fix prompted questions about XRP Ledger's decentralization claims. The network markets itself as a fully decentralized, public blockchain, a characterization central to arguments that its native token, XRP, is not a security.
Cyber Capital founder Justin Bons criticized the emergency release, claiming that marketing XRP to retail investors as decentralized amounted to "straight-up fraud." He noted that the patch shipped as binaries only, temporarily withheld source code, and pressured operators to upgrade.
The XRP Ledger Foundation countered that the decision involved multiple parties. "No single party could make that call alone. Every validator and node operator chooses what software to run, and 3.4.1 only became required through a normal amendment vote with more than 80% validator support for two weeks," the foundation said.
XRP Kuwait, an independent validator operator, rejected centralization claims, stating: "Coordination is not the same as control. Independent operators can assess a situation, communicate with one another, and reach the same conclusion without giving up their independence."
Technical Details of the Vulnerability
The bug was an integer overflow in the XRP Ledger's payment engine present since 2015. XRP balances are stored as 64-bit integers with a fixed maximum. When a sum exceeded that maximum, the calculation wrapped to a smaller number instead of failing.
An attacker could exploit this by creating hundreds of specially priced offers requesting large amounts of XRP, then sending one payment that consumed them all. The engine would credit each offer owner their full amount but charge the buyer only the tiny wrapped total, with the difference representing newly created, spendable XRP.
The attack required deliberately constructed offers and could not be triggered by normal trading activity. Developers reported finding no evidence that the issue was exploited on any public network.
