XRP Ledger discloses decade-old bug that could have minted XRP from nothing, finds no evidence of exploitation

A bug that could have let anyone create new XRP with a single payment sat in the XRP Ledger (XRPL) for nearly a decade. The XRPL website (xrpl.org) published a vulnerability disclosure report on Oct. 9 (local time), saying the flaw was closed by xrpld 3.4.1, an emergency server release shipped on Sept. 25. "We have found no evidence that this issue was exploited on any public network," the report said.

The same report also covered a flaw in the Batch transaction feature, which went live on mainnet on the night of Oct. 9. It explains why the two Batch upgrades Coinyong reported on Oct. 9 were delayed once before switching on.

1. Sept. 18Batch validation gap reconfirmed; public fix work begins
2. Sept. 22Payment engine bug reported via bug bounty; XRP minting reproduced the same day
3. Sept. 22-23Payment engine fix developed privately; decision to ship it without a vote
4. Sept. 23-24Ripple and other validators pull Batch votes; Batch fix merged into 3.4.1
5. Sept. 25xrpld 3.4.1 released; over 80% of default UNL validators upgrade the same day
6. Oct. 9, 23:15Batch security fix (fixBatchV1_2) activates on mainnet (KST)
7. Oct. 9, 23:47Batch transactions (BatchV1_1) activate on mainnet (KST)

When the total overflowed, it wrapped to a small number

The problem arose when a payment consumed many offers from the order book at once. The XRPL payment engine added up what the buyer owed using plain 64-bit integers, and when the sum exceeded the maximum it did not fail with an error but wrapped around to a tiny number (an overflow). The engine paid each offer owner their full amount while charging the buyer only the wrapped-around total, and the difference became XRP that should never have existed.

The XRPL has a built-in safety check to ensure no transaction creates XRP, but that check summed balances the same way, so it wrapped around identically and caught nothing. A separate check that fails when a single account holds more than the total supply could be avoided by spreading the minted XRP across hundreds of accounts. The report said investigation suggests the bug had been present since the current payment engine was written in 2015.

The attack did not need a large starting balance. According to the report, an attacker could create hundreds of accounts, have each place an offer selling a tiny amount of a token for a very large amount of XRP, and then send a single payment from another account that bought through all of them at once. The cost was a few hundred XRP in account and offer reserves plus fees. The bug bounty report rated the finding Major, but RippleX engineers raised it to critical after reproducing the bug and confirming the minted XRP could be spent. Had it been exploited, the report said, an attacker "could have created spendable XRP far beyond the total supply in a single validated transaction" and sent it to exchanges. It added that the attack could not happen by accident, because it required hundreds of offers priced in a way no real trader would use. The bug was reported through the bug bounty program by Cayden Liao and Veria AI.

A first: a rule change without a vote

Changes to how the XRPL processes transactions normally go through a vote known as an amendment. A change switches on across all servers at the same moment only after holding the support of more than 80% of trusted validators for two weeks. This fix skipped that process and took effect on each server as soon as it upgraded to 3.4.1. The report called it "the first time a change to transaction processing has deliberately shipped this way since the amendment system was introduced more than ten years ago."

The report pointed to the risk of disclosing a bug in open-source code. Because xrpld is open source, publishing a fix also shows where the bug is, and going through the vote would have left a known bug exploitable on mainnet for weeks. Servers on mixed versions risked disagreeing on the ledger and halting the network, but the report said a halt was preferable to having invalid XRP recorded in the ledger. More than 80% of operators on the default Unique Node List (UNL) upgraded on release day, before the source code was even published. The report stressed that the decision was reached together by the XRPL Foundation, RippleX and validators, and that transaction-processing changes will still go through amendments.

Validators reset the clock to delay Batch

The other flaw disclosed was in Batch (XLS-56), which processes up to eight transactions as a single unit. Inner transactions are supposed to be wrapped in a field called "RawTransaction," but the server did not check this, so transactions wrapped in other fields were also accepted. The report said this could cause servers on different versions to disagree and stall ledger validation, and could break wallets and explorers that read transaction records. It was not a flaw that could drain funds, and because the feature had not yet been switched on, there was no mainnet damage.

Batch had originally been scheduled to go live on Sept. 29. Ripple and other validator operators switched their votes to "no" to reset the two-week clock, then switched back to "yes" after the fix gained majority support. As a result, according to the XRPL explorer XRPSCAN, the fix activated at 11:15 p.m. KST on Oct. 9 and Batch followed 32 minutes later. Servers that have not upgraded to 3.4.1 can no longer stay in sync with the network.

XRP flat around 1,900 won the day after Batch went live

As of 5:30 p.m. KST on Oct. 10, XRP traded at 1,917 won on Upbit's Korean won market, up 0.4% from the previous close, and at 1,916 won on Bithumb at the same time. The Binance spot price was $1.4065, and Upbit traded about 1.6% above that price converted into won, a gap known as the kimchi premium (the difference between prices on Korean exchanges and global markets). Upbit's 52-week high for XRP is 3,970 won, set on Oct. 27, 2025.