An XRP Ledger bug could have created more XRP in a single transaction than exist in total. RippleX fixed the overflow error, likely present since 2015, in late September 2026, with no evidence of exploitation.
The XRP Ledger is the decentralized blockchain behind XRP. It handles payments and trading through a built-in order book. The payment engine is the part of the code that matches payments against the offers placed there. At launch, the total supply stood at 100 billion XRP. There is no mining and no inflation, and only burned transaction fees slightly reduce the supply. RippleX, Ripple's development arm, and the XRPL Foundation disclosed the case jointly. Version 3.4.1 of the xrpld server software came out on September 25, and the disclosure report followed 14 days later. Before that, more than 80% of validators on the Default Unique Node List (UNL) had upgraded. The bug affected xrpld 3.4.0 and all earlier versions. Veria Labs, which reported the bug, calculates that a single exploit transaction would have created around 18 trillion XRP.
Subscribe to our newsletter
The best articles of the week, directly delivered into your mailbox.
An overflow in the payment engine creates XRP out of thin air
The payment engine added up the amounts of all offers that a payment consumed in the order book. To do so, it used a 64-bit integer addition without an overflow check. If the sum grew large enough, the value wrapped around to a small number. Each offer owner received the full payment, but the ledger debited the buyer only the wrapped sum. As a result, the difference came into existence as new XRP.
Two safeguards should have prevented this. However, the invariant stating that no transaction may create XRP used the same overflowing arithmetic. In addition, the per-account balance check only triggers above the total supply. Yet the created XRP would have landed in many accounts. For the attack, an actor would have set up hundreds of accounts. Each would offer a tiny fraction of a token for an enormous amount of XRP. A single payment then consumes all of the offers. And every account involved could belong to the attacker. Costs came to a few hundred XRP in recoverable reserves plus fees, so the attacker needed no large starting balance.
Still, no one could trigger the overflow by accident. Normal payments never reach the required sum, because no real trader would quote such prices. The report also states that there is no evidence of exploitation on any public network. Cayden Liao of Veria Labs says the exploit chains two bugs that would each rate as low severity alone. He suspects this is why nobody found the flaw earlier.
Veria Labs reports the XRP bug through the bug bounty program
Cayden Liao and Veria AI reported the XRP Ledger vulnerability on September 22 through the network's bug bounty program. The reporters initially rated it as "Major". RippleX reproduced the attack and raised the rating to "critical". The team then developed the fix privately. One day later, the fix landed in the release branch for version 3.4.1 and shipped in release candidate 3.4.1-rc1. Since then, the payment engine checks for an overflow when it sums the offer amounts. If the sum overflows, that part of the payment fails.
Only Veria Labs has provided details about the discovery itself. The company says an AI agent found the bug and built a working exploit. By contrast, the disclosure report names only Liao and Veria AI as reporters. The figure of around 18 trillion XRP also comes from Liao's calculation and would equal 184 times the total supply. Moreover, Veria says it received the maximum bounty of USD 250,000. The report does not name an amount.
According to the report, the bug had likely been in the code since the payment engine's development in 2015. It went unnoticed for about a decade. The case thus fits into the wider trend of AI-assisted vulnerability hunting, which exposes flaws faster. RippleX developers also argue from this perspective.
The fix works without an amendment, disclosure follows 14 days later
Rule changes on the XRP Ledger normally go through so-called amendments. A change needs the support of more than 80% of trusted validators over a two-week period. This fix, however, took effect immediately as each individual server upgraded. The report calls it the first deliberate change of this kind to transaction processing since amendments arrived. On release day, more than 80% of Default UNL validators were already running version 3.4.1 or later.
RippleX justifies the move with the time window. A regular open-source release would have shown attackers where the bug sat, weeks before the fix took effect. Members of the XRPL Foundation, RippleX and XRPL validators therefore agreed in advance that the risk justified a fast approach. In their view, only the most severe bugs warrant this step, while all other changes still go through amendments.
"AI has changed things. You can't sneak a critical bug patch into a routine public release process, it'll get spotted and reverse-engineered immediately." - Mayukha Vadari, RippleX
Yet the team published the 3.4.1 source code on GitHub only around two weeks after the binaries. Justin Bons, founder of Cyber Capital, criticized on X that XRP had been running on closed-source code for two weeks. A silent patch with delayed disclosure is common practice in software security. Nevertheless, it remains contested in a decentralized network with governance ambitions.
A second bug in the batch feature tightens process rules
At the same time, version 3.4.1 closed a second bug in the batch feature (XLS-56). It affected xrpld 3.3.0 and 3.4.0. A batch holds up to eight inner transactions. Under the specification, each one must sit in a field called RawTransaction. The server did not check this. As a result, a permanently malformed ledger entry could arise that might have disrupted indexers, explorers and SDKs. A consensus variant was more serious. With mixed software versions, a crafted transaction could have halted validation at the cost of one transaction fee. An attacker would have gained nothing on-chain from this. Mainnet saw no impact, though, since BatchV1_1 was not active there.
The finding first surfaced at the Sherlock Attackathon, initially rated "low". On September 18, Denis Angell of the XRPL Foundation confirmed that an earlier fix was incomplete. Four days later, Mayukha Vadari identified the consensus risk. Ripple and validator operator Vet then withdrew their votes for BatchV1_1. The amendment was originally due to activate on September 29. Meanwhile, the release started the two-week activation of fixBatchV1_2. Finally, since October 9, both amendments have been active on mainnet.
RippleX is therefore changing its review process. From now on, every security finding marked as fixed goes through a new test against the release candidate. The team closes it only once a test reproduces the original bug and the candidate passes. Among other additional safeguards, the report lists public attackathons and AI-assisted red teaming. Older versions count as "amendment-blocked" and no longer stay in sync. Operators thus need to upgrade their servers to xrpld 3.4.1 or later.
