XRP Ledger Fixes a Decade-Old Bug That Could Break Its Supply Cap
A quietly deployed software release closed a critical accounting flaw that could have created spendable XRP without a funded sender.
The XRP Ledger has disclosed and patched a critical accounting flaw that could have allowed an attacker to create spendable XRP without supplying the corresponding funds. The vulnerability was old, the potential consequence was fundamental, and the response was deliberately quiet until operators had time to upgrade.
Researchers Cayden Liao and Veria AI reported the issue privately on September 22. RippleX engineers reproduced the behavior on a standalone server, confirmed that the improperly created XRP could be spent in a later transaction, and shipped the fix in xrpld version 3.4.1 on September 25. The public security report followed only after the remediation window. RippleX said it found no evidence that the flaw had been exploited on public networks.
The defect concerned the ledger's built-in decentralized exchange. An attacker could construct many offers that exchanged tiny quantities of one asset for disproportionately large amounts of XRP, then route a single payment across those offers. A counting error could cause the transaction engine to credit recipients with more XRP than the sender actually funded. That matters because XRP's monetary design begins with a fixed 100 billion units created at launch; the protocol is not supposed to permit additional issuance.
This was therefore not a routine availability bug. If used successfully at scale, it could have undermined the supply invariant that supports market pricing, exchange risk controls and institutional assumptions about the asset. The immediate risk was counterfeit liquidity entering circulation, potentially being sold before validators, exchanges or analytics providers understood its origin.
The absence of observed exploitation is reassuring but cannot be treated as mathematical proof that no private attempt occurred. Public-ledger analysis can identify abnormal balances and transaction patterns, yet certainty depends on the completeness of monitoring and the quality of the historical search. Operators also need to distinguish the software release from network-wide safety: a fix only protects infrastructure that has upgraded.
The technical root cause makes the severity easier to understand. The engine added amounts across many order-book offers using an unchecked 64-bit integer. A deliberately constructed total could exceed that integer's maximum and wrap to a small value. Individual recipients were still credited their full amounts, while the buyer was charged only the wrapped total. The ledger's existing no-creation invariant used the same arithmetic pattern, so it could wrap in the same way and fail to detect the inflation.
The remediation added overflow checks to payment aggregation and widened the counter used by the invariant. RippleX also hardened other balance-aggregation paths as a precaution. More unusually, the transaction-processing change became effective as operators installed the release rather than waiting for the standard amendment vote and activation cycle. The official report says more than 80% of validators on the default trusted list upgraded on release day. That reduced the exposure period, although mixed software versions briefly created their own consensus risk.
The disclosure illustrates a recurring trade-off in open financial infrastructure. Publishing full exploit details before a supermajority of validators is protected can give attackers a usable blueprint. Delaying disclosure, however, temporarily leaves users unable to evaluate the change. Coordinated vulnerability handling is defensible when paired with a prompt patch, operator outreach and a later technical account that allows independent scrutiny.
For exchanges, custodians and institutions using XRP Ledger, the practical questions are operational. They should confirm that their own nodes and critical counterparties run a patched version, review deposits and withdrawals around the affected period, and preserve monitoring for balances or payment paths that violate expected conservation rules. Developers building on the ledger should also test assumptions at the transaction-engine level rather than relying solely on the advertised supply cap.
Why it matters
Digital-asset value depends not only on consensus uptime but on the correctness of the accounting rules consensus enforces. A network can continue producing blocks while faithfully agreeing on a defective result. This incident shows why mature blockchain infrastructure needs the same disciplined patching, version management and post-incident transparency expected of conventional payment systems.
The episode also strengthens the case for independent security research and formal testing of long-lived protocol code. A vulnerability believed to date to 2015 survived years of market growth and institutional adoption. The fix appears to have contained the immediate threat, but the larger lesson is that monetary invariants require continuous verification, not historical confidence.