The XRP Ledger bug that could have created XRP from nothing: what is actually true

If you have seen posts saying the XRP Ledger had a bug that "could print unlimited XRP," the core of the story is real. A flaw in the ledger's payment code could have created new XRP out of nothing. But it was reported privately, patched within three days, and, according to the official disclosure, never used.

What was disclosed, and by whom

On October 9, 2026, the XRP Ledger developer site published a vulnerability disclosure report covering two bugs fixed in xrpld 3.4.1. xrpld (the program previously named rippled) is the core server software run by XRP Ledger validators and other nodes.

The serious one is labeled "Payment Engine XRP Overflow." The report credits researcher Cayden Liao and Veria AI with finding it and submitting a proof of concept through the XRPL bug bounty program on September 22, 2026. The researchers rated it "Major." RippleX, Ripple's engineering arm, recreated the exploit on an isolated test server that same day, showed the minted XRP could then be sent onward like any other XRP, and raised the rating to critical.

The report says the bug likely dated back to 2015, when the current payment engine was written. So "a vulnerability has existed for a while" is accurate: roughly a decade.

How the bug worked

The XRP Ledger has a built-in decentralized exchange, where anyone can list an offer to trade one asset for another on an order book. A single payment can fill many offers at once, and the software adds up what the buyer owes across all of them.

That running total was stored in a 64-bit integer with no overflow check. Think of a car odometer: push it past its highest reading and it rolls back to a small number. The report describes an attacker setting up a few hundred accounts, each offering a tiny amount of some token in exchange for an enormous amount of XRP. One payment then buys through all of those offers. The total owed overflows and wraps around to a small value. The sellers each receive their full XRP price while the buyer pays only the small rolled-over figure, and the gap between the two is brand-new XRP.

The report says the attack would have cost only a few hundred XRP, tied up as reserves for the accounts and offers and returned once they are deleted, plus normal transaction fees.

Why the ledger's safety checks missed it

The XRP Ledger runs what it calls invariant checks after every transaction. These are a separate set of checks, kept apart from the normal transaction code, that review each transaction's changes before they are saved. Any transaction whose changes would violate a core rule fails and has no effect. One of those rules is "XRP Not Created": a transaction may destroy the small fee it pays, but it must never create XRP.

According to the report, two safeguards should have stopped this attack, and neither did:

• The "no XRP created" invariant totaled the transaction's balance changes using the same unchecked 64-bit arithmetic, so its own sum rolled over too and the transaction appeared to have done nothing more than burn a normal fee.
• The per-account balance check is only triggered when one account's balance goes above 100 billion XRP. Splitting the minted XRP among hundreds of accounts left each one below that ceiling.

The report's explanation for why it went unnoticed so long: everyday payments never involve amounts anywhere near large enough to roll the counter over, so only an attacker deliberately stacking absurdly priced offers would ever hit it.

What "unlimited XRP printed" would and would not mean

The XRP Ledger started in 2012 with its full 100 billion XRP already in existence. There is no mining or issuance. Each transaction destroys a small fee, so the total in existence slowly shrinks below that original figure. An exploit like this would have broken that model by putting new, spendable XRP into ordinary accounts, where it could be spent, swapped or deposited at an exchange.

The report's own wording is that an attacker "could have created spendable XRP far beyond the total supply in a single validated transaction." It does not use the word "unlimited," and it calls the impact critical only if it had been exploited. Here is the reality check:

• True: the bug was real, critical in severity, cheap to attempt and present for about a decade.
• Not true: that XRP was actually printed. RippleX says it found no evidence of exploitation on any public network.
• Not true: that it could be triggered by accident or by normal trading. The report says it required hundreds of offers "priced in a way no real trader would use."

A suggested side effect, using the bad offers to block other people's payments, was tested by RippleX and found not to work in practice.

The fix, and an unusual shortcut

xrpld 3.4.1 shipped on September 25, 2026, three days after the report. It adds an overflow check to the payment engine, so an oversized total now fails cleanly instead of minting anything. The "no XRP created" invariant now uses a wider counter that cannot wrap around, as a backstop against similar bugs elsewhere.

Rule changes on the XRP Ledger normally go through an amendment: the change is built into the software but stays dormant until over 80% of trusted validators have backed it continuously for two weeks. This fix bypassed that vote: each server started enforcing it the moment its operator installed 3.4.1. The report says no transaction-processing change had deliberately bypassed the amendment process like this since that system began more than a decade ago. Its reasoning: anyone can read xrpld's code, so publishing the fix weeks ahead of activation would have pointed attackers straight at a live, working exploit. To limit that exposure, operators received 3.4.1 without its source code, which was published on October 9 together with the disclosure report.

According to the report, over 80% of the validators in XRPL's default Unique Node List (UNL), which is the recommended roster of trusted validators that most servers rely on, had upgraded on the day 3.4.1 came out. The report admits this carried risk: had someone tried the exploit mid-upgrade, patched and unpatched servers could have disagreed, possibly stalling the network, an outcome it considered better than a ledger containing minted XRP.

Not everyone is comfortable with that process. Cyber Capital founder Justin Bons argued that the emergency release, which validators installed before its source code was public, and the default validator lists show a degree of practical control at odds with decentralization, according to TokenPost and U.Today. XRPL's stated position is that anyone can run a validator and choose their own UNL. If you weigh how a network handles emergencies, our guide to evaluating a crypto project covers governance questions worth asking.

What you need to do

• If you hold XRP: nothing. The fix lives in server software, not in your wallet or your XRP balance.
• If you run an XRP Ledger server: the official guidance is to run xrpld 3.4.1 or newer. Older versions can no longer follow the network.

The takeaway

This is a story about a serious bug caught through a bug bounty, not an inflated XRP supply. Even long-running blockchains carry hidden software risk, which belongs in any crypto risk management plan. Details are as of October 2026 and based on the October 9 disclosure report; we will update this post if new information emerges.

Published October 10, 2026 by Dave McNaught. Educational content, not financial, legal or tax advice. Spot an error? Request a correction.

About the author

Dave McNaught

Dave McNaught has worked in IT since 1999 and founded All Business Technologies (ABT) in 2003, a Boston-area firm providing Managed IT, Cybersecurity, Managed AI, Web Design and App Development. He publishes The Crypto Guide.

Full bio