How one payment could have minted XRP past the 100B cap

BYDFi explains the XRP Ledger overflow bug, the 3.4.1 patch and the skipped vote

By Alexander F., Portfolio Manager @ LiquidityFlow.ioUpdated 2026-10-31

Key takeaway

BYDFi's Market Intelligence desk wrote up the XRP Ledger bug that was disclosed on Oct 9 and patched in xrpld 3.4.1. In short: a payment could have charged the buyer a few hundred drops and credited sellers with trillions of XRP, and the ledger's own checks would have let it through.

Official BYDFi Market Intelligence art for its XRP Ledger bug story: a silver XRP coin with a wrench, blue shield, cracked gears and stacked gold coins. — Image: BYDFi official article image, as used in the original post.

Developers say they found no evidence it was ever exploited on a public network.

The image is the official BYDFi Market Intelligence art for the story.

The bug in plain English

The ledger counts XRP in drops, and one XRP is a million drops. The full 100B supply is about 100 quadrillion drops, far under the ceiling of a 64-bit number. When a payment ran through the built-in order book, though, the engine added up every offer at the best price with plain 64-bit addition and no overflow check. Stack a few hundred absurdly priced offers and the total runs past the ceiling, then wraps around to a tiny number, like an odometer rolling over. Sellers get credited in full, the buyer pays the wrapped amount, and the difference is newly minted XRP.

No real trader would ever touch offers priced like that, so normal payments never reached this code path.

Why the two safety nets missed it

The "no XRP created" invariant added up balance changes with the same unchecked 64-bit math, so it wrapped too and the result looked like an ordinary fee.
The per-account guard only trips if one account holds more than the total supply. Spread the minted coins across hundreds of accounts and none crosses the line.

Timeline (2026)

Sept 22: reported through the bug bounty and raised to critical
Sept 23: fix merged
Sept 25: xrpld 3.4.1 released, with over 80% of default-list validators running it
Oct 9: public disclosure and source published

The governance part

Rule changes on the XRP Ledger normally go through an amendment that needs more than 80% validator support for two weeks. Because open-source code shows the bug the moment the fix ships, developers skipped that vote and pushed it as a direct change. This is reported as the first deliberate bypass for a transaction-processing change. The trade-off: while servers ran mixed versions, an exploit attempt could have split or halted the network. Critics say the "protect first, disclose later" approach weakens decentralization.

Official vs claimed

Official (XRPL report): the overflow mechanism, the dates, the fix, no evidence of exploitation
Researcher or company claims: about 18.45T XRP mintable in one transaction (roughly 184x supply), a $250,000 maximum bounty, and an AI agent finding the flaw

What it means for holders

The upgrade requirement is for server operators. Servers below 3.4.1 are now amendment blocked because a separate Batch fix was enabled on Oct 9. Ordinary holders aren't asked to do anything. The article makes no price call and links no price move to the bug.

The thing to track is how many more dormant bugs the promised audits of old payment, consensus and networking code turn up.