XRP Ledger patched payment flaw that could mint spendable XRP
XRPL 3.4.1 blocks an order-book overflow that could mint spendable XRP, trading weeks of exposure under the usual validator vote for a shorter upgrade risk.
By The Coin Wire Editorial4 min read

The XRP Ledger’s developers released a fix on Sept. 25 for a payment-engine flaw that could create spendable XRP, closing a vulnerability they believe had existed since 2015. The XRPL’s Oct. 9 disclosure report says the bug was reported through its bug bounty program and reproduced by RippleX engineers. The report found no evidence of exploitation on a public network.
How could an order-book payment create XRP?
A payment could trigger the flaw by consuming hundreds of specially crafted offers in the XRP Ledger’s built-in order book. The payment engine added the XRP amounts due across those offers using a fixed-width 64-bit integer. When the sum exceeded the integer’s maximum, it wrapped around to a small amount instead of raising an error. Sellers still received the full amounts in XRP, while the buyer paid only the wrapped total; the difference was newly created XRP.
The offers had to be arranged across hundreds of accounts, and a separate account had to submit a payment designed to consume them all at once. The XRPL report says the accounts could all belong to the attacker, with the practical upfront cost limited to a few hundred XRP in account and offer reserves, plus transaction fees. The XRP created could then be spent like ordinary XRP.
Two safeguards did not stop it. The ledger’s “no XRP created” invariant used the same kind of unchecked arithmetic, so its total wrapped too. A per-account balance check also failed to catch XRP spread across hundreds of accounts. The bug therefore exposed a gap between the ledger’s intended supply rules and what its payment engine could validate in this unusual case.
Why did the fix skip the usual validator vote?
Under the usual amendment process, a transaction-rule change takes effect only after more than 80% of trusted validators support it for two weeks. That gives operators time to upgrade and makes the change activate at the same ledger across the network. For this flaw, developers judged that waiting would leave a serious, publicly visible exploit open for weeks once the fix was disclosed.
Instead, the correction took effect on each server as it upgraded to xrpld 3.4.1. The XRPL report says more than 80% of default UNL validators were running that version or later on the release date, Sept. 25. The choice shortened the exposure window, but created a period when upgraded and older servers would process the exploit differently. Had an attacker tried it during that window, the report says, servers could have disagreed on the ledger and fallen out of sync; in the worst case, the network could have halted.
CoinDesk’s report on the disclosure likewise describes a flaw that could have breached the ledger’s intended supply rules. The XRPL report says ordinary payments would not reach the overflow: the offers needed extreme prices, far below real liquidity, and the attack required a deliberately constructed payment.
What should XRPL users and operators watch now?
The immediate signal is whether server operators upgrade: the XRPL report says all operators must run 3.4.1 or newer to maintain sync. The patch checks for overflow when summing offer amounts and across multiple payment paths. It also widens the counter used by the “no XRP created” safety check so it cannot wrap around in the same way.
The report also sets out a next step for security reviews: XRPL’s team says it is adding a release-process check that retests every security finding marked fixed against the release candidate, using a test that reproduces the original issue. Whether that process is implemented, and whether future fixes withstand those reproductions, are concrete measures to watch alongside operator upgrades. The episode shows both the value of a bug bounty report that exposed a dormant flaw and the cost of bypassing coordinated activation: less time with a known exploit, but a short interval when server versions could disagree.
Source material
- XRPL’s Oct. 9 disclosure report — xrpl.org
- CoinDesk’s report on the disclosure — coindesk.com