XRP Ledger fixes overflow flaw that could mint 18 trillion XRP
XRPL’s 3.4.1 release closed an overflow flaw that could have created spendable XRP; its emergency rollout traded the usual validator vote for faster protection.
By Blockchain Today Editorial3 min read
RippleX fixed a decade-old XRP Ledger payment-engine flaw in software released Sept. 25, closing a route that could have created spendable XRP beyond the ledger’s 100 billion supply. The XRPL Foundation’s vulnerability disclosure report says it found no evidence the flaw was exploited on a public network.
The bug was in how the engine added up XRP owed across offers in the ledger’s built-in exchange. A sum larger than a 64-bit integer could wrap around to a small number: sellers would receive the full amounts listed, while the buyer was charged only the smaller total. The report says a second “no XRP created” check used similarly vulnerable arithmetic and could also miss the difference.
How much XRP could one transaction have created?
A proof of concept demonstrated that the newly created XRP could be spent in a later transaction. The Block reported that Veria Labs co-founder Cayden Liao estimated one exploit transaction could have created about 18 trillion XRP, roughly 184 times the original 100 billion supply. That is an estimate of the exploit’s potential, not a report of XRP actually minted.
The attack required a few hundred accounts, each offering a tiny amount of another token for an unusually large amount of XRP, followed by a payment that consumed all those offers. The attacker could control the accounts and needed only a few hundred XRP in reserves, which the report says would be returned when the accounts and offers were removed, plus transaction fees.
The amounts were deliberately implausible for real trading. The offers would sit below real liquidity in the order book, and the report says ordinary payments would clear before reaching them. This was a constructed route to bypass the supply protections, rather than a way for routine trades to create XRP by accident.
Why did the fix skip the validator amendment process?
XRPL transaction-rule changes normally take effect through an amendment: more than 80% of trusted validators must support a change for two weeks. This fix instead took effect on each server when it upgraded to version 3.4.1, a first for a transaction-processing change since the amendment system began, according to the disclosure.
The trade-off was speed against consistency during the upgrade. A normal public release could have revealed the flaw weeks before an amendment activated, leaving it exploitable while operators upgraded and validators voted. But servers on different versions process the affected payment differently; the report says that could have caused ledger disagreement or, in the worst case, a network halt.
RippleX’s fix makes the payment fail cleanly if the offer total would overflow, and uses a wider counter for the “no XRP created” check. More than 80% of default Unique Node List validators were on version 3.4.1 or later on release day, the report says. Operators still had to upgrade to remain in sync, and the release also included a separate Batch vulnerability fix that later activated through an amendment.
What should XRPL users watch next?
The disclosure says the XRP overflow fix applies immediately on upgrade, while the separate Batch fix activated on Mainnet through the fixBatchV1_2 amendment on Oct. 9. The report says older servers can no longer stay in sync after that activation. A practical signal to watch is whether remaining operators upgrade and the network continues to reach consensus through future releases.
XRPL’s team also says it plans to re-test security findings against release candidates before closing them as fixed. That safeguard, and the continued use of amendments for ordinary transaction-rule changes, will show how the ledger balances faster vulnerability response with coordinated rule changes after this exceptional patch.