RippleX changed XRP Ledger transaction rules without the standard validator vote. The emergency fix closed a flaw that could have created XRP out of nothing. Validators received compiled soft
For the first time in more than ten years, the XRP Ledger changed how it processes transactions without an amendment vote. The emergency release, xrpld 3.4.1, went out on September 25, 2026, three days after security firm Veria Labs privately reported a flaw that could have let a single payment create roughly 18 trillion XRP. The fix went out as compiled software, with the source code published two weeks later, a sequence that has since drawn criticism from outside the project.
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
Rule changes on the ledger normally pass through an amendment, which activates only after more than 80% of trusted validators support it for two consecutive weeks. The corrected code is public from the first day, and a competent reader can compare it with the previous version and work out what it prevents.
Here the old rules would have stayed in force for at least a fortnight. The attack was cheap: the official disclosure estimates a few hundred XRP in account and offer reserves, most of it recoverable, plus ordinary fees.
Standard route
Amendment vote
Activation: after 2 weeks above 80% support
Source code: public from day one
Cost here: flaw stays exploitable while the fix is readable
What happened instead
Emergency release 3.4.1
Activation: immediately on each upgraded server
Source code: published after the binaries
Cost here: possible validator disagreement, code run on trust
The emergency fix took effect on each server the moment its operator installed it, so validators briefly applied different rules. A patched validator would have rejected a malicious payment that an unpatched one accepted, and the disclosure acknowledges that such a split could have temporarily halted ledger validation. The developers and validators involved judged a stalled network preferable to trillions of unauthorized XRP.
The window was short. More than 80% of validators on the default Unique Node List, the set that servers trust unless configured otherwise, ran 3.4.1 on release day. Other networks have gone further under pressure: in September, Cronos erased 11,000 blocks to undo a $120 million exploit
From private report to public disclosure
September 22
Veria Labs files the report. RippleX reproduces the exploit and raises severity from Major to Critical.
September 23
Engineers merge the fix into the 3.4.1 branch after private reviews.
September 25
xrpld 3.4.1 ships without a vote.
October 9
The XRPL team publishes its vulnerability report.
Validators received executable software while the source code stayed private. Cyber Capital founder Justin Bons criticized the arrangement, arguing that a public ledger had temporarily operated on closed code. The XRP Ledger Foundation has since said the build went first to default UNL validators through the contact details each publishes in its xrp-ledger.toml file, with public binaries following the same day.
It also argues that no single party could impose the change: every operator chose whether to install it, and 3.4.1 became mandatory only once the fixBatchV1_2 amendment passed the standard vote. The source for 3.4.1 has since been published, so anyone can compare it against the distributed binaries.
The bug sat in payment code dating to 2015. The ledger has an order book built into the protocol, and a payment can settle against many standing offers at once. The engine added up the XRP owed with 64-bit integer arithmetic, and when the sum exceeded the largest value that format holds, it wrapped around to a small number. Sellers were credited in full. The buyer paid the wrapped total.
A supply check added in 2017 should have blocked this, but it used the same unchecked arithmetic and overflowed with the calculation it was auditing. A per-account limit also missed the attack, because the new XRP was spread across hundreds of wallets.
18T
XRP one transaction could create
$94B
Value at risk, Veria Labs’ estimate
2015
Year the flawed code went live
$250K
Bounty paid, the program maximum
Veria Labs says an AI agent it built found both weaknesses and wrote a working proof of concept. By the firm’s count, the ledger had been through more than a dozen audits and audit contests since 2024 and had paid over $1 million in bounties without anyone flagging the overflow.
Server operators need to run xrpld 3.4.1 or a later version. The disclosure does not indicate that XRP holders need to take any step. The Foundation says it has verified the supply across the ledger’s full history, and that about 99.986 billion XRP exist today, slightly below the original 100 billion because transaction fees are destroyed. Developers added overflow checks to the payment engine, rebuilt the supply check, and are introducing a stricter procedure for confirming that reported flaws are fixed before a release ships.
The same release closed a separate flaw in Batch transactions, a feature not yet active on Mainnet, and that fix went through a regular amendment that activated on October 9.
The speed of the response is likely to be tested again. Veria Labs points to a 2026 incident in which at least 1,367 BTC, worth around $89 million, was stolen through a years-old flaw in Coldcard wallet firmware. Coinkite, the wallet’s maker, reportedly suspected the attackers used AI to find it, though that suspicion remains unproven. Hardware wallets came under attack again this month, when Ledger buyers lost millions to a spy chip hidden inside the device.
The post XRP Ledger Skipped Its Own Validator Vote to Patch a Critical Bug appeared first on ETHNews.
