The XRP Ledger Foundation has published a detailed explanation of the recent security bug that raised concerns over whether additional XRP could have been created and whether the way the issue was fixed undermined the network’s decentralization.
The Foundation says no extra XRP was created.
It also confirmed that the vulnerability was fixed in version 3.4.1 and said the current supply remains about 99.986 billion XRP.
The announcement quickly fed into a wider debate around XRPL security and decentralization, with pro-Ripple lawyer Bill Morgan pushing back against critics who argued that the private coordination behind the fix raised centralization concerns.
What you'll learn 👉
XRP Ledger Foundation Says No New XRP Was Created
The Foundation said XRP’s supply was fixed at 100 billion when the ledger launched and that the bug created a potential way around that rule.
However, it stressed that no extra XRP was actually issued.
Because XRPL balances are public, any newly created tokens would have appeared on-chain and could have been tracked by explorers and data platforms.
The Foundation said it monitors the ledger continuously and verified that supply remained intact throughout the network’s history.
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
It also pointed out that transaction fees are burned, meaning total XRP supply gradually declines over time.
The bug itself was unusual.
The Foundation said a normal payment would not come close to triggering it. Exploitation would have needed hundreds of deliberately constructed operations.
That is one reason the issue managed to remain unnoticed for so long.
Why the Fix Was Handled Privately
The more controversial part of the story is how the patch was deployed.
The Foundation explained that publicly revealing the vulnerability before the fix was ready could have exposed the ledger to attackers.
With AI making it easier to analyze code and identify weaknesses, the risk of publishing details too early was considered significant.
The XRPL Foundation, RippleX, core developers and validators therefore coordinated privately before releasing the fix.
Version 3.4.1 was first shared with validators on the default UNL, followed by public binaries later the same day.
The Foundation stressed that no single party could force the upgrade.
The version only became required after the usual amendment process received more than 80% validator support for two weeks.
Going forward, XRPL plans to expand formal verification, AI adversarial testing, security research collaboration and its bug bounty program.
Read also: Here’s Where XRP Price Could Go This Week (October 12-18)
Bill Morgan Pushes Back at Centralization Claims
Bill Morgan took a much stronger tone.
He said he had grown tired of critics using the bug and the way it was fixed as evidence that XRPL is centralized.
I have grown very tired very quickly hearing from bad actors who hate the XRPL about the bug that could’ve caused XRP to be created and the manner in which the problem was fixed being used to cast shade on whether the XRPL is centralized. That can be viewed in the context of a decade long campaign of people outside the XRP community to attack the decentralization credentials of the XRPL. But I want to turn it around and ask what does this say about the definition of decentralization of these critics. If decentralization means that people with the expertise in a community cannot come together and privately fix a serious bug that could do damage to the ledger, because going public before the problem is fixed gives an opportunity for bad actors to exploit the vulnerability, then what is your definition of decentralization. It can’t be anarchy or chaos. That is not going to attract any investors, retail or institutional. In any event, the manner in which the problem was solved does not bear on the concept of decentralization in my opinion. It bears on the issue of security vs. disclosure. The solution was disclosed publicly after it was implemented. It was not disguised. People who have the expertise and who are good faith actors fixed the problem before bad actors could exploit it. What is the problem?
— bill morgan (@Belisarius2020) October 12, 2026
Morgan argued that the situation should instead be viewed as a security-versus-disclosure issue.
His point is simple: if knowledgeable members of a decentralized community cannot privately coordinate to fix a dangerous vulnerability before attackers can exploit it, then the definition of decentralization being used is impractical.
He also stressed that the fix was disclosed publicly after deployment and was not hidden permanently.
That distinction is important.
Private coordination around an emergency security fix does not automatically mean one entity controls the network.
The stronger test is whether one party could independently impose protocol changes.
In this case, validators still had to adopt the software, and the amendment process still needed more than 80% support.
For more crypto news and price predictions, click here.
Subscribe to our YouTube channel for daily crypto updates, market insights, and expert analysis.
