An overflow bug in the XRP Ledger could have allowed a single transaction to create more XRP than the entire existing supply. RippleX, Ripple's development arm, and the XRPL Foundation disclosed and fixed the flaw, likely present since 2015, in late September 2026. There is no evidence it was ever exploited.

A Supply Cap That Could Have Been Broken

The XRP Ledger is the decentralized blockchain behind XRP. It handles payments and trading through a built-in order book, and the payment engine is the component that matches payments against the offers placed there. The total supply stood at 100 billion XRP at launch. There is no mining and no inflation; only burned transaction fees slightly reduce the supply. That fixed cap rests on a ledger-level invariant — the rule that no transaction may create XRP — and this is precisely the guarantee the overflow bug undermined.

Version 3.4.1 of the xrpld server software was released 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 already 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.

How an Would Have Minted XRP Out of Thin Air

The payment engine summed the amounts of all offers that a payment consumed in the order book, using 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 would have received the full payment, while the ledger debited the buyer only the wrapped sum. The difference would have come 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 offering a tiny fraction of a token for an enormous amount of XRP. A single payment would then consume 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 have triggered 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, and he suspects this is why nobody found the flaw earlier.

Reported Through the Bug Bounty Program

Cayden Liao and Veria AI reported the vulnerability on September 22 through the network's bug bounty program, initially rating it "Major." RippleX reproduced the attack and raised the rating to "critical," 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 comes from Liao's calculation and would equal 184 times the total supply. Veria also says it received the maximum bounty of USD 250,000, though the report does not name an amount. Programs like this one are a standard mechanism across major blockchain networks for rewarding responsible disclosure.

According to the report, the bug had likely been in the code since the payment engine's development in 2015, going unnoticed for about a decade. The case fits into the wider trend of AI-assisted vulnerability hunting, which exposes flaws faster — a perspective RippleX developers also share.

A Fix Without an Amendment

Rule changes on the XRP Ledger normally go through so-called amendments, which require 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 justified the move by 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, but it remains contested in a decentralized network with governance ambitions.

A Second Bug in the Batch Feature

Version 3.4.1 also closed a second bug, in the batch feature (XLS-56), which affected xrpld 3.3.0 and 3.4.0. A batch holds up to eight inner transactions, and 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, though an attacker would have gained nothing on-chain. Mainnet saw no impact, 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, an amendment originally due to activate on September 29. The release started the two-week activation of fixBatchV1_2, and since October 9, both amendments have been active on mainnet.

Tightened Review Process

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, and the team closes it only once a test reproduces the original bug and the candidate passes. Among the additional safeguards listed in the report are 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. How the handles its next critical finding — through this reserved fast track or a regular amendment — will show whether the approach remains the exception the report describes it as.

Source: XRPL vulnerability disclosure report via Crypto Valley Journal