XRP Ledger Closes a 2015 Flaw That Could Create XRP Out of Nothing: What It Means for Your Coins

The XRP Ledger disclosed a bug on 9 October 2026 that had been sitting in the chain's payment engine for about eleven years. Anyone exploiting it could have created XRP far beyond the total supply in a single valid transaction. The flaw has been closed since 25 September with version xrpld 3.4.1, and RippleX writes in its report that there is no indication anyone used it on a public network.

So this is not a warning about an attack in progress. What is left to settle is your own setup: where your coins sit, who runs the server behind them, and which version is running there. This article places the disclosure report in context, explains the arithmetic error in plain terms, and translates it into the points an investor in Europe can check without outside help.

Payment engine overflow: what the 9 October report discloses

The disclosure report for xrpld 3.4.1 describes two separate findings. The more serious one concerns the payment engine, the part of the software that routes a payment through the offers in the chain's order book and works out how much the payer must give up and the recipient must receive.

The finding was submitted on 22 September 2026 through the XRP Ledger bug bounty programme, the channel where security researchers hand in vulnerabilities for a reward. The report names Cayden Liao and Veria AI as the finders. It was initially rated "Major". After RippleX reproduced it, the team raised the rating to critical.

The report sets out the scale in a single sentence: an attacker could have created spendable XRP far beyond the total supply, and in one confirmed transaction. The stake needed would have been small. It took a few hundred XRP as a reserve, the deposit the network requires for open offers and returns once they are cleared, plus the usual fees. Versions xrpld 3.4.0 and all older releases were affected.

How an unchecked addition could make more than 100 billion XRP

The arithmetic error in one sentence

The payment engine added up the amounts of several offers using a 64-bit integer, without checking whether the result fit into that width. An overflow is exactly that case: when a sum exceeds the largest value that can be represented, it does not raise an error but starts again at zero. A very large sum turns into a very small number.

In practice, according to the report, that meant the offer providers were paid in full while the buyer was charged only the tiny wrapped-around remainder. The difference came out of nowhere. It could be triggered with a few hundred deliberately mispriced offers in the order book, which a single payment then swept up together.

What the supply check missed

The XRP Ledger has its own safeguard against precisely this kind of case, the invariant. An invariant is a rule that must hold after every transaction, or the network rejects it. One of them says that no XRP may be created.

That check ran inside the same bug and used the same unchecked arithmetic. So it saw no increase where there was one. Two layers of protection gave way because both rested on the same assumption. The report traces the bug back to the implementation of the payment engine in 2015.

xrpld 3.4.1: a fix without an amendment, effective at start-up

Changes to the rules of the XRP Ledger normally go through an amendment. An amendment is a rule change that validators vote on and that applies across the network only after a period of support. Validators are the servers that confirm the order of transactions.

For this finding RippleX deliberately chose a different route. The overflow checks in the offer sum and in the combination of several payment paths take effect without a vote as soon as a server starts up on 3.4.1. The invariant has counted with a wider counter ever since. The report calls this a considered exception, justified by the severity of the finding.

For operators the consequence is a clear duty. The report states that all server operators must move to 3.4.1 or newer to stay in sync with the network. Anyone staying on an older version has been amendment-blocked since the activation on 9 October, which means they are stuck on a set of rules the rest of the network has already moved past.

Timeline from 22 September to 9 October

The report sets out the sequence, and the intervals in it are the real finding. One day passed between the submission and a finished fix.

On 22 September 2026 the overflow came in and was reproduced. On 23 September the fix was in the release branch for 3.4.1. On 24 September the team concluded that a pure disruption scenario along this route would not really work. On 25 September xrpld 3.4.1 was published, and at the same time a two-week support phase began for the second fix. On 9 October both rule changes went live on the main network, and the report appeared the same day.

Two weeks between shipping and disclosure are deliberate, not an omission. As long as a large share of servers is still running the old version, a precise description of the bug amounts to a set of instructions. It was published on the day the rule change stood in the network.

Five of the XRPL's eight disclosure reports date from 2026: our own count

Whether a single finding is an outlier only becomes clear from the series. So we counted every post on the XRPL blog and picked out the disclosure reports. Among 273 posts there are eight such reports, and five of them carry a 2026 date.

The five from this year cover the Batch amendment in February, the handling of transaction amounts in March, a flood of manifest messages reported on 30 July, sponsored fees and reserves under XLS-68 reported on 7 August, and the report on 3.4.1 from 9 October. The three older ones fall in November 2024, April 2025 and September 2025. cryptoticker.io compiled this count itself on 10 October 2026.

The number can be read in two directions, and only naming both is honest. More reports can mean that more is being found, because a bounty programme and a contest such as the Sherlock Attackathon round are looking for it on purpose. It is also conceivable that the chain gains more surface area with every new building block where something can jam. For placing the overflow in context, what counts above all is that it comes from the old core and not from one of the new features.

Batch amendment and Permission Delegation: what else went live on 9 October

The report's second finding concerns Batch, a feature under proposal XLS-56 that lets an account submit up to eight transactions as a single unit. The specification requires every inner transaction to sit in a designated field. The server did not check this, so other fields could serve as a wrapper too.

