The October 10 post is about AI finding bugs faster. The October 9 report says the check that was supposed to stop a mint used the same addition, so it wrapped the same way.
On October 9 the XRP Ledger published the disclosure for xrpld 3.4.1. It covers two bugs. The overflow is the one in the October 10 post. The other is a wrapper check on Batch inner transactions, a feature that had not activated on Mainnet. The report says that one did not touch Mainnet funds.
On October 10, @ja_akinyele posted about the overflow. His X bio says he is head of engineering at RippleX. The post is https://x.com/ja_akinyele/status/2109062336543686996. When I read it on October 11 it had 751 likes, 129 reposts, and 41,133 impressions. He wrote that the bug had existed for over a decade and could have allowed XRP to be created beyond its fixed supply. Then he wrote the line people are repeating: AI is fundamentally changing how quickly vulnerabilities can be discovered. The rest of the post is a list. More bounty work, more AI-assisted testing, a pass over old assumptions in the payments engine, and formal verification with CommonPrefix and the XRPL Foundation.
The disclosure is https://xrpl.org/blog/2026/vulnerabilitydisclosurereport-bug-20261009. Cayden Liao and Veria AI reported the overflow through the XRPL bug bounty on September 22. The bounty report rated it Major. RippleX reproduced the mint on a standalone server the same day, confirmed the new XRP could be spent in a later payment, and raised it to critical. The fix shipped in xrpld 3.4.1 on September 25. The public write-up waited until October 9. RippleX says it found no evidence the bug was used on any public network. That is their statement. I did not audit the ledger.
The same addition
XRP balances are integers with a fixed maximum. When a payment walks an order book, the engine takes every offer at the best price in one pass and adds up what the buyer owes. That sum was plain 64-bit addition. There was no overflow check.
Each offer was valid on its own. A few hundred of them, each asking for a very large amount of XRP, add up to more than a 64-bit integer can hold. The total wrapped around to a small number. The engine still credited each offer owner the full amount. It charged the buyer only the wrapped total. The gap is XRP that was not in the ledger before the transaction.
The ledger already had a check for this. The report calls it the “no XRP created” invariant. That check summed the net change with the same kind of 64-bit counter. It wrapped the same way. After the wrap, the net change looked like the transaction fee, which is what a normal transaction looks like, so the check passed.
A second check fails only if one account holds more than the total supply. Spreading the new XRP across hundreds of accounts kept every balance under that line. Both checks ran. Both passed.
The overflow has been there since the current payment engine was written in 2015. The invariant was added two years later, on the same unchecked arithmetic. The report says no normal payment comes near a 64-bit overflow, because the total supply sits far below the wrap point. You have to build the offers on purpose.
The path in the report is specific. The attacker opens a few hundred accounts and has each one offer a tiny amount of some token for a very large amount of XRP. One payment from another account buys through all of those offers at once. The buyer is charged a few hundred drops plus the fee. A drop is one millionth of an XRP. The offer owners hold more XRP than the buyer spent, and the attacker can spend it from any of those accounts. All of them can belong to the attacker. The cost up front is a few hundred XRP in account and offer reserves, returned when the objects are removed, plus ordinary fees. RippleX confirmed the minted XRP was spendable in a follow-up payment. That test was on a standalone server and in unit tests, not on Mainnet.
The disclosure says an exploited transaction would have created spendable XRP far beyond the total supply, in ordinary accounts that could be moved, traded, or sent to exchanges. It does not say how much one transaction could mint.
The first report also said these offers might sit in the book and block other payments. The disclosure says that does not work. To hit the overflow, the offers have to be priced so badly they sit under real liquidity. Normal payments fill before they reach them. Payments and path finding returned the same results with or without those offers.
Starting in xrpld 3.4.1, the sum checks for overflow. If the total would wrap, that part of the payment fails as a normal path-dry or partial-payment result. Nothing is minted. The same check was added where the engine combines results from multiple paths. The invariant now uses a wider counter that cannot wrap. A few other places that add balances across many accounts were hardened the same way. The report says none of those could be reached by a real transaction today.
The fix that did not wait for a vote
Transaction-processing changes on the XRP Ledger normally go through an amendment. The new rule ships in the software and stays off until more than 80 percent of trusted validators have supported it for two weeks. Every server switches at the same ledger. This fix did not do that. It took effect on each server as soon as that server upgraded to 3.4.1. The report says 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.
xrpld is open source. A release that contains the fix also shows where the bug is. Under the amendment process, the fix would have been public for weeks before it turned on: upgrade time, a vote, then the two-week clock. For all of that time the bug would have been visible and still usable on Mainnet. The exploit was cheap, needed no special access, and the minted XRP would have been hard to undo.
They shipped the binary and held the source. More than 80 percent of validators on the default UNL were running 3.4.1 on September 25, the release day, even though the source for the fix was not yet published. The October 9 report says that source is public now.
During the upgrade, servers on different versions follow different rules for these payments. An exploit in that window would be rejected by upgraded servers and accepted by older ones, and the two groups would disagree on the ledger. The report says normal transactions never reach this code path, so the exploit was the only transaction that could cause that split. Their view is that a halt is better than writing minted XRP into a ledger that is hard to roll back, and that a short upgrade window was safer than weeks of a known bug. Members of the XRPL Foundation, RippleX, and the validators agreed. That is the report’s account. I was not in that room.
The bug that sat there since 2015 was not missed because the invariant was missing. The invariant was there. It added the numbers the same way the bug did, and then it passed. The wider counter is what they changed on this check. A later sum can still be written the old way.