XRP Foundation Explains Its Emergency Fix for Critical Bug
XRP Ledger Foundation has answered the questions raised by the recent payment-engine flaw: whether XRP was created, why the patch came before a full disclosure and who chose to install it.
Key Takeaways
- XRPL says no XRP was created through the flaw.
- Public ledger data allows supply and transaction history to be checked.
- Validators installed the emergency patch before the technical disclosure.
- Formal verification and stronger security testing are planned next.
The Foundation is explaining the response, not reopening the exploit
The recently disclosed flaw could have allowed an attacker to create spendable XRP through a deliberately constructed payment. The more useful question after that disclosure is how a public network handled a critical risk without leaving the exploit visible for weeks.
XRPL Foundation’s October 11 statement focuses on that response: the recorded supply, the accelerated software rollout and the safeguards it plans to strengthen. Readers looking for the mechanics of the vulnerability can find them in our earlier explanation of the XRP Ledger bug that could have created spendable XRP.
How the response unfolded
A bug-bounty report reached the engineering team.
xrpld 3.4.1 was released; more than 80% of default-UNL validators were running it.
XRPL published its full vulnerability disclosure report.
The supply claim can be checked against the ledger record
The Foundation said no XRP was created through the flaw. XRP began with a fixed 100 billion supply, while transaction fees are destroyed over time; the Foundation put the remaining amount at about 99.986 billion XRP.
Its technical disclosure report goes further, saying the team found no evidence that the flaw had been exploited on a public network. That finding can be assessed against the ledger’s validated transaction history and account balances, which are available for independent review.
“You don’t need to trust us on this,” the Foundation wrote, pointing to public ledger data and external explorers.
Public records have limits, however. They can show what was validated on-chain, including visible balance changes and transactions. They cannot identify every private conversation before disclosure or prove the intent behind an unsubmitted attack. The record is still enough to challenge the claim that large amounts of XRP were secretly minted and left hidden on the network.
Why the technical details followed the patch
Under XRPL’s normal governance process, transaction-rule changes are introduced through amendments. Validators must maintain more than 80% support for two weeks before a new rule activates, giving operators time to upgrade while ensuring the network changes at the same point.
The overflow fix followed a different path because the risk was already live. The disclosure report says that releasing code showing the exact flaw would have made the attack route easier to identify while older servers could still accept it. Version 3.4.1 therefore applied the protection as each server upgraded, instead of waiting through the public amendment process.
The recent XRP Ledger security fix raised a lot of questions and some misconceptions. Let’s clear them up.
1. Was any XRP created?
No. XRP’s supply was fixed at 100 billion when the XRP Ledger launched, and no transaction is allowed to create more. This bug was a way around that rule, and 3.4.1 fixed it 2 weeks ago.
You don’t need to trust us on this. All ledger data is public, and explorers and data sites read it every day. New XRP would show up in account balances for everyone to see. There is no hidden place for XRP on the XRP Ledger, every balance is public.
We monitor the XRP Ledger 24/7 and have verified the supply throughout the history of the ledger. Others in the community verified this too, and anyone can do the same.
Transaction fees are destroyed, so the supply is deflationary. About 99.986 billion XRP exist today.
2. How did this go unnoticed, and what’s next?
No normal payment comes anywhere near triggering it. It took hundreds of deliberately constructed operations.
AI makes bugs like this faster to find, for the bad guys and the good guys.
Together with RippleX and the community, we will ensure the XRP Ledger is protected against such vulnerabilities. This means radically applying Formal Verification and AI adversarial testing, collaborating closely with security researchers, and strengthening the bug bounty program.
You’ll hear a lot more about this as we progress.
3. XRP Ledger decentralization at the core of this.
A public fix shows attackers where the bug is, and AI makes that fast. With a normal amendment vote, the fix would have been public for weeks before it took effect, risking network security.
As a reaction to this, the XRPL community came together, and among them the XRP Ledger Foundation, RippleX, core devs and validators formed a social consensus and agreed on a path forward that involves shipping the fix directly. Patching a live network is never trivial, so the plan was also designed to minimize disruption for everyone running on it.
We shared the build with the default UNL validators, using the contact details each one publishes in its xrp-ledger.toml file. Public binaries followed the same day, September 25.
No single party could make that call alone. Every validator and node operator chooses what software to run, and 3.4.1 only became required through a normal amendment vote with more than 80% validator support for two weeks. Protocol changes still go through amendments.
Big thanks to Cayden Liao and Veria AI for finding and reporting this responsibly, to the XRPL core developers for building and testing the fix, and to every node operator who upgraded so quickly, especially the validators.
Full report: https://t.co/aWxdvthYPt
— XRP Ledger Foundation (@XRPLF) October 11, 2026
XRPL describes that as an exceptional response, not a replacement for ordinary governance. The report says this was the first deliberate direct change to transaction processing since the amendment system was introduced more than a decade ago, and that future protocol changes will continue to require validator-backed amendments.
Validators still decided whether to install the software
The Foundation said it shared the patched build with operators of default-UNL validators before releasing public binaries on September 25. Those operators could decide whether to run the new version; neither the Foundation nor RippleX could force an upgrade across independent servers.
That created a short period in which patched and unpatched servers followed different rules for the specialised payment path. XRPL’s report says an attempted exploit could have caused those versions to disagree, potentially disrupting validation. The team judged that risk preferable to leaving a cheap and potentially irreversible inflation attack open during a longer public activation period.
What the disclosure means in practice
For XRP holders: The report did not call for users to move funds or replace wallets.
For node operators: XRPL says servers should run xrpld 3.4.1 or newer to remain in sync with the network.
The promised security changes need to appear in future releases
The Foundation said it plans to expand formal verification, AI adversarial testing, work with external security researchers and its bug-bounty programme. Those measures cannot guarantee that no critical issue will surface again, but they can improve the odds that flaws are found before a production release.
The disclosure report also sets out a specific release-control step. Security findings marked as fixed should be re-tested against the release candidate carrying the patch, with the original reported problem reproduced before the finding is closed. That creates a standard outside researchers can assess when later releases arrive.
The flaw exposed a serious weakness in a rule meant to preserve XRP’s fixed supply. The response now leaves a public trail of its own: a bug-bounty report, a rapid validator upgrade, a later technical disclosure and a set of security commitments. Whether those commitments become routine release practice will be the more meaningful measure of the incident’s long-term effect.
This article is for informational purposes only and does not constitute investment advice. Software releases and security-disclosure details may change as further technical information becomes available.
Alex is Editor-in-Chief of Coindoo and co-founder of Millennial Media Group, with nearly a decade of experience covering financial markets - crypto first, then everything else. It started in 2016 with Bitcoin. Like most people at the time, he didn't fully understand it - so he kept digging. Blockchain, tokenomics, the projects, the cycles. That curiosity never stopped, and eventually pulled him into traditional markets too: equities, commodities, macro. Not because he left crypto behind, but because you can't properly understand one without the other. What drives him is straightforward: he wants to know why something is happening, not just that it's happening. Most market coverage stops at the headline - price up, price down, here's a chart. Alex finds that kind of reporting actively unhelpful. If you walk away from an article without understanding the mechanism behind the move, what did you actually learn? He holds a degree in Tourism from New Bulgarian University - not the most obvious path into financial markets, but markets have a way of pulling in people who are simply too curious to stay out. He has authored over 200 in-depth analyses and more than 10,000 articles across crypto and traditional finance. He still thinks every day in markets teaches him something new. That's probably why he hasn't stopped.
