XRP Ledger Emergency Patch Closed an 18 Trillion-XRP Overflow Path

The XRP Ledger came frighteningly close to a supply disaster—and the most important fact is that developers closed the door before anyone used it.

Security researchers at Veria Labs disclosed a payment-engine flaw that their proof of concept could use to create roughly 18.45 trillion XRP in a single transaction. That is about 184 times the 100 billion XRP created when the ledger launched.

The firm’s AI security agent first identified two issues that looked relatively modest on their own. Researchers then chained them together: one calculation could overflow while adding XRP amounts across offers, and a separate supply-protection counter could also wrap around.

Veria said an attacker could arrange 256 funded accounts and submit an otherwise ordinary signed transaction. The team’s test produced 18,446,744,073,709.551872 XRP across those accounts, with the new balance spread around so no single account crossed its cap.

The setup required only a few hundred XRP in refundable account reserves plus normal fees, according to the disclosure.

Veria privately reported the flaw on Sept. 22.

The firm received a $250,000 bounty. The team held the technical details until the network was protected.

There is no evidence the flaw was exploited on a public network. No unauthorized XRP was created, and the ledger’s legitimate supply did not change.

The size of the theoretical failure explains why the response was so unusual.

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

The problem lived in the XRP Ledger’s payment engine, which can route a payment through multiple offers on the ledger’s decentralized exchange. According to the official XRP Ledger disclosure, a payment could overflow while totaling XRP amounts across offers.

The vulnerable calculation handled native XRP delivered through order-book paths. One crafted payment could therefore pass through normal transaction processing while producing spendable XRP that had not existed before.

A separate “no XRP created” accumulator could then overflow too. Instead of catching the newly created value, the final accounting check could see what looked like an ordinary fee burn.

The distinction matters. This was not a compromised private key, a dishonest validator or a bridge holding stolen collateral.

It was an arithmetic path inside the software that honest validators use to decide whether a payment balances. That made the downside unusually broad.

An attacker could never sell trillions of XRP at the pre-incident market price, of course. The real risk was destruction of confidence in every legitimate XRP already in circulation.

The bug had been reachable since 2015, while the second protection it defeated had been present since 2017.

XRPL protocol changes normally ship as amendments. They activate only after support stays above 80 percent of trusted validators for two weeks, allowing every server to switch rules at the same ledger.

This patch took a different route. Developers distributed the binary-only xrpld 3.4.1 security release days after the private report.

The public GitHub release now tells every server operator to upgrade as soon as possible. The repaired rules began applying as soon as each server installed the software.

The official disclosure says this was the first deliberate transaction-processing change to bypass the amendment path since that system arrived more than a decade ago. Publishing the vulnerable code and then waiting through the normal activation window would have shown attackers exactly where to strike while Mainnet remained exposed.

That emergency choice carried a different danger: old and new servers could disagree if somebody attempted the exploit during the rollout. More than 80 percent of validators on the default trusted list upgraded on release day, sharply reducing that mixed-version window.

Security remains our top priority for preserving trust in the XRP Ledger (XRPL). Sharing a few thoughts following yesterday's disclosure of the critical payments engine vulnerability reported by Veria AI.

First, this was a serious vulnerability, and we don't take that lightly.…

— J. Ayo Akinyele (@ja_akinyele) October 10, 2026

The repaired payment engine now checks for overflow as it totals amounts across offers and across payment paths. If a sum would overflow, the payment fails cleanly.

Developers also widened the “no XRP created” accumulator so the safety check itself cannot wrap around in the same way.

The new rules are already active, and servers running older software can become amendment blocked. Operators should confirm the version actually deployed in production instead of assuming a package file or dependency declaration completed the job.

For XRP holders, the bottom line is less dramatic than the headline number. The vulnerability was privately reported, patched and coordinated before public technical disclosure, and no rogue supply appeared.

But the incident is a serious reminder that a fixed-supply promise ultimately depends on the code enforcing it—and on operators moving quickly when that code fails.

Join the conversation!

We have no tolerance for comments containing violence, racism, profanity, vulgarity, doxing, or discourteous behavior. If a comment is spam, instead of replying to it please click the icon below and to the right of that comment. Thank you for partnering with us to maintain fruitful conversation.