How could an arithmetic error threaten the 100B XRP supply cap? Learn how researchers identified the XRPL payment flaw before anyone could exploit it.
One payment could have charged a buyer a few hundred drops of XRP while crediting hundreds of sellers with trillions. The ledger’s own safety checks would have waved it through. That is what an arithmetic error in the XRP Ledger’s payment engine made possible, according to the vulnerability disclosure report published on Oct. 9, 2026. The fix, xrpld 3.4.1, had shipped two weeks earlier, on Sept. 25.
The XRP Ledger bug was an integer overflow, a calculation that exceeds the largest number a computer can store and wraps around to a small one. Developers say it dates to the current payment engine, written in 2015. Cayden Liao and Veria AI reported it through the XRPL bug bounty program on Sept. 22. Developers say they found no evidence of exploitation on any public network.
The central finding is narrow. The supply cap held because a researcher found the flaw first and validators upgraded quickly. The open questions concern governance and the speed of bug discovery, not lost funds. The sections below cover the mechanism, the timeline, why the fix skipped a validator vote, who found it, and the risks that remain. Nothing here predicts prices or recommends any action.
The ledger counts XRP in drops, where one XRP equals one million drops. Computers store whole numbers in fixed-size containers. A 64-bit container has a ceiling in the quintillions, and code that adds past it without checking wraps back to a small value, like a car odometer rolling over. The full 100 billion XRP supply equals about 100 quadrillion drops, far below that ceiling. Honest activity never gets close.
When a payment runs through the ledger’s built-in order book, the engine takes every offer at the best price in one pass and totals what the buyer owes. The report says that total used plain 64-bit addition with no overflow check.
Each offer was valid on its own. A few hundred offers, each asking an enormous amount of XRP, added up past the ceiling. The total wrapped to a tiny number. The engine credited every offer owner in full and charged the buyer only the wrapped total. The difference was new XRP.
The attacker would not have needed a large balance. The huge numbers were what the offer owners received, not what the attacker put up. All the accounts could belong to the attacker. The offers had to be priced so badly that no real trader would touch them, so ordinary payments never reached that code path.
The ledger has an invariant, a built-in safety check that confirms no transaction creates XRP. According to the report, it summed balance changes with the same kind of 64-bit counter. It wrapped in the same way, so the net change looked like an ordinary transaction fee. The report adds that this check was written two years after the payment engine, on the same unchecked arithmetic.
A second guard only trips if one account holds more than the total XRP supply. Spreading the minted coins across hundreds of accounts kept every balance under that line. Two independent-looking defenses both depended on the same weak assumption.
Veria’s estimate of the maximum yield is about 18.45 trillion XRP in one transaction, roughly 184 times the supply. Veria’s proof of concept used 256 offers spread across 256 accounts. The 18.45 trillion figure lines up with 2^64 drops, the ceiling of an unsigned 64-bit integer. That is consistent with a wraparound of that size, but it is an inference, not a statement from the report. remio
The official timeline is short. The table combines the XRPL report with Veria’s account where noted.
| Date (2026) | Event | Source |
| Sept. 21 | Veria says its AI agent flagged the issue | Veria (company account) |
| Sept. 22 | Reported via bounty and rated “Major”; RippleX reproduced it and raised it to critical | XRPL report |
| Sept. 23 | Fix merged into the 3.4.1 release branch | XRPL report |
| Sept. 25 | xrpld 3.4.1 released; over 80% of default-UNL validators running it | XRPL report |
| Oct. 8 | Maximum bounty awarded | Veria (company account) |
| Oct. 9 | Public disclosure; source code published | XRPL report |
The release notes for 3.4.1 described the change only as assorted integer-arithmetic hardening in the payment engine. They said the source was withheld because of the fix’s security-sensitive nature. Readers of the Sept. 25 notes could not have known what was being closed.
The XRP Ledger normally changes transaction rules through amendments. A new rule ships in software but stays off until it keeps the support of more than 80 percent of trusted validators for two weeks. Every server then switches at the same ledger. Decrypt reported that this was the first deliberate bypass of the process for a transaction-processing change since it was introduced more than a decade ago. decrypt
The reasoning in the report is mechanical. The software is open source, so any release containing the fix also shows where the bug is. Under the normal process, the flaw would have been visible and still exploitable for weeks. Shipping the fix as a direct change shrank that window to the time validators needed to upgrade.
The trade-off was real. During the upgrade, servers on different versions would handle the exploit differently, and the network could have split or halted if someone had tried it. The report judged a halt preferable to a corrupted ledger that would be hard to roll back. It also stated that the approach worked only because validators moved fast. Operators on the default list upgraded the same day, before the code was public.
Not everyone accepted the logic. Block Media reported criticism that the “protect first, disclose later” sequence undermined decentralization. The report anticipates this and says the case does not change how the ledger makes protocol changes. Amendments remain the rule, and skipping them is reserved for bugs where the exploit is worse than a network halt. blockmedia
Veria’s account is the only public description of how the XRP Ledger bug was found. The XRPL report credits Liao and Veria AI for the original report and proof of concept but does not say how the flaw was discovered. The Block reported that Liao said Veria’s AI agent found the bug, built a working exploit, and earned the program’s maximum $250,000 bounty. Veria also says the flaw chains two bugs that would be low severity alone, which may explain why years of review missed it. theblock
The report confirms the pairing: an overflow in the offer sum and an invariant built on the same arithmetic. It does not confirm the bounty figure or the claim that this was the largest bounty ever paid for an AI-found flaw. Treat those as company claims.
Liao has argued that, in his words, “AI is making old bugs much cheaper to find”, a point he frames as cutting both ways for attackers and defenders. RippleX’s head of engineering, Ayo Akinyele, wrote on X on Oct. 10 that “this was a serious vulnerability” and said the team would expand AI-assisted bug hunting and formal verification. ambcrypto
| Claim | Where it comes from | Status |
| Integer overflow in the payment engine, present since 2015 | XRPL report | Official (“investigation suggests”) |
| No evidence of exploitation on any public network | XRPL report | Official, but absence of evidence |
| Fix live on Sept. 25, over 80% of default-UNL validators upgraded | XRPL report | Official |
| About 18.45 trillion XRP mintable in one transaction | Veria | Researcher estimate; not in the report |
| $250,000 maximum bounty | Veria | Company claim |
| AI agent found the flaw | Veria | Company claim; report silent on method |
The split matters for readers who share the story. The mechanism, dates, and fix are documented in the primary source. The headline numbers are not.
XRP fell 6.2% on Oct. 8, during a broad crypto sell-off. Public disclosure came on Oct. 9, so that decline cannot be a reaction to the disclosure. The Oct. 8 drop and the bug are not linked by any evidence reviewed here.
AMBCrypto reported that XRP sentiment stayed at a “greed” level with the token above $1.30 and that the bug news had not changed it. The same outlet put XRP’s market value at about $94 billion when the flaw was found in late September, which is the scale an unpatched exploit would have threatened. That figure describes exposure. It does not describe a market response. ambcrypto
Price data from a few days cannot isolate one news item from sector-wide moves. This article makes no claim that the bug raised or lowered XRP’s price, and it offers no price forecasts.
The 3.4.1 release also carried a separate amendment, fixBatchV1_2, for a different flaw in the Batch feature. It was enabled on Mainnet on Oct. 9. Servers not running 3.4.1 or newer are now amendment blocked and cannot stay in sync. That deadline applies to people running servers, such as validators, exchanges, and infrastructure providers. The Batch issue and why it posed no supply risk are covered in the FAQ below.
The patch closes one flaw. It does not remove the conditions that allowed it to survive. Each risk below is labeled by how well the evidence supports it.
| Risk | Classification | Mechanism |
| Other unchecked arithmetic in legacy code | Emerging risk | The report says other places that sum balances across accounts were hardened as a precaution, though none was reachable by a real transaction. |
| Emergency-patch precedent | Confirmed governance question | A fix bypassed validator voting for the first time. Critics argue it exposes reliance on a small coordinating group. |
| Cheaper discovery for attackers | Emerging risk | If AI lowers the cost of finding old bugs, as Liao argues, the same tools reach attackers. |
| Past exploitation not fully excluded | Confirmed limitation | “No evidence” describes what investigators found. It is not proof that nothing happened. |
| Incomplete earlier fix | Confirmed | The Batch finding was first rated low severity in an audit contest and believed fixed, then found incomplete during re-verification. |
| Mixed-version consensus risk, Sept. 25 to Oct. 9 | Confirmed, now past | Servers on different versions could have disagreed on an exploit transaction. |
The last two rows deserve attention. The Batch history shows that a “fixed” label can be wrong. RippleX responded by adding a re-verification step: every security finding marked fixed is re-tested against the release candidate and closed only when a test reproduces the original issue.
The scenario that would worry a risk analyst did not happen. A researcher with a bounty incentive found the XRP Ledger bug, not someone who would have used it. That outcome depended partly on luck, on a bounty large enough to attract skilled attention, and on validators who upgraded blind. None of those is guaranteed next time.
First, the 3.4.1 source is now public, so outside reviewers can check the fix and the “wider counter” now used by the supply invariant. Second, the re-verification step will be tested by the next security release. Third, RippleX has said it will review long-standing code in the payment engine, consensus, and peer-to-peer layers, and push formal verification. Independent reporting of those plans comes from Korean outlet Block Media, so look for the actual disclosure reports as they appear.
For anyone tracking the XRP Ledger bug story, the useful signal is not price. It is how many dormant flaws the next audits find in old code, and how the ledger’s disclosure reports describe them.
No losses have been reported. XRPL developers say they found no evidence the payment engine flaw was exploited on any public network, and RippleX reproduced the minting only on a local standalone server and in unit tests.
That statement comes from the Oct. 9 report and reflects what investigators found as of that date. The separate Batch bug also affected no Mainnet funds, because the feature had not activated.
The upgrade requirement applies to people who run XRP Ledger servers, which must be on xrpld 3.4.1 or newer to stay in sync. The report does not tell ordinary holders to take any action.
Holders on exchanges or wallets rely on those providers’ servers being upgraded. The report addresses the network software, not individual accounts.
The payment engine flaw could have created spendable XRP on the live network. The Batch bug was a validation gap in a feature not yet active on Mainnet, and it threatened network liveness and data parsing, not supply.
The Batch issue was reported on Sept. 18, 2026. It let an inner transaction be wrapped in a non-standard field. The report says an attacker would gain nothing on-chain, though the malformed record could break off-chain indexers and SDKs. Validators pulled their votes on BatchV1_1 to reset its activation clock, and fixBatchV1_2 and BatchV1_1 both activated on Oct. 9.
According to the disclosure report, the real cost was a few hundred XRP in account and offer reserves, which are returned when the objects are removed, plus ordinary transaction fees.
The attacker needed hundreds of deliberately mispriced offers and one payment built to consume them all. The very large numbers in the attack were what offer owners received, not what the attacker had to hold at the start.
What changes if Democrats flip the House? Explore crypto regulation shifts, subpoena risks, 7 key Senate races, and December Fed rate hike pressure.
Read article
The OCC stablecoin rule is finalized. Analyze the GENIUS Act final rule, stablecoin issuer requirements, rewards scrutiny, and the January 2027 effective date.
Read article
Explore an institutional analysis of the CLARITY Act stall, SEC innovation exemptions, CFTC rulemakings, and structural crypto market risks.
Read article
The CLARITY Act failed Senate advancement. Analyze why the crypto market structure bill fails, the market's "shrug it off" reaction, and the new regulatory pivot.
Read articleDisclaimer: This article is provided for informational and educational purposes only and does not constitute financial, legal, or investment advice. It contains no buy/sell recommendations of any kind. Readers should conduct their own research and consult a qualified professional before making any financial decisions.