XRPL Patch Closes Supply-Overflow Flaw That Could Have Created 18.45 Trillion XRP

An arithmetic flaw in the XRP Ledger’s payment engine could have allowed a transaction to create roughly 18.45 trillion XRP—far beyond the ledger’s original 100 billion supply cap. RippleX patched the vulnerability in September 2026, after researchers demonstrated a working exploit in a local test environment. The episode puts a specific protocol risk in focus: a calculation error in payment settlement can have consequences beyond the individual transaction, reaching the ledger’s supply protections.

How the payment flaw worked

Veria Labs, a US-based cybersecurity startup, found the issue with an AI-assisted security agent. The vulnerability had been present in XRPL’s payment-processing code since 2015, according to the researchers’ report dated October 12. It involved an integer overflow—a calculation that exceeds the range a software variable can represent and produces an incorrect result.

The problematic path involved transactions that processed multiple decentralized exchange orders. XRPL’s payment engine could miscalculate how much XRP a buyer needed to provide to settle those orders. In the exploit scenario described by Veria Labs, sellers could receive the full amounts associated with their orders even though the buyer was charged substantially less.

A separate arithmetic error in the ledger’s supply-protection mechanism could then keep the transaction from being rejected. That combination matters: the payment calculation created the imbalance, while the second error weakened a check intended to prevent an invalid change to the XRP supply. Veria Labs said a single successful transaction could have created more than 184 times the original supply, and that an attacker could potentially repeat the attack under the right conditions.

“An attacker could have created spendable XRP far beyond the total supply in a single validated transaction,” Veria Labs stated. The firm estimated that the flaw put XRP’s reported $94 billion market value at risk. That figure describes the value cited in the report, not a loss that occurred: the article reports that researchers tested the exploit locally and that RippleX released a patch.

Why the patch skipped the usual path

Veria Labs reported the vulnerability on September 22, 2026. The fix was merged the next day, and the emergency software release, rippled 3.4.1, followed on September 25. Rather than wait for XRPL’s standard amendment process, the response used an immediate software update. That process generally requires support from more than 80% of trusted validators over two weeks.

The reason for moving quickly was exposure risk. Publishing details of a fix while the network was still waiting for the usual approval could have given attackers time to study the weakness before enough participants had upgraded. The disclosure says more than 80% of default validators installed the release on its first day.

That response highlights a practical tension in decentralized software maintenance. A standard process can give validators time to assess and coordinate changes, but a publicly visible vulnerability can make delay costly. An emergency release can narrow that window, while placing more weight on fast communication, software distribution and validator readiness. The reported upgrade rate offers a measure of adoption, but it does not, by itself, establish how every network participant updated or how the change was tested in every environment.

Testing and wider XRPL security

The supply flaw is separate from an August security incident involving the tx XRPL cross-chain bridge. In that case, an attacker stole approximately $200,000 after software incorrectly treated transactions as deposits, even though the corresponding XRP had not reached the bridge’s reserves. The bridge operator halted the service and addressed the vulnerability. The two incidents involved different software and failure modes; together, they show why testing must cover both ledger-level transaction logic and the systems that connect to it.

On Sunday, XRPL developers announced plans to expand security testing. Those plans include mandatory retesting of fixed vulnerabilities before releases, broader AI-assisted bug detection, formal verification, closer work with security researchers and a stronger bug bounty program. These are stated plans, not evidence that every measure is already in place.

AI-assisted discovery helped Veria Labs identify and reproduce this flaw, but the result also underlines the limits of relying on a single testing method. Payment engines combine arithmetic, order settlement and validation rules; a defect at the boundary between those components can escape ordinary checks. Retesting fixes and applying formal verification may help teams examine whether key properties hold across transaction paths, while adversarial testing can probe how those paths behave under deliberately constructed inputs.

For XRPL users and developers, the immediate takeaway is that the reported supply-creation path was addressed in rippled 3.4.1, with rapid validator uptake cited by the disclosure. The longer-term test will be whether the announced practices become routine parts of release work. For a ledger whose supply limits depend on software-enforced checks, arithmetic edge cases deserve the same attention as broader transaction and bridge security.