More seriously, the set of permissible wrappers differed between software versions. Two servers could therefore have judged the same operation differently, and that is precisely what threatens consensus in the network. Versions 3.3.0 and 3.4.0 with the not-yet-active BatchV1_1 amendment were affected. The report names Attackathon submission F48 as the finder, initially rated low. Denis Angell of the XRPL Foundation established on 18 September that the first fix was incomplete, and Mayukha Vadari of RippleX found the risk to consensus. According to the report there was no damage: no loss of balances, no exposed keys, no consensus failure.

Since 9 October the network rejects every Batch transaction with the wrong wrapper, secured by the rule change fixBatchV1_2, which went live the same day as BatchV1_1. Our article from 1 October described the window in which this round of rule changes could take effect at the earliest, and the open question then was why parts of it were delayed: the XRP Ledger and the date for Permission Delegation. The report supplies the answer. Behind the delay stood the withdrawal of votes, which prevented an activation with an incomplete fix.

63.13 of 99.99 billion XRP: the supply cap as the core of the promise

XRP was created once and has not been issued since. Of a total supply of 99.99 billion units, 63.13 billion are in circulation, with the rest locked up or held by the company. Market capitalisation, the circulating supply at the current price, stands at around $88.8 billion as of 10 October 2026. That places XRP fifth among the largest cryptocurrencies.

This firmness of supply is where the overflow hurts. A flaw that creates spendable units beyond the cap does not hit a side feature but the promise the price rests on. An executed attack would not merely have changed the supply on paper; it would have damaged the check with which the network notices supply changes at all.

The critical rating is therefore understandable even though no balance was lost. The yardstick for findings like this is the possible damage, not the damage that occurred. And here it sat on the number the whole model carries.

How to check where your XRP sit if it comes to the worst

The software version of a server is not something an investor can change from outside. What can be checked is the chain of responsibility: who holds the coins, who runs the technology underneath, and who would have to be contacted in an emergency.

Exchange, broker or self-custody

If the XRP sit on an exchange, that exchange runs the connection to the chain and is responsible for the version. The investor has a claim to withdrawal there, not direct access to the coins. Which trading venues in Europe operate under a licence, and what fees that involves, is set out in our overview of the best crypto exchanges.

With self-custody the key sits with the holder, and the connection runs through a provider or an own server. Anyone using wallet software should update it after a report like this, because many programs use a bundled connection. With an own node the duty from the report applies directly: version 3.4.1 or newer, or the server drops out of consensus.

Three questions carry this check. First: does the holding sit with a provider domiciled and licensed in the EU, or on a platform without European supervision? Second: has the provider announced maintenance or an update after 25 September? Third: how would a withdrawal run if the network stood still for hours?

Custody under MiCA: a claim rather than possession

Since MiCA, the EU regulation for markets in crypto-assets, providers that hold or exchange crypto-assets for clients need authorisation as a crypto-asset service provider. Their duties include keeping client holdings separate from their own and being liable for the loss of assets held in custody.

That shifts the question without resolving it. An authorised custodian can be contacted and carries liability, but it sits between the holder and the chain. Self-custody turns that around: no third party can freeze the holding, and nobody is liable for a lost key. Which form is right depends on the amount and on how often somebody trades.

With a protocol bug like this one, both help only so far. A flaw in the payment engine takes effect on the chain, not on the holder's device. What custody decides is how quickly somebody can react if a network has to be halted or rebuilt.

XRP price at $1.41: the market did not move on the news

XRP trades at $1.41 on 10 October 2026, up 1.1 percent on the previous day. The daily range runs from $1.37 to $1.41. Over a week it is down 5.6 percent, over thirty days up 0.8 percent.

The levels for the coming days follow from that range. On the downside sits the daily low at $1.37, on the upside the daily high caps it at $1.41. That the 9 October disclosure left no mark fits the content: what was reported was a closed flaw with no indication of exploitation, not an incident in progress.

Our assessment: a bug that sat for eleven years is not a one-off

From the newsroom's point of view, the handling of this finding is the counterpart to the bug itself. One day from submission to fix, two weeks to disclosure, a fix without a vote where voting would have taken too long: this is the conduct one would want from a network of this size, and it is documented in the report.

The other side sits in our own count. Five of eight disclosure reports within one year, plus a finding from the 2015 core that two layers of protection let through at the same time because they used the same arithmetic. Anyone concluding from this that the chain is now audited is reading too much into it. The origin of the finding argues against that reading: code that ran unremarkably for years, not a freshly built feature. For an assessment of XRP as an investment the episode changes nothing about the numbers; it changes something about the question of how much auditing the foundations still need.

XRPL patch: without version 3.4.1 a node drops out of consensus

1. Settle responsibility. Check where your own XRP sit and who runs the connection to the chain. With a provider, what counts is its authorisation and whether client holdings are kept separate. Which platforms operate under European supervision is shown in our overview of regulated crypto exchanges.
2. Follow the state of the chain yourself. The activation of rule changes and the version of a server are publicly visible. Anyone tracking that regularly notices a changeover before the next report. Tools for it are listed in our overview of analytics platforms.
3. Document holdings and holding periods. After a protocol incident a clean record of your own inflows and outflows counts, for tax purposes too. In Germany the one-year holding period decides whether a gain is taxable. How to keep track of that is covered in our list of crypto tax software and portfolio trackers.

The episode can be read in the source itself: in the disclosure report for xrpld 3.4.1 and in the announcement of version 3.4.1 from 25 September.

(As of October 10, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)