XRP Ledger Patches Decade-Old Bug That Could Have Bypassed Its 100 Billion Token Cap

The XRP Ledger has fixed a critical software vulnerability that could have allowed attackers to create spendable XRP without paying the corresponding amount. The flaw, reportedly present since 2015, was disclosed by the XRP Ledger development team on October 9, 2026, following an investigation into a bug bounty submission. Developers said they found no evidence that the vulnerability had been exploited on public networks.

The vulnerability affected the ledger’s payment engine, specifically transactions that execute multiple offers from an order book. Under carefully constructed conditions, the calculation used to add XRP amounts could exceed the maximum value supported by its integer representation and wrap around to a much smaller number.

The XRP Ledger has a fixed intended supply of 100 billion XRP, making the potential flaw particularly serious. If exploited, it could have enabled an attacker to receive and spend XRP that had not been transferred from an existing balance, undermining the ledger’s supply rules.

How the XRP Minting Vulnerability Worked

The issue was reported through the XRP Ledger Bug Bounty program on September 22. The researcher demonstrated that an attacker could construct hundreds of specially priced offers and execute a single payment designed to consume them together. Each offer could appear valid individually, while the combined amount triggered the arithmetic overflow.

When the calculation wrapped around, the payment engine could charge the buyer only the much smaller resulting total while still crediting the sellers with the full amounts specified by their offers. The difference represented newly created XRP. The attacker could distribute the resulting balances across multiple accounts and spend the tokens in subsequent transactions.

An existing safeguard intended to detect the creation of XRP did not catch the problem because it used similar arithmetic when calculating the transaction’s net balance changes. That calculation could overflow in the same way, allowing the unexpected increase to escape detection. Individual account balance checks also failed to identify the issue when the newly created tokens were distributed across multiple accounts.

The development team’s investigation found that the vulnerability was not practical to trigger through ordinary payments or routine trading. It required deliberately constructed offers and a transaction engineered to process them together. However, the ability to create spendable tokens made the flaw critical despite the unusual conditions needed to exploit it.

RippleX confirmed the issue on a local test server and developed a fix for the payment engine. The discovery illustrates why blockchain security depends on testing edge cases that normal transactions are unlikely to reach, rather than relying exclusively on routine operation and standard balance checks.

Emergency Patch Released in XRPL Version 3.4.1

RippleX released XRP Ledger server software version 3.4.1 on September 25, addressing the payment-engine overflow and additional security issues. The payment fix adds checks to prevent arithmetic overflow when summing amounts across order-book offers and combining results from multiple payment paths. Transactions that would trigger the overflow are rejected rather than allowed to create XRP.

Developers also strengthened the ledger’s safeguards by using a wider counter for the check designed to ensure that transactions do not create XRP. This provides another layer of protection against similar arithmetic errors, even if a future vulnerability appears in a different part of the transaction-processing code.

The response was unusual because the payment fix took effect as individual servers upgraded, rather than waiting for the XRP Ledger’s normal amendment process. That decision reduced the period during which a publicly disclosed vulnerability could remain exploitable, although developers acknowledged that mixed software versions can introduce temporary network-consistency risks.

According to the disclosure, more than 80% of validators on the default Unique Node List had upgraded on the day version 3.4.1 was released. The rapid response helped limit the exposure window before the technical details became public. The same release also addressed a separate Batch transaction validation flaw, which was handled through the fixBatchV1_2 amendment activated on October 9.

For XRP holders, the disclosure did not identify a need to move tokens or replace wallet keys. The issue concerned server-side transaction processing, and the team reported no evidence of public-network exploitation, compromised private keys or losses attributable to this vulnerability. Node operators, however, were instructed to upgrade to version 3.4.1 or later to remain aligned with the current network rules.

The incident highlights the role of bug bounty programs, independent researchers and rapid software updates in protecting blockchain infrastructure. XRP’s supply cap remained intact in the reported public-network activity, but the discovery demonstrates why even long-established payment systems require continuous review, stronger arithmetic safeguards and careful validation of security fixes.