A vulnerability in the XRP Ledger could have created XRP that the protocol would normally prohibit from being issued. It was patched in xrpld 3.4.1 and disclosed on October 9. Network teams say they found no evidence of exploitation on a public network.
The risk concerned the integrity of the currency itself, not simply a wallet. The incident also raises a governance question: how can an urgent fix be deployed without leaving an exploitable vulnerability exposed while validators vote?
In brief
- Veria Labs describes a demonstration that created approximately 18.45 trillion XRP in a test environment.
- The patch was distributed before the details were published; the teams identified no public exploitation.
- Operators must use xrpld 3.4.1 or a compatible later version.
XRP: a spectacular figure, not a confirmed theft
Protocol maintenance was already at the center of the proposal to remove the native XLS-38 bridge from the XRP Ledger. This time, the issue directly concerns the possibility of creating the native asset. This was not a third-party token imitating its name.
In its technical analysis published on October 10, Veria Labs puts the scale of its demonstration at approximately 18.4467 trillion XRP. Compared with the original 100 billion units, that represents roughly 184 times the initial supply. This is a comparison of quantities, not an estimate of realizable revenue.
Veria also presents a $94 billion market capitalization as potential exposure. That figure is not a recorded loss. An issuance on that scale could have damaged confidence and the price; there is no basis for saying that these units would have found buyers at the previous price.
The official disclosure report clearly distinguishes the capability reproduced in testing from a public exploit. However, the absence of reported evidence does not constitute an absolute guarantee covering the network’s entire history.
Two safeguards blinded by the same calculation
Veria locates the problem in the addition of amounts during order processing. A computer integer has a limited capacity: if the program does not check for overflow, its result can become incorrect. In this case, the total debited could stop matching the amounts credited.
Yet the XRPL invariant documentation describes a second check performed before changes are recorded. Among other things, it is intended to prevent a transaction from creating XRP and to verify balance limits.
Two safeguards do not necessarily provide two independent lines of defense. According to Veria’s analysis, the global check also used a counter that could overflow. It could therefore validate an accounting result that had already been corrupted. The lesson extends beyond this protocol: testing a business rule is not enough if its verification shares the weakness of the initial calculation.
This distinction matters when compared with token-creation permissions in a smart contract. An issuance authorized by an administrator and an issuance caused by a bug in the native engine are two different problems.
Why the emergency response disrupted the vote
The normal amendment process requires support from more than 80% of trusted validators for two weeks. Its purpose is practical: to apply a new rule at the same point in the history, rather than allowing different versions to process a transaction differently.
This coordination sheds light on the debate between operational control and decentralization. The speed of a decision, by itself, does not show who can impose a network’s rules over the long term.
For the issuance vulnerability, the teams chose immediate application after the update. They explain that waiting would have publicly exposed the bug before it was neutralized. That choice created a temporary risk of disagreement between versions, which was accepted in view of the danger of fraudulent issuance.
The issue connects, without conflating the underlying architectures, with discussions about emergency interventions after a hack. The question is not only whether action can be taken quickly, but also which exception is being used and why.
Two fixes, two timelines
The September 25 announcement presented version 3.4.1 as an emergency release. It already detailed strengthened arithmetic calculations, but temporarily withheld the source code for security reasons.
The October report also addresses another flaw related to the encapsulation of Batch transactions. It did not affect funds on mainnet before being fixed. It followed a separate timeline: the fixBatchV1_2 amendment took effect on October 9.
The two events should therefore not be merged. The payment-engine fix applied with the server update; the other change depended on the activation of an amendment.
What operators need to check
The current GitHub release confirms that older versions without the new amendment are now blocked from following the network. The expected action concerns server operators: update their software, then verify synchronization and service continuity.
The documentation notes that a server blocked by an amendment can no longer correctly determine ledger validity or participate in consensus. An application can therefore have a functional interface while relying on a server that is no longer suitable.
For readers, the important distinction is different: separate a fix that was actually distributed, a research demonstration and a confirmed financial incident. Our analysis is based on documents from maintainers and researchers; we did not independently run their demonstration.
What matters next is the quality of the deployment and the controls, not merely the number of XRP that could theoretically be created. A limited-supply rule is reliable only if the software enforcing it, its safeguards and its update procedures work together.
