XRP Ledger confirms 100B supply is safe after major security flaw

The XRP Ledger has fixed a critical security flaw dating back to 2015 that could have allowed attackers to create approximately 18 trillion XRP through a single specially designed transaction, with more than 80% of trusted validators installing the emergency update on September 25.

The XRP Ledger Foundation and RippleX confirmed the vulnerability in an October 9 disclosure, explaining that an error in the network’s payment engine could have produced spendable XRP beyond its intended 100 billion supply. Developers reproduced the issue during testing and released version 3.4.1 to address it. Their investigation found no evidence that the flaw had been exploited on a public network. Security researcher Cayden Liao and Veria AI received the bug bounty program’s maximum $250,000 reward after reporting the vulnerability and demonstrating its potential effect.

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…

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

XRP Ledger fixes bug that could create trillions of XRP

The vulnerability affected the XRP Ledger’s payment engine, which processes transfers and transactions involving the network’s built-in decentralized exchange.

According to the official disclosure, the problem originated from an integer overflow in software written in 2015. An integer overflow occurs when a calculation produces a number larger than the computer system can represent using the allocated number of bits.

In this case, the payment engine added together XRP amounts associated with multiple offers in the network’s order book. The software used a 64-bit integer to calculate the total amount a buyer owed when completing a payment involving several offers.

Developers discovered that an attacker could create hundreds of specially priced offers and arrange for one payment to consume them. When the calculated total exceeded the integer’s maximum value, the number could wrap around to a much smaller amount. The system would still credit individual sellers with the full XRP amounts specified in their offers, even though the buyer paid only the reduced amount produced by the overflow. The difference would create XRP that had not previously existed.

According to the XRPL Foundation, the resulting cryptocurrency could be transferred to other accounts, traded or sent to exchanges. The report described the potential outcome: “An attacker could have created spendable XRP far beyond the total supply.”

The vulnerability could not be triggered through ordinary trading, according to developers. An attacker would have needed to create several hundred accounts, place unusually priced offers and submit a carefully constructed transaction to process them together. The existing security checks failed because the system’s supply verification used the same type of arithmetic that caused the original error.

Meanwhile, a separate account balance check could be bypassed by distributing the newly created XRP across multiple wallets.

Researcher uncovers potential 18 trillion XRP exploit

The vulnerability came to developers’ attention after security researcher Cayden Liao and Veria AI tested the XRP Ledger’s open-source software.

Veria Labs published its findings on October 10, describing how its automated security testing system discovered the issue on September 21. The following day, researchers developed a working proof of concept on a local testing network.

According to the company, the demonstration showed that approximately 18 trillion XRP could be created through one specially designed transaction. The amount was equivalent to roughly 184 times XRP’s intended total supply, based on the researchers’ calculation. The figure describes the results of controlled security testing, not an actual increase in the cryptocurrency’s circulating supply. Liao submitted the vulnerability through the official XRPL bug bounty program on September 22.

RippleX engineers reproduced the problem on a standalone server and confirmed that the newly generated XRP could be spent in a subsequent payment.

The initial report classified the vulnerability as major, but developers raised its severity to critical after confirming the potential consequences. Veria Labs stated that the vulnerability could have placed XRP’s entire market value at risk if attackers had successfully exploited it. The company’s estimate was based on an approximately $94 billion XRP market capitalization at the time.

However, the $94 billion figure represents the researcher’s estimate of potential financial exposure, not confirmed losses. The security team found no evidence of unauthorized XRP creation on public networks. On October 8, Veria AI received the maximum $250,000 bounty for identifying and responsibly disclosing the issue.

RippleX releases emergency fix without normal approval process

After confirming the vulnerability, RippleX engineers developed a fix between September 22 and September 23. The patch was incorporated into xrpld version 3.4.1, released on September 25.

According to the official disclosure, developers added checks that prevent the payment engine from accepting calculations exceeding the permitted integer range. The updated software rejects affected calculations and returns an ordinary payment failure instead of creating additional XRP. Engineers strengthened the network’s supply verification by replacing the existing arithmetic with a wider counter designed to detect similar errors. Additional balance calculations were reviewed as a precaution.

However, the decision to deploy the fix introduced an unusual situation for XRP Ledger governance. Normally, changes to transaction processing must pass through the network’s amendment system. An amendment requires support from more than 80% of trusted validators for two consecutive weeks before activation.

For the payment overflow vulnerability, developers decided to apply the fix immediately when validators upgraded their software. The XRPL Foundation explained that the normal process would have exposed the vulnerability while leaving it exploitable during the approval period.

Because the XRP Ledger software is open source, publishing a patch can reveal the location and nature of a vulnerability.

Developers concluded that waiting through the usual amendment process could have created additional security risks. The emergency approach carried a separate concern: validators running different software versions could disagree about how to process a malicious transaction.

In an extreme scenario, the disagreement could temporarily prevent the network from confirming new ledgers. The foundation said the decision was made in consultation with RippleX, validator operators and other XRPL contributors. By September 25, more than 80% of validators on the default Unique Node List had upgraded to version 3.4.1.

The public source code was subsequently released after the immediate security response. The XRPL Foundation’s release records describe version 3.4.1 as an emergency update addressing security-sensitive protocol issues.

XRP Ledger resolves second security flaw before Batch activation

The October 9 disclosure covered another vulnerability involving the XRP Ledger’s Batch transaction feature. Batch allows developers to combine up to eight transactions into one operation. The feature supports different execution modes, including arrangements in which every transaction must succeed for the complete operation to be accepted.

During security testing, researchers discovered a validation error involving how individual transactions were packaged inside a Batch. The protocol required each transaction to use a specific field named RawTransaction.

However, the software could accept alternative field names under certain conditions. Investigators found that different server versions might process those incorrectly formatted transactions differently.

According to the XRPL Foundation, the resulting disagreement could interrupt network validation if the feature became active before the problem was corrected. The issue was originally identified during the Sherlock Attackathon and later examined by XRPL Foundation contributor Denis Angell. RippleX engineer Mayukha Vadari determined that the vulnerability created a potential consensus risk between server versions.

Developers responded by introducing the fixBatchV1_2 amendment. The amendment requires every Batch transaction to use the approved field format and rejects incorrectly packaged transactions. Validators temporarily withdrew support for the earlier BatchV1_1 activation schedule while developers completed the correction.

Both fixBatchV1_2 and BatchV1_1 activated on the XRP Ledger mainnet on October 9. The XRP Ledger Batch activation received support from 30 validators, with five opposing the upgrade, according to XRPScan figures included in the verified network report.

Earlier research into the Batch security review detailed the September 25 emergency release and the safeguards required before the feature could activate. The initial version had previously faced security concerns, including transaction authorization issues uncovered during developer reviews.

A separate XRP Ledger security audit in August documented 96 valid vulnerabilities identified during a Sherlock competition covering proposed protocol features.

For the latest Batch vulnerability, the XRPL Foundation confirmed that the affected amendments had not been active on mainnet when the issue was discovered. No user funds were lost, no private keys were compromised and no consensus failure occurred because of that particular flaw. The October 9 activation means servers running older software versions are now amendment blocked and must upgrade to version 3.4.1 or later to remain synchronized.

The XRPL Foundation said it is introducing an additional verification requirement for future software releases: previously reported security issues must be tested again against release candidates before being classified as fixed.

According to the foundation, the procedure will apply to findings from audits, bug bounty programs, AI-assisted security testing and other vulnerability assessments.