- Researchers demonstrated that a payment on the XRP Ledger could credit a receiver without the sender funding it. An emergency software release followed.
- The flaw is reported to be around a decade old. No losses have been reported, and nobody has said whether it was ever exploited.
- We could not find a primary security advisory or an on-the-record statement from anyone involved, so this rests on CoinDesk’s write-up.
There is one thing a payment network cannot get wrong, and it isn’t speed or fees. It’s the supply. Researchers have shown the XRP Ledger could be made to create spendable XRP that nobody paid for. A fix has shipped.
A bug that creates units out of nothing doesn’t cost one person money. It costs everyone money at once. If a network can be made to produce coins nobody bought, every coin already held is worth fractionally less, and the fixed supply the asset is sold on stops being a fact about the system and becomes a hope about the code.
Nothing in the reporting suggests that happened. The patch matters because of what was possible, not because of damage done.
What was demonstrated
Strip a ledger back and a payment is two entries that have to agree. One account is debited, another is credited, and the totals match before and after. Everything else, the fees, the consensus, the , exists to make sure those two numbers stay in step.
According to CoinDesk, researchers showed a transaction in which the credit happened and the debit effectively did not. The receiving account ended up with XRP it could spend, drawn from no one. Repeat that at scale and the headline figure of billions of dollars is simple arithmetic rather than hyperbole: once the constraint is gone, there is no natural stopping point.
The code path involved is reported to have existed for roughly ten years. An emergency release went out once the issue was disclosed.
The failure mode that has form
Inflation bugs are rare, and they are also not new. In August 2010, someone exploited an overflow in bitcoin’s code to create 184 billion BTC in a single transaction, against a supply cap of 21 million. Developers shipped a fix and the chain was reorganised within hours, which is the only time bitcoin’s history has been rewritten.
The closer parallel is 2018. Bitcoin Core published what looked like a routine fix for a crash bug, and only later confirmed that the same flaw would have allowed to create coins beyond the cap. Nobody had used it. The quiet disclosure was deliberate, because telling the world how to inflate a currency before the people running it have updated is not a neutral act.
Which is the context the XRP Ledger fix sits in. Mature networks find these things. The question each time is how long the window was open and who else had found it.
A fix only counts once it’s installed
This is where an open network differs from a company pushing an update to your phone. The XRP Ledger runs on independent validators, and nobody can force them to upgrade. A release exists the moment it is published; it protects the network only as operators install it.
The ledger also has a second route for changes, the amendment process, where a feature goes live only after validators have signalled support for a sustained period. That is how the PermissionDelegationV1_1 upgrade activated on 8 October. Security patches typically take the faster route, a new software version that operators apply directly, but both depend on the same thing: the people running the machines actually doing it.
What has not been established
Whether the flaw was ever used in the wild. How much of the validator set was running unpatched software, and for how long after disclosure. Who the researchers were, and whether a bounty was paid. No one at Ripple or the XRPL Foundation appears to have been quoted on the record in the coverage so far.
Our own inference, and it is an inference: the total supply of XRP is a public number anyone can read off the ledger, so units created out of nothing would show up in it. That makes historical exploitation a checkable claim rather than an unknowable one, if whoever shipped the fix chooses to publish the audit. Nobody has said they have.
What to watch
A proper post-incident write-up. The useful version names the version number, describes the condition that triggered the bug, and states plainly whether the chain’s history was examined for signs it was ever triggered. Plenty of networks publish that. Several have built real credibility doing it.
After that, validator uptake. A patch sitting on a download page is not the same as a patched network, and that gap is the only part of this story where the risk is still live. Other technology coverage is in the archive if you want the wider picture.