XRP Ledger Bug: Why the Fix Skipped the Amendment Vote

The XRP Ledger had a bug for about 10 years that could have created XRP from nothing, according to a disclosure report the ledger’s team published on October 9. The fix shipped on September 25 in version 3.4.1 without the usual validator vote. The report says it found no evidence the bug was ever exploited on a public network.

For holders, the fixed supply of 100 billion XRP is one of the coin’s core promises. This story tests two things at once: whether that promise held, and who can change the ledger’s rules when something goes wrong. The video also argues that the bigger day-to-day risk sits closer to home, with whoever holds your keys.

What was the XRP Ledger bug?

The XRP Ledger bug was an overflow error in the ledger’s payment engine, the code that matches one person’s order with another’s. According to the video, the payment engine was written in 2015. It added up large XRP amounts without checking for a limit.

The video compares it to the mileage clock on an old car. Push it past the top number and it rolls back to zero. Stack enough large amounts into one payment, and the total could roll over to a tiny number. The sellers would be paid in full, the buyer would be charged the tiny number, and the difference would be brand new XRP.

The report puts it this way: “One payment could have made spendable XRP far beyond the total supply.” Per the video, an attack would have cost only a few hundred XRP.

Why didn’t the safety check catch it?

The ledger’s safety check added up amounts the same way as the payment engine, so the same rollover fooled it. Two years after the payment engine was written, the team added what is called an invariant checker. Its job is to ask one question after every transaction: did this create any XRP?

David Schwartz, one of the XRP Ledger’s original architects, described it in a clip the video plays. If a transaction creates XRP, the checker throws away the result and flags that a rule was broken, “but it does not allow the XRP to be created.” In the same clip, Schwartz said there are probably 20,000 lines of code that could have a bug that creates XRP, which is why the check exists.

The safety net was real. This particular bug got past it because it broke the math the checker relied on.

Was any XRP actually created?

No XRP was created as far as the report can tell. The key line reads: “We have found no evidence that this issue was exploited on any public network.” The video’s view is that the 100 billion figure held.

The video also points out how most people heard about the bug. Social posts said it could “mint unlimited XRP” and drew hundreds of thousands of views, and CoinDesk used the same word. According to the video, “unlimited” does not appear in the report. Most holders heard about the bug roughly two weeks after it had been fixed.

For a closer look at the numbers behind the bug, see the earlier Bullrunners piece on how the XRP Ledger bug could have created 18 trillion XRP.

Why did the fix skip the amendment vote?

The fix skipped the amendment vote because a public vote would have shown attackers where the hole was while it was still open. That is the reason the report gives.

Normally the XRP Ledger changes its rules through amendments. The video plays the XRP Ledger Foundation’s own explainer: at least 80% of validators, the trusted servers that agree on each transaction, must support a change for two straight weeks before it activates. Validators can change their vote during that time.

This fix did not go through that process. It switched on as each server upgraded. According to the video, that is the first time this has been done on purpose in more than 10 years.

The same report covered a second, smaller bug in a new feature called Batch. That fix did get the full treatment. Ripple and other validators pulled their votes to reset the clock, the fix went through the two-week process, and Batch went live on October 9. Bullrunners covered that episode in why Ripple voted no on the Batch upgrade.

	Batch bug	Supply bug
Severity	Smaller	Could create XRP
Went through 2-week vote	Yes	No
How it activated	Amendment vote	As servers upgraded
How it was first described	Named	“Batch fix and stability improvements”

Was it a secret rule change?

Critics called it one, and part of the criticism is accurate. Justin Bons, who runs the crypto fund Cyber Capital, posted that the XRP Ledger had been running closed-source code for two weeks. The video says the report backs that up: validators ran the fix before anyone could read it. The September 25 release notes described it only as a Batch fix and stability improvements.

The video gives the other side. Bitcoin’s developers did something similar in 2018. They fixed an inflation bug as if it were a crash bug, then disclosed the full story two days later to give systems time to upgrade. On the XRP Ledger, more than 80% of the main validators ran the fix on the day it came out. Nobody can force a server to upgrade, and the source code is now public.

The video’s view is that the ledger’s rules are at least argued over in the open. If you want to understand who those validators are, see how the XRP Ledger’s validators and UNL work.

Who found the bug?

An outside researcher, working with an AI security firm, found the bug and reported it through the XRP Ledger’s bug bounty program. A bug bounty pays people to report security holes instead of using them. According to the video, the bug was reported on September 22 and the fix was out within three days.

A contributor to the XRP Ledger Foundation said AI is the biggest threat these days, but also what the team is using to harden the ledger. The video expects more disclosures like this one.

Long-hidden bugs are not unusual in open-source software. The video points to Heartbleed, a flaw in the OpenSSL security software that went unnoticed for close to two years, and to Log4j, which the head of the US cyber defense agency called the most serious vulnerability of her career. The host’s explanation for why these bugs survive is simple: nobody digs through 10-year-old code unless something makes them.

The one check and three decisions

The video ends with a short exercise.

1. Search for “XRPL vulnerability disclosure report” and open the version on the ledger’s own website. Find the “no evidence” line and read it yourself.
2. Open whatever app holds your XRP. If you log in with an email and password, an exchange usually holds the keys. That means its rulebook, not the ledger’s, decides what happens to your coins.

The video’s example is Coinbase. The exchange announced on December 28, 2020 that it would stop XRP trading, and trading stopped on January 19, 2021. Nothing was wrong with the XRP Ledger, but customers could no longer trade XRP where they held it. For more on this risk, see what Coinbase’s terms say about freezing your crypto.

The host then sets out three questions to answer before the next scary headline:

1. Who holds the keys to your XRP when the rules change: you or a company?
2. Is your XRP doing anything while you wait, or just sitting there?
3. When the next headline lands, what is your plan, decided in advance rather than on the day?

What to watch next

Version 3.4.1 is now the minimum version every XRP Ledger server must run, and older servers have been cut off. Watch for more bug bounty disclosures, which the video expects as AI tools speed up code review. Also watch how future fixes are disclosed, and whether release notes name serious issues sooner.

The video also flags Ripple’s Swell conference in New York from October 27 to 29. It will be the first Swell since this report came out, so watch for any comment from Ripple on the bug and the decision to skip the vote.