Key Takeaways
- Cayden Liao and Veria AI initially reported the XRPL overflow bug through the bug bounty program on Sept. 22, 2026.
- RippleX rated the flaw critical, and over 80% of default UNL validators ran the xrpld 3.4.1 fix by Sept. 25.
- The XRPL disclosure on Oct. 9 found no exploit, as the fixBatchV1_2 amendment went live the same day.
What Was Actually Broken?
The problem sat inside the code that settles payments across the XRP Ledger’s built-in decentralized exchange (DEX). According to the official vulnerability disclosure report published yesterday, when a single payment consumed many offers, the engine added up the amounts using unchecked 64-bit arithmetic.
By pushing that sum high enough, it “wrapped around,” which is what an integer overflow does. A gigantic number subsequently became a small one and the sellers on the other side of the trade were paid in full, but the buyer was only charged the wrapped, tiny total. The difference was XRP that never existed before.
The ledger does run a safety check, known as an invariant, that is supposed to confirm no XRP is ever created. That check used the same unchecked math, so it was blind to the exact failure it was built to catch. The report traces the flaw back to the current payment engine, which was written in 2015.
How Cheap Would an Attack Have Been?
The report says the cost was a few hundred XRP locked up as reserves, which are returned once the objects are removed, plus ordinary transaction fees. An attacker would have needed to place hundreds of deliberately mispriced offers and then route one payment through them.
The payoff was the scary part, with RippleX calling the bug critical because spendable XRP could have been created beyond the total supply in a single validated transaction. XRP’s whole pitch rests on a hard cap of 100 billion tokens, so a silent mint would have hit the asset’s core promise. That is why posts such as one from Whale Insider framed it as a bug that could have conjured “billions” of XRP.
Who Found It and How Fast Was It Fixed?
The timeline was quite brief and as follows:
- Sept. 22: Cayden Liao and Veria AI submitted their findings through the XRPL Bug Bounty program, rating it “Major.”
- Sept. 23: RippleX reproduced it, upgraded it to critical, and the fix was merged.
- Sept. 25: Xrpld 3.4.1 was shipped, and more than 80% of default Unique Node List (UNL) validators were running it that day.
- Oct. 9: Public disclosure.
The patch did not go through the usual amendment vote but was instead shipped as a direct code change in release 3.4.1 and took effect as each server upgraded. Source code was only published after deployment, a standard move to avoid handing attackers a map. The XRPL Operations account has since made 3.4.1 the minimum required version, adding:
We have found no evidence that this issue was exploited on any public network.
A second, lower-severity bug was fixed in the same release. It involved how Batch transactions are wrapped, and its fix sits behind the fixBatchV1_2 amendment, which went live on Mainnet on Oct. 9 alongside BatchV1_1. The report says no funds were lost from that one either.
The disclosure landed in an ugly week for crypto security as Ledger device losses, which Bitcoin.com News reported, reached an estimated $93.4M. Lastly, Ripple-backed Evernorth is preparing to start trading on Nasdaq under XRPN on Monday, with roughly 473 million XRP on its books. XRP has also been expanding into decentralized finance (DeFi), with Firelight recently activating vault protection on the network.
