A payment-engine flaw in the XRP Ledger shows how a software bug can threaten a blockchain’s rules without breaking its digital-signature cryptography. Reported by Cayden Liao and Veria AI on Sept. 22, 2026, and fixed three days later, the vulnerability could have enabled spendable XRP to be created beyond the ledger’s 100 billion supply cap.
2
3
42 But Veria AI’s involvement is not proof that AI discovered the flaw: the available reporting does not attribute the vulnerability to AI or document an AI-driven attack.
18
What the XRP Ledger flaw could have done
The issue was in the ledger’s payment engine, which processes payments that draw on offers in the exchange order book. Reporting describes an integer-overflow flaw in the calculation of accumulated amounts: if a total exceeded what the counter could represent, it could wrap around and be miscalculated.
10
43
That mattered because the miscalculation could allow a specially constructed payment to create XRP that could then be spent, rather than merely causing a transaction to fail. The potential impact was a breach of the ledger’s fixed supply rule—not a demonstrated break in the cryptography used to sign transactions.
2
3
26
The flaw was reported through the XRPL bug-bounty program on Sept. 22, and reporting traces it to code dating to about 2015. It affected xrpld 3.4.0 and earlier, according to coverage of the disclosure.
1
3
What the patch and disclosure establish
XRPL released xrpld 3.4.1 as an emergency update on Sept. 25, describing it as a response to security-sensitive protocol issues.
42 RippleX later disclosed two distinct bugs fixed in that release: the payment-engine XRP overflow and a Batch inner-transaction wrapper validation error.
25 They should not be conflated: one concerned payment calculations and potential unauthorized XRP creation; the other concerned validation of Batch transactions.
The release introduced the fixBatchV1_2 amendment, which had validator supermajority support and was expected to activate on Oct. 9.
42 The release announcement said the source code would be published later with a retrospective, citing the security-sensitive nature of the fixes.
42
RippleX’s reported testing showed the flaw could be reproduced, while the disclosure said there was no evidence it had been exploited on the public network.
19 That is a report about the evidence found—not proof that exploitation was impossible. Nor does the available reporting establish that the reported researchers used AI to identify the bug.
18
How this relates to Emin Gün Sirer’s warning
Avalanche founder Emin Gün Sirer warned that AI could find or exploit system-level blockchain bugs before advances in cryptography undermine ECDSA, a digital-signature algorithm.
26
31 The XRP Ledger case illustrates the distinction behind that warning: a defect in transaction-processing software can threaten a ledger’s rules even when there is no evidence that its signature cryptography has been broken.
3
26
But the incident is not evidence that Sirer’s predicted AI attack occurred. Reporting says he did not identify a specific unpatched XRP Ledger vulnerability or demonstrate an AI attack on the network.
12
28 The careful conclusion is narrower: the flaw is an example of the software risk he highlighted, while AI’s role in finding it remains unverified.
The practical takeaway
For blockchain security, cryptographic strength is only one part of the picture. Payment logic, arithmetic, and transaction validation also need scrutiny because mistakes in those layers can undermine protocol rules. In this case, an emergency patch preceded public disclosure, and reports found no evidence of public-network exploitation—but they do not establish that AI was responsible for the discovery.
18
19
42