XRP Ledger defiende parche de emergencia por fallo de suministro ilimitado

A flaw lurking in XRP Ledger's payment engine since 2015 could have allowed someone to create unlimited XRP—a prospect so dangerous that the network's developers chose to bypass their standard governance process to fix it. On September 25, they released an emergency patch that took effect immediately on any server that installed it, skipping the usual two-week validator vote that has governed protocol changes for over a decade.

The vulnerability was an integer overflow in how the ledger tracks XRP balances. The system stores these balances as 64-bit integers with a fixed maximum. When a calculation exceeded that ceiling, instead of rejecting the transaction, the system would wrap the number back to a smaller value. An attacker could exploit this by creating hundreds of specially priced offers, each requesting an enormous amount of XRP, then sending a single payment that consumed all of them at once. The engine would credit each offer holder with the full amount requested, but charge the buyer only the tiny remainder left after the overflow. The difference would be newly created XRP, ready to spend.

The attack required deliberately constructed offers and could not be triggered by normal trading activity. The developers found no evidence the flaw had ever been exploited on any live network. But the risk was real enough that waiting felt impossible. "With a normal amendment vote, the fix would have been public for weeks before taking effect, which would have exposed the network to attackers," the XRPL developers said in a post on X.

The decision to move unilaterally raised immediate questions about whether XRP Ledger is truly decentralized—a claim central to arguments that XRP itself is not a security. Justin Bons, founder of Cyber Capital, called marketing XRP to retail investors as decentralized "outright fraud." He noted that the emergency version was distributed only as compiled binaries, the source code was temporarily withheld, and node operators were pressured to upgrade.

The XRPL Foundation pushed back, saying the choice to skip the normal amendment process was made jointly by the Foundation, RippleX, core developers, and validators after assessing the severity. "No single party could make that decision alone," the Foundation said. "Every validator and node operator chooses what software to run, and version 3.4.1 only became mandatory through a normal amendment vote with support from over 80 percent of validators over two weeks. Protocol changes continue to be processed through amendments." XRP Kuwait, an independent validator operator, also rejected the idea that coordinated upgrades proved centralized control. "Coordination is not the same as control," the operator said. "Independent operators can evaluate a situation, communicate with each other, and reach the same conclusion without surrendering their independence."

The tension between speed and transparency sits at the heart of what comes next. The patch worked. The network is secure. But the method used to secure it has handed critics a concrete example of how quickly decentralization can bend when the stakes feel high enough. For regulators weighing whether XRP qualifies as a security, the episode offers fresh material for debate.