Crypto protocol review: the XRP Ledger payment-engine bug

The news

XRP Ledger developers have disclosed a critical-severity flaw in the network’s payment engine that could have let an attacker create XRP without a source. The code dated to 2015. In a disclosure report dated October 9, the maintainers said they had “no evidence that this issue was exploited on any public network.”

The bug involved totaling a payment that fills many order-book offers at once. The sums had no overflow check, so a large enough total wrapped around to a small number. The ledger’s own check against newly created XRP added balances in a similar way, so it also failed to stop the minting. In the attack described, a person would create a few hundred accounts, each offering a tiny fraction of a token for a huge amount of XRP. One payment would then close all those offers: each seller would be paid in full while the buyer paid only a few hundred drops plus the fee. The report said the setup could not be triggered by accident, since it needs hundreds of offers priced in ways no real trader would use.

Veria Labs, an AI security startup, found the flaw. Co-founder Cayden Liao said the firm’s AI agent located it and built a working exploit, and that a single transaction could have created about 18 trillion XRP, roughly 184 times the supply. Ripple paid the program’s top bounty of $250,000, which Liao said is the largest known payment for a vulnerability found entirely by an AI agent.

Our analysis

The timeline shows a fast response. Veria reported the bug on September 22, and RippleX shipped the fix in xrpld version 3.4.1 three days later, on September 25. More than 80% of validators on the default Unique Node List were running it that day. Public disclosure came two weeks later, after the network was protected.

The notable choice was how the fix was deployed. XRP Ledger changes that alter transaction processing normally go through the amendment process, which needs support from more than 80% of trusted validators over two weeks. This fix took effect as each server upgraded, with no vote. The report called it the first such case in more than ten years of amendments. The reasoning is that xrpld is open source, so a normal release would have shown attackers the bug for weeks before it activated.

That reasoning points to a trade-off for any protocol: a vote gives validators a say but exposes a vulnerability while they deliberate. The same release also fixed a separate flaw in Batch, a feature not yet live when it was found. According to the report it could have stalled the network. Batch and its fix both activated on Friday, and servers on older versions can no longer stay in sync.

The finding also reflects a change in how bugs are found. A flaw that survived over a decade of human review was, by Veria’s account, identified by an automated agent, and Liao suggested it went unseen because it chains two issues that would each rate as low severity alone.

Room for disagreement

Critics say the process cost something. The source code for 3.4.1 was published about two weeks after the binaries, and Justin Bons, founder of Cyber Capital, argued on X that XRP had run closed-source code for that period. RippleX engineer Mayukha Vadari replied that AI has changed the situation, since a critical patch hidden inside a routine public release would be spotted and reverse-engineered quickly. A broader objection is that bypassing validator votes, even once, sets a precedent for centralized control of a network that markets itself as decentralized. The report’s answer is that a normal open-source release would have exposed the bug while leaving it exploitable for weeks.

What to watch

RippleX Head of Engineering J. Ayo Akinyele said the team will expand AI-assisted bug hunting and formal verification. Watch whether Ripple publishes a fuller postmortem, whether validators adopt a documented process for emergency fixes, and whether other ledgers audit for similar overflow patterns in order-book code.