{"slug": "we-prevented-the-biggest-hack-in-crypto-history", "title": "We Prevented the Biggest Hack in Crypto History", "summary": "Veria AI's agent discovered an infinite-mint vulnerability in the XRP Ledger, the blockchain created by Ripple in 2012, that could have let anyone create 18 trillion XRP in a single transaction — 184 times the 100 billion token supply — putting the network's $94B market cap at risk, more than 60 times the largest crypto hack on record (Bybit, $1.5B). Veria AI reported the bug through XRPL's bug bounty program on Sept 22, the fix was merged Sept 23 and released Sept 25 with over 80% of validators upgraded, and XRPL skipped its multi-week validator amendment process for the first time in more than ten years to ship the emergency fix. Veria AI received the program's maximum $250,000 bounty, which it says is the largest ever paid for a vulnerability discovered entirely by an AI agent.", "body_md": "# How We Prevented the Biggest Hack in Crypto History\n\n[Cayden](https://verialabs.com/authors/cayden)\n\n[#bug-bounty](https://verialabs.com/tags/bug-bounty)\n\n[#crypto](https://verialabs.com/tags/crypto)\n\nHow Veria AI found an infinite mint in the XRP Ledger that put $94B at risk\n\nLast month, our AI discovered a vulnerability that let anyone mint infinite XRP.\n\nXRP is the fifth-largest cryptocurrency, bigger than Solana and USDC, with a $94B market cap. The XRP Ledger it runs on was created by Ripple in 2012, which makes it one of the oldest blockchains.\n\n## $94 Billion at Risk\n\nXRP launched with a fixed supply of 100 billion tokens. You can’t mine or stake on the network, and each transaction burns a small fee, so the supply should only ever go down.\n\nThe bug we found let anyone create 18 trillion XRP with a single transaction, 184 times the total supply.\n\n**That put the full $94B at risk, more than 60 times the largest crypto hack on record (Bybit, $1.5B).**\n\nTo our knowledge, no whitehat has ever found a bigger vulnerability. The previous record we know of was a 2021 bug in Polygon that put $24B at risk.\n\n## A Decade-Old Bug\n\nThe bug had been live on the XRP Ledger for nearly a decade, in code written in 2015 and 2017.\n\n**This is one of the most heavily reviewed codebases in crypto.** The XRP Ledger has paid out well over $1M in bug bounties and has had more than a dozen audits and audit contests since 2024 alone, including one contest with a $550K prize pool.\n\nWe suspect one reason nobody caught it is that it chains together two bugs that are harmless on their own. The first lets a payment charge almost nothing while paying out trillions. The second is in the safety check meant to catch exactly that, and it breaks in the same way.\n\n## How Our AI Found It\n\nWe pointed our agent at `rippled`, the software that runs the XRP Ledger. It found both bugs, worked out how to chain them together, and built a working exploit on a local network to prove it.\n\nIt flagged the bug at 11 on a Monday. I didn’t believe it, so I read through the proof of concept three times.\n\nBy 4am I still couldn’t find anything wrong with it, so I woke up our founding engineer to go through it with me. Vulnerabilities directly affecting $94B don’t come along often, and neither of us could believe one had been sitting in the XRP Ledger for nearly a decade without anyone noticing.\n\n**By morning we were sure it was real.**\n\nThe Veria agent hunts not only for the highest-impact bugs, but also for how lower-severity vulnerabilities can be chained into something much worse. After we disclosed this one, we pointed general-purpose coding agents directly at the vulnerable code, and they still couldn’t find it.\n\n## Patched in Three Days\n\nWe reported it through XRPL’s bug bounty program, and their team moved quickly.\n\n- **Sept 22:** reported and confirmed the same day\n- **Sept 23:** fix merged\n- **Sept 25:** fix released, with over 80% of validators upgraded\n\nNormally, changes to how the XRP Ledger processes transactions go through an amendment process, where validators vote on the change over several weeks.\n\n**For the first time in the more than ten years since that process was introduced, XRPL skipped it and shipped an emergency fix.** As their [disclosure report](https://xrpl.org/blog/2026/vulnerabilitydisclosurereport-bug-20261009) put it, “an attacker could have created spendable XRP far beyond the total supply in a single validated transaction.”\n\nRippleX found no evidence that the bug was ever exploited. We thank the XRPL team for their quick response and triage.\n\n## The Largest AI Bug Bounty\n\nWe were awarded **the maximum $250,000 bounty** offered by XRPL’s bug bounty program. To our knowledge, that’s the largest ever paid out for a vulnerability discovered entirely by an AI agent.\n\n## AI Cuts Both Ways\n\nEarlier this summer, an attacker drained 1,367 BTC ($89M) from Coldcard wallets through a bug that had been sitting in the firmware for five years, and Coinkite suspects AI helped find it.\n\n**AI is making old bugs much cheaper to find, and attackers have access to the same tools you do.** Even a codebase as heavily audited as the XRP Ledger had a critical vulnerability hiding in it for a decade.\n\n**Fortunately, there are far more good hackers than bad ones.** This bug was found by people who reported it, and the XRPL team fixed it before anyone could use it. As long as defenders adopt these tools as fast as attackers do, the good guys have the upper hand.\n\nThe rest of this post is the technical deep dive: how the two overflows work, how they chain together, and how the fix closes them.\n\n## Technical Deep Dive\n\n### Background: XRP and the DEX\n\nXRP is divisible into one million “drops,” much like lamports in Solana:\n\nAll 100 billion XRP were created in the genesis ledger, and no transaction is supposed to create more. The open source [rippled](https://github.com/XRPLF/rippled) codebase implements the entire chain: transaction processing, consensus, ledger storage, and RPC interfaces.\n\nXRPL also supports issued currencies called IOUs. An IOU represents an obligation from an issuer in a currency code. Anyone can issue one, and IOUs trade against XRP on XRPL’s built in decentralized exchange (DEX).\n\nThat DEX ends up being the attack path which turns attacker issued IOUs into an infinite XRP mint.\n\n### Background: Offer Processing and the BookStep Conversion\n\nCross-currency payments can consume offers from the DEX. Internally, the payment engine models each order-book conversion as a `BookStep`.\n\nFor example, a payment may spend XRP, consume offers selling an issued USD token, and deliver that USD to the destination. When several offers have the same quality (exchange rate), `BookStep` aggregates their inputs and outputs.\n\nThe implementation limits an individual `BookStep` traversal to 1,000 offers.\n\n### Background: Transaction Invariants\n\nAfter a transaction is applied, `rippled` runs invariant checks before committing the result. If any check fails, the transaction’s changes are thrown away.\n\nOne of these checks is the `XRPNotCreated` invariant. It walks every ledger entry the transaction modified and adds up the net change in native XRP. For any valid transaction, that net change must be exactly the negative of the fee:\n\nA positive result would indicate that a transaction created XRP, and it is rejected.\n\nA separate invariant, `XRPBalanceChecks`, prevents an individual account from holding more than the original 100 billion XRP supply.\n\nThe `BookStep` aggregation code was written in November 2015, and the `XRPNotCreated` invariant in February 2017. To put that into perspective, Ethereum launched in July 2015 and Solana in March 2020.\n\n### Overflow #1: Integer Overflow in BookStep\n\nWhen a payment crosses an order book, `BookStep` doesn’t settle each offer in isolation. As it walks the offers in a strand, it accumulates their inputs into a running multiset and collapses it into a single total.\n\nwhere `result.in` is the total amount the source account is ultimately charged.\n\nNotice the `sum()` function. This is the helper function that `BookStep` uses to sum a collection of amounts:\n\nWhen the collection contains `XRPAmount` values, `std::accumulate` calls `XRPAmount::operator+=`. The underlying value is a signed 64-bit integer:\n\nThe addition does not check whether the result still fits within the signed 64-bit type.\n\nThis means that if a single `BookStep` traversal consumes enough offers whose combined XRP input exceeds the signed 64-bit range, the accumulated total wraps around to a small value.\n\nThe offers themselves are settled one at a time, inside `consumeOffer`, each at its own true input amount:\n\nSince the aggregate amount is essentially ignored in this path, each offer owner is credited `ofrAmt.in`, the full unwrapped amount their offer asked for.\n\nSigned integer overflow is undefined behavior in C++, so whether this crashes or silently wraps depends on how the binary was built. We tested this against the official release binary and confirmed that the overflow wraps silently, with no crash.*\n\n**Notably, had `rippled` been built with overflow trapping (for example, `-ftrapv`), this bug would have become a node crash (DoS) instead.*\n\n### Overflow #2: XRPNotCreated\n\nOverflowing `BookStep` creates XRP out of thin air, but this should never survive to a committed ledger. The `XRPNotCreated` invariant exists precisely to catch it.\n\nUnfortunately, its accumulator is also a signed 64-bit integer, and the invariant checks the *accumulated* total rather than individual state changes:\n\nAs the invariant walks the modified entries, `visitEntry` subtracts each account’s balance before the transaction and adds its balance after:\n\nOnce every entry has been visited, `finalize` checks that the net change is exactly the fee that was destroyed and nothing more:\n\nIn a normal transaction this is fine. The only XRP that should disappear is the fee, so `-drops_` must equal `fee.drops()`, and anything positive means XRP appeared from nowhere.\n\nBut `drops_` accumulates the real balance changes. When a payment credits enough accounts that their gains sum past the signed 64-bit bound, `drops_` overflows. Because the invariant operates over the entire transition, the true net change, an enormous positive number, folds back down to a negative value that looks like a fee burn.\n\nSo `finalize` sees a net change of roughly `-fee` and lets the transaction through.\n\n### Chaining the Two Primitives\n\n`BookStep` by itself can mint XRP, but `XRPNotCreated` rejects any transaction that creates XRP, so the mint never commits. And the `XRPNotCreated` overflow by itself is unreachable.\n\nThe goal was to chain both primitives together. Conveniently, both have the same type of overflow: `result.in` in `BookStep` and `drops_` in `XRPNotCreated` are both signed 64-bit integers.\n\nIf an attacker can choose the credits so that their total lands on a multiple of , then *both* accumulators wrap by the same amount.\n\n#### Constructing the Transaction\n\nThree constraints shape the transaction:\n\n- **Clean wrap** : Both sums are modulo , so  offers of  drops with  a power of two can land  exactly on a boundary.\n- **Per account cap** : Each maker is credited its real amount, bounded by 100 billion XRP (`kInitialXrp` drops ), so each offer is at most  drops.\n- **Strand limit** :`kMaxOffersToConsume` caps one traversal at 1,000.\n\nPutting these together gives 256 offers of drops:\n\nThe keeps the total off exactly (which wraps to 0), so it wraps to a usable 256 drops instead.\n\n#### Hitting Both Primitives\n\nThe same flows through each overflow:\n\nThe buyer is charged 256 drops, the 256 makers collectively receive drops of real XRP, and the invariant sees only a fee burn and commits the ledger.\n\nIn summary:\n\n1. Set up 256 offers: Issue a worthless token with 256 offers, each selling for drops of XRP.\n2. `BookStep` overflows the charge:`sum(savedIns)` wraps  down to 256 drops.\n3. `XRPNotCreated` overflows the check: The net change of  wraps to  and passes.\n4. Ledger commits: The invariant passes, and the minted XRP is written to the XRP Ledger.\n\n### Impact\n\nOne successful trigger credits the maker accounts with:\n\nAfter accounting for the source debit and fee (which are negligible next to the amount created), that is 18.45 trillion XRP spread equally across 256 accounts.\n\nThe 100 billion cap is still enforced per account. All 18.45 trillion XRP is spendable, but it has to stay spread across separate accounts so that no single account exceeds the cap.\n\nThe setup requires about 256 funded accounts, but it does not require the attacker to operate a validator or have any special access. Once submitted, it is processed as an ordinary signed transaction. Because the setup can be recreated with additional accounts, the attack is repeatable, so an attacker could mint an unbounded amount of native XRP, 18.45 trillion at a time.\n\nAn attacker could never have sold that much XRP at market price, so the real exposure is the value of every existing XRP: the full $94B market cap.*\n\n**At XRP’s price of $1.59 at the time, 18.45 trillion XRP would have a notional value of roughly $29 trillion.*\n\n### The Fix\n\nThe fix shipped in [`rippled v3.4.1`](https://github.com/XRPLF/rippled/releases/tag/3.4.1):\n\n- Adds an overflow check when `BookStep` sums offer amounts, so a sum that would overflow now fails cleanly instead of minting anything.\n- Widens the `XRPNotCreated` accumulator so the net change can no longer wrap around to look like a fee burn.\n- Hardens balance summation in other code paths.\n\n## Timeline\n\n- 09/21/2026 - Veria AI is run on rippled and identifies the infinite mint\n- 09/22/2026 - Veria AI builds a working PoC of the infinite mint on localnet\n- 09/22/2026 - Cayden validates the PoC and confirms the bug is reachable on mainnet\n- 09/22/2026 - Infinite mint reported through XRPL’s bug bounty program and confirmed the same day\n- 09/23/2026 - Fix merged\n- 09/25/2026 - `rippled v3.4.1` released as an emergency fix, with over 80% of validators upgraded\n- 10/08/2026 - Veria AI is awarded the maximum critical bounty of $250,000\n- 10/09/2026 - XRPL publishes its disclosure report\n\n## About Us\n\nAt Veria Labs, we build AI pentesting agents that automatically find and fix security vulnerabilities in your application. Founded by members of the #1 competitive hacking team in the U.S., we work with teams like Phantom, Tempo, and Provable to find bugs like this before attackers do.\n\nThink we can help secure your systems? [Get in touch](https://verialabs.com/contact).\n\n## PoC\n\nAll files related to the PoC can be found in this GitHub gist:\n\n[https://gist.github.com/SuperBeetleGamer000/131515ad1965a67c6f210aa7dedce67d](https://gist.github.com/SuperBeetleGamer000/131515ad1965a67c6f210aa7dedce67d)", "url": "https://wpnews.pro/news/we-prevented-the-biggest-hack-in-crypto-history", "canonical_source": "https://verialabs.com/blog/biggest-hack-in-crypto-history/", "published_at": "2026-10-11 02:57:33+00:00", "updated_at": "2026-10-11 03:20:41.533209+00:00", "lang": "en", "topics": ["ai-agents", "artificial-intelligence"], "entities": ["Veria AI", "XRP Ledger", "Ripple", "XRP", "RippleX", "Bybit", "Polygon", "Coinkite"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/we-prevented-the-biggest-hack-in-crypto-history", "markdown": "https://wpnews.pro/news/we-prevented-the-biggest-hack-in-crypto-history.md", "text": "https://wpnews.pro/news/we-prevented-the-biggest-hack-in-crypto-history.txt", "jsonld": "https://wpnews.pro/news/we-prevented-the-biggest-hack-in-crypto-history.jsonld"}}