Here’s a number I’ve been chewing on since the news broke: 100,000,000,000. That’s the entire XRP supply, created all at once when the ledger launched in 2012. The software is built so that no more can ever be added. “Fixed supply” isn’t a marketing line for XRP the way it is for Bitcoin’s 21 million cap — it’s a hard rule, the kind of rule institutions underwrite against when they build on the network.
Now ask the question nobody likes to ask: what, exactly, enforces that rule?
Not a mathematical proof. Not a consensus vote. Not Ripple’s word. It’s enforced by a chunk of C++ in the payment engine — a chunk that, until last month, had a bug in it. A bug that let a single transaction create XRP out of thin air. A bug that had been sitting there since 2015.
That gap between “the promise” and “the code that keeps the promise” is the whole story. Let me walk you through it the way I wish someone had walked me through it — by reading the mechanism, not the headline.
The promise, stated like a spec
The XRP Ledger’s deal with the world is simple to say and brutal to implement: the total supply is 100 billion, it was fully created at genesis, and no operation — no payment, no trade, no nothing — is allowed to make that number go up.
To enforce it, the ledger runs a check after every transaction. It adds up all the XRP across all accounts and asks: did any new XRP appear? If the answer is yes, the transaction is rejected. This check is the entire security model for “no inflation.” One function. One invariant.
The 2026 exploit didn’t defeat that invariant by being cleverer than it. It defeated it by making the invariant’s own arithmetic wrong.
The attack, read line by line
Here’s the mechanism, and it’s genuinely worth understanding because it’s so boring — no zero-days, no private keys, no 51% attacks.
The XRP Ledger has a built-in order book. Accounts post offers — “I’ll trade X amount of this for Y amount of that.” An attacker opens hundreds of accounts, and each one posts a deliberately mispriced offer: a tiny sliver of some token, asking for an absurdly large amount of XRP in return.
Then the attacker sends one payment that buys every single one of those offers at once.
And here’s where the integer overflow bites. The total amount of XRP the buyer “owes” across all those offers is so large that the software can’t count it correctly. The number wraps around. So the seller accounts get credited in full — while the buying account is debited almost nothing.
The difference? XRP that didn’t exist before. Minted from a counting error.
// What the payment engine was supposed to do
buyer_balance -= total_owed; // must equal sum of all offers
seller_balance += offer_amount; // each seller paid in full
// What the integer overflow actually did
buyer_balance -= wrapped_number; // near zero: the sum overflowed
seller_balance += offer_amount; // sellers still paid in full
// -> new XRP appears in the seller accountsThat’s it. No exploit “against” the ledger. The ledger did exactly what its code said — the code was just wrong about how much money was moving.
Why the safety net missed it
Here’s the part that actually bothers me, because it’s the part that generalizes.
The ledger has two safeguards against exactly this, and both failed. The post-transaction supply check — the “did new XRP appear?” function — used the same overflowed arithmetic as the payment. It added up a number that had already wrapped around, so the check saw a clean total and waved the transaction through.
And there’s a second limit: a cap on how much XRP a single account can receive. That one worked fine. The attack just didn’t care — it spread the newly-minted XRP across hundreds of accounts, so no single account tripped the limit.
The lesson isn’t subtle: a check that shares the same broken arithmetic as the thing it checks is not a check. And a per-account limit is not a supply limit. Two safety nets, both technically present, both bypassed by the same misdirection.
The whole thing cost the attacker almost nothing to attempt — a few hundred XRP to open the accounts and cover reserves (most of it recoverable), plus transaction fees.
100000000000 — XRP the fixed supply cap the bug could have silently broken
The fix — and the argument it started
The bug was reported on September 22 through the ledger’s bug-bounty program by researcher Cayden Liao and Veria AI. RippleX reproduced the attack on a standalone server and confirmed the freshly-created XRP could be spent in a later transaction — which is the difference between a curiosity and a catastrophe. The patch shipped in xrpld 3.4.1 on September 25, quietly, without saying what it fixed. No evidence anyone exploited it on a public network.
And that quietness is where the second argument began. The patch was delivered as closed-source code, which prompted exactly the reaction you’d expect. Justin Bons, the cyber-capital founder who’s spent years arguing XRP isn’t as decentralized as it claims, called the closed fix “fraud” — his argument being that you can’t simultaneously claim a trustless, permissionless ledger and then ship a security patch nobody can independently verify. Avalanche’s founder went further, pointing out that AI tools are about to make these decade-old bugs much easier to find — and that open-source audit trails are the only defense.
I’m not going to adjudicate the decentralization fight here. But the closed-source patch is worth sitting with, because it cuts to the exact point I opened with: if the enforcement of “no inflation” is just code, then whoever controls the code controls the promise.
What this actually teaches you
This bug joins a strange little run of long-hidden crypto flaws surfacing with AI help — the Coldcard wallet bug behind the theft of at least 1,367 BTC, the Core Lightning vulnerabilities that forced node operators to disconnect. The pattern is the same: old code, high stakes, nobody looking, until a tool made looking cheap.
But for XRP specifically, I’d frame it differently. The headline “bug could have minted billions” is scary, and it’s also not quite the point. The point is subtler and more useful: “fixed supply” was never a property of XRP the way “21 million” is a property of Bitcoin’s code. It was an invariant that one function had to uphold — and for ten years, that function had a hole in it.
So here’s what I’d actually keep from this:
- Treat “fixed supply” as a claim about code, not a law of nature. Every asset’s supply cap is only as real as the function that enforces it — and functions rot.
- Distrust checks that share arithmetic with the thing they check. If the supply check and the payment logic can overflow together, they’re one bug, not two.
- Demand an open patch trail for anything you hold. A closed-source security fix is a governance event, not just a code event — it tells you who actually holds the keys to the invariant.
The XRP Ledger got lucky this time: the bug was found by a researcher, not a thief. But “lucky” is a terrible foundation for a monetary promise. The next ten years of crypto security won’t be won by writing better invariants. It’ll be won by making sure someone is actually reading them.
(The End)
XRP Ledger payment-engine overflow reported Sept 22, 2026 by Cayden Liao and Veria AI; patched in xrpld 3.4.1 on Sept 25, 2026 (affects 3.4.0 and earlier). Attack mechanics and RippleX reproduction per CoinDesk, KuCoin and TokenPost reporting. Bug dated to a 2015 code change in the payment engine. No evidence of public-network exploitation found.
