256 Drops and One Payment Could Have Minted 18 Trillion XRP

One XRP is a million drops. For 256 of them, plus the transaction fee, a single payment on the XRP Ledger could have credited 256 accounts with 18,446,744,073,709.55 XRP between them. The ledger's supply has been capped at 100 billion since 2012. The payment would have created 184 times that, and the ledger's own check against created XRP would have waved it through, because it did the same arithmetic the same broken way.

That is the finding RippleX and the XRPL Foundation published on October 9 in a vulnerability disclosure report covering two bugs fixed in xrpld 3.4.1. The report says the overflow was reported through the XRPL bug bounty on September 22, reproduced the same day, patched into a release candidate on September 23 and shipped on September 25, and that the fix went out in a way the ledger has never used before. "We have found no evidence that this issue was exploited on any public network," it says. The reporter it credits is Cayden Liao of Veria Labs, whose own account says the bug was found, chained and turned into a working exploit by an AI agent.

Two bugs that wrap the same way

The XRP Ledger has a built-in exchange, and a cross-currency payment can fill many offers from that order book at once. The engine, written in 2015, added up the XRP owed across those offers using plain 64-bit arithmetic with no overflow check. Push the sum past the largest value a signed 64-bit integer can hold and it wraps around to a small number. Each seller is still paid in full, offer by offer. The buyer is charged the wrapped total. The difference is XRP that did not exist before the payment.

The ledger has a safeguard for exactly this: an invariant check, added about two years after the engine, that runs after every transaction and confirms the net change in XRP equals the fee burned. The report's finding is that the invariant kept its running total in the same kind of 64-bit integer, "so it also failed to detect the problem." A second safeguard, the per-account balance check, only fails if a single account exceeds total supply. Spread the new XRP across a few hundred accounts and no one account trips it.

Veria's write-up gives the construction. The engine caps a single traversal at 1,000 offers, and each account's balance is capped near 10¹⁷ drops, so the per-offer amount is bounded too. The agent's answer was 256 offers of 2⁵⁶+1 drops each. That totals 2⁶⁴+256 drops: the extra 256 is there because a sum landing exactly on 2⁶⁴ wraps to zero, which fails, while 2⁶⁴+256 wraps to a usable 256. "The buyer is charged 256 drops," Veria writes, and "the 256 makers collectively receive ∼2⁶⁴ drops of real XRP." Each maker ends up holding about 72 billion XRP, under the 100 billion cap, so all of it is spendable. The report says RippleX reproduced the attack on a standalone server and in unit tests, and "confirmed the minted XRP could be spent."

Two details in the report cut against the drama. The attack "could not be triggered by accident": it needs hundreds of offers priced in ways no trader would use, sitting below all real liquidity. And the report says it tested whether those offers could be used to grief ordinary payments, found identical payment and pathfinding results with or without them, and ruled that out.

Report, reproduce, raise, merge, ship

Liao submitted the finding rated Major, per the report. RippleX raised it to critical the same day, once it had confirmed the minted XRP could move. The fix was "developed privately and reviewed" on September 22 and 23 and merged into the first 3.4.1 release candidate on September 23. xrpld 3.4.1 shipped on September 25, and by the end of that day, the report says, more than 80 percent of the validators on the default Unique Node List were running it.

Veria's timeline matches to the day and adds its own colour. Its agent, pointed at the ledger's open-source code, "flagged the bug at 11 on a Monday"; the author says they re-read the proof of concept three times, then "woke up our founding engineer to go through it with me." The proof of concept ran on a local network on September 22 and the report went in that day. Veria says the maximum bounty of $250,000 was paid on October 8. "To our knowledge, that's the largest ever paid out for a vulnerability discovered entirely by an AI agent," Liao said, in a post quoted by The Block. The XRPL report gives no payout figure; the bounty number is Veria's.

The vote that did not happen

Changes to how the XRP Ledger processes transactions normally go through an amendment: a code change ships, validators vote on it, and it activates only after holding more than 80 percent support for two weeks. The overflow fix skipped that. It took effect on each server the moment that server upgraded. "This is 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 says.

The reasoning is set out plainly. The exploit was cheap, needed no special access and "would have been very hard to reverse." And xrpld is open source, so publishing the fix would publish the bug; under the amendment process, the hole would have stayed open and documented for the two-week voting window. The report concedes the cost. During the upgrade window, old and new servers could disagree about one of these payments and the network could halt, but "a network halt would actually be preferable to processing exploit transactions and creating an incorrect ledger state that would be hard to roll back."

The source stayed sealed. Validators upgraded on September 25 "even though the source code for the fix was not yet published," the report says, and the 3.4.1 tag did not appear on GitHub until October 10. The release notes there describe the fixes as having been "first published as binary-only packages on 2026-09-26," one day later than the September 25 date the report uses; this desk could not resolve the difference, which may be a time-zone artefact. Either way, the default-UNL validators ran a closed binary for roughly two weeks. Justin Bons of Cyber Capital put the objection in the obvious terms, saying XRP "has been running closed-source code for the last two weeks," per The Block. RippleX engineer Mayukha Vadari's reply, also quoted by The Block: "You can't sneak a critical bug patch into a routine public release process, it'll get spotted and reverse-engineered immediately."

Related 25 Fixes Core Lightning Kept Sealed for Two Weeks

The second bug was supposed to be fixed already

The same release carried a lower-severity fix with its own lesson. The Batch feature, which lets one account submit up to eight transactions as a unit, requires each inner transaction to be wrapped in a specific field. The server never enforced that. The report traces the bug to a finding in the Sherlock Attackathon, labelled F48 and rated low, which "was believed fixed" during earlier Batch work. On September 18, Denis Angell of the XRPL Foundation confirmed during re-verification that the fix was incomplete. On September 22, the same day the overflow landed, Vadari worked out that servers on versions 3.3.0 and 3.4.0 would disagree about which wrappers were valid, which on a mixed network could stall validation. That raised a low finding to a pre-activation blocker.

Batch was due to activate on September 29; operators switched their votes to no to reset its clock, shipped the fix as a separate amendment, and switched back. Both activated on October 9. The roadmap section of the report is a direct response: a re-verification step is being added to the release process, so that "every security finding marked as fixed" is retested against the release candidate before it is closed.

What the agent did

The claims about the AI belong to Veria and should be read as its own. Its post says the agent found both overflows, worked out that they had to be chained so the invariant would wrap by the same amount as the sum, and produced the exploit. "We suspect one reason nobody caught this vulnerability is that it chains together two bugs," Liao wrote, per The Block, and each alone would have been low severity. After disclosure, Veria says, "we pointed general-purpose coding agents directly at the vulnerable code, and they still couldn't find it." The report's acknowledgements name "Cayden Liao and Veria AI" for the report and proof of concept and say nothing about how it was found. J. Ayo Akinyele, RippleX's head of engineering, said the team would expand AI-assisted bug hunting and formal verification, per The Block.