Ledger Emergency Patch Closed a Bug That Could Have Minted 18.5 Trillion Tokens

The 18.5 Trillion XRP Overflow

The route ran through the order book. An attacker could line up offers with specially chosen prices on the exchange built into the XRP Ledger so that the payment engine's accounting overflowed, allowing spendable XRP to appear that the ledger had never created. The theoretical haul, roughly 18.5 trillion tokens, would have stood nearly 185 times above the network's fixed circulating supply cap of 100 billion XRP. At stake was the ledger's core supply safeguard: because the forged XRP would have been fully spendable rather than a display error, the overflow could have made the cap meaningless in practice. Developers shut the path down with an emergency patch, shipped as xrpld 3.4.1 on September 25.

The XRPL Foundation's vulnerability disclosure report traces the flaw to BookStep, the aggregation code that prices offers when a payment routes through the ledger's exchange. Offers arranged in a particular pattern could overflow the engine and defeat the XRPNotCreated invariant, the guard written in 2017 that stops XRP from coming into existence outside the protocol's own rules. Security firm Veria demonstrated the route in practice, moving the fabricated tokens through a series of wallet addresses while holding every account under the ledger's per-account balance ceiling, so the imbalance never surfaced on any single account. Veria put the theoretical exposure at about $94 billion. The schedule was compressed. The bug was confirmed on Tuesday, September 22, the fix was merged into the codebase the following day, and the patched release went out on Friday, September 25, folded into xrpld 3.4.1. Each step, confirmation, merge and release, landed inside four days. RippleX's review found no sign the flaw was ever used against a live network. The decision to bypass the usual amendment vote drew renewed attention on Monday, October 12, when the emergency patch announcement spread across X.

Why Validators Weren't Asked to Vote

Under XRPL's ordinary governance, validators vote on changes to how transactions are processed over a stretch of weeks before any new rule goes live, giving the network one coordinated point of transition. The amendments currently waiting in the pipeline follow exactly that route. This fix did not. Publishing the code ahead of activation could have handed attackers a working recipe while most servers still ran the vulnerable software, so developers released the patch directly, and it took effect on each server as that server upgraded to 3.4.1.

The exception carried its own risk. During the rollout, servers on different versions could have processed the same exploit transaction in different ways, leaving the network with conflicting views of the ledger. That window stayed short: Veria counted over 80% of validators on the new version by September 25. The severity of the flaw drove the call, since a two-week wait under the standard process could have given an attacker time to work while the network remained exposed. The episode also put the age of the code on the record: BookStep had been part of the software since 2015, and the XRPNotCreated invariant had sat alongside it since 2017, years before anyone found the combination that broke them.

The XRPL Foundation's disclosure report covers both the overflow and the choice to ship without the amendment route, and it is clear that this was an emergency response to a threat that could have created spendable XRP far beyond the original supply, not a new template for ledger governance. Validators are weighing separate protocol questions this month as well, including whether to lift the PaymentBurn delegation ban by October 23.

A Governance Question Left Open

The disclosure report is the load-bearing document here, and it states the limits plainly: no tokens were minted, and the 18.5 trillion figure measures what the exploit could have reached, not what it did. Our reading is that the cap held because it is enforced in code, not in anyone's custody. The flaw never touched a single private key; it attacked the accounting that decides when XRP exists at all. That frames the trade the report leaves open. An emergency patch was defensible against a supply-breaking bug, but a bypass repeated for lesser threats would erode the validator process that gives the ledger's rules their weight. With the upgrade largely complete by September 25 and no exploitation on record, the sources point to no remaining step a holder could still take. Our XRP technical analysis tracks the market side while that debate runs, and our guide to blockchain security audits explains how to read disclosure reports of this kind.