The XRP Ledger Foundation has explained how developers and validators responded to a vulnerability that could have allowed an attacker to create spendable XRP through a deliberately constructed payment. The Foundation said no XRP was created through the flaw and that there is no evidence it was exploited on a public network.

The October 11 statement focused on the response rather than repeating the mechanics of the vulnerability. An earlier explanation of the bug is available in Coindoo’s report. The Foundation’s technical disclosure report is available on the XRP Ledger website.

Public ledger data supports the supply claim

XRP launched with a fixed supply of 100 billion, and transaction fees are destroyed over time. The Foundation said approximately 99.986 billion XRP currently exist.

The technical disclosure report said the team found no evidence that the vulnerability had been exploited on a public network. The claim can be assessed against the XRP Ledger’s validated transaction history and account balances, which are publicly available for independent review through explorers and other data services.

“You don’t need to trust us on this,” the Foundation wrote. New XRP would appear in account balances, because there is no hidden balance area on the XRP Ledger. The Foundation said it monitors the ledger continuously and has verified the supply throughout the network’s history, while other community members have performed their own checks.

Public records cannot reveal every private conversation before disclosure or establish the intent behind an attack that was never submitted to the network. They can, however, show validated transactions, visible balance changes and the recorded supply. That information provides a basis for challenging claims that large amounts of XRP were secretly minted and left hidden on the network.

Why the fix was released before the technical disclosure

Under the XRP Ledger’s standard governance process, changes to transaction rules are introduced through amendments. Validators must maintain more than 80% support for two weeks before an amendment activates. This process gives operators time to upgrade and allows the network to adopt a change at the same point.

The overflow fix followed a different route because the vulnerability was considered an active risk. According to the disclosure report, publishing code that revealed the precise flaw before older servers were protected could have made the attack path easier to identify. Version 3.4.1 therefore applied the protection as individual servers upgraded instead of waiting for the normal public amendment process.

The Foundation summarized its explanation in an X post:

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.

1. 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.

1. 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:

— XRP Ledger Foundation (@XRPLF) October 11, 2026

The Foundation described the direct software release as an exceptional response rather than a replacement for ordinary governance. Its report said this was the first deliberate direct change to transaction processing since the amendment system was introduced more than a decade ago. Future protocol changes, it said, will continue to require validator-backed amendments.

Validators retained control over software installation

The Foundation said it shared the patched build with operators of default-UNL validators before releasing public binaries on September 25. Those operators decided whether to run the new version. Neither the Foundation nor RippleX could force an upgrade across independently operated servers.

This created a short period in which patched and unpatched servers followed different rules for the specialized payment path. According to the XRPL report, an attempted exploit during that period could have caused the versions to disagree and potentially disrupted validation. The team judged that risk preferable to leaving a potentially irreversible inflation attack open during a longer public activation period.

The response was coordinated through the XRP Ledger Foundation, RippleX, core developers and validators, but no single organization could make the decision alone. Every validator and node operator chooses which software to run, while the amendment system remains the mechanism for making protocol changes mandatory.

What the disclosure means for users and operators

The report did not instruct XRP holders to move funds or replace their wallets. For node operators, XRPL said servers should run xrpld version 3.4.1 or newer to remain synchronized with the network. In practical terms, the stated remediation concerned the software maintaining ledger infrastructure rather than a wallet action requested of XRP holders.

The Foundation also said a normal payment would not come close to triggering the vulnerability. Exploitation required hundreds of deliberately constructed operations. It added that artificial intelligence can make vulnerabilities faster to find for both attackers and defenders.

Planned security measures

The Foundation said it plans to expand the use of formal verification and AI adversarial testing, work more closely with external security researchers and strengthen its bug-bounty program. These measures cannot guarantee that no critical issue will emerge again, but they are intended to improve the chances that vulnerabilities are identified before a production release.

The disclosure report also describes a release-control measure. Security findings marked as fixed should be tested again against the release candidate containing the patch, and the original reported problem should be reproduced before the finding is closed. That process gives external researchers a defined standard against which later releases can be assessed.

The vulnerability exposed a serious weakness in a rule designed to preserve XRP’s fixed supply. The response has produced a public record consisting of a bug-bounty report, an accelerated validator upgrade, a subsequent technical disclosure and commitments to strengthen security practices. The extent to which those commitments become routine parts of future release procedures will determine the incident’s longer-term significance.

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.

Source: Coindoo.