XRPL discloses a 10-year payment-engine overflow that could have minted XRP from nothing

The XRP Ledger Foundation published a Vulnerability Disclosure Report on October 9 describing an unchecked 64-bit overflow in the payment engine that could have produced XRP ex nihilo when summing the amounts of offers consumed by a payment. The bug has been present since the payment engine was written in 2015. The fix shipped in rippled 3.4.1 on September 25, before the public disclosure. The foundation says there is no evidence of mainnet exploitation.

The bug

In the payment engine, a cross-currency payment can consume multiple existing offers from the order book. The engine sums the amounts paid to those offers in 64-bit arithmetic and compares the total against what the payer provides. The disclosure's one-line description: that sum was computed without an overflow check. Craft a payment whose offer totals wrap past UINT64_MAX, and the resulting small value lets the payer pay a tiny amount while the offer owners are each credited their full ask. The delta is created rather than transferred — the invariant that "no XRP is created outside the initial supply" was itself validated with the same unchecked arithmetic, so the safety rail did not fire.

That is as much mechanism as the public disclosure spells out. The XRPLF report keeps the attack construction compact, which is standard practice for a bug that was live on mainnet for a decade; it names the primitive, not a reproducer.

Discovery and fix timeline

• September 18 — fixBatchV1_2 validation bug (unrelated) reported to the Sherlock Attackathon F48 by Denis Angell and Mayukha Vadari.
• September 22 — The payment-engine overflow reported to the XRPL bug bounty by Cayden Liao and Veria AI.
• September 25 — rippled 3.4.1 ships with both fixes. The payment-engine fix is bundled; the Batch fix is attached to the fixBatchV1_2 amendment.
• October 9 — The fixBatchV1_2 amendment activates on mainnet after validator vote; XRPLF publishes the disclosure.

The payment-engine fix did not require an amendment vote — it is a bug fix, not a consensus change — so the mainnet patch took effect as validators upgraded past September 25. Any validator still on an older release at disclosure time was still vulnerable; the disclosure's release-note recommendation to run 3.4.1 or newer is the operational take-away for node operators.

Why the invariant check didn't catch it

The telling architectural detail in the report is that XRPL has a dedicated post-transaction invariant that asserts no new XRP is created outside the initial 100 billion supply. In principle, that check should have fired on an attempted inflation attack even if the primary arithmetic failed. In this bug, it did not — because the invariant check used the same unchecked 64-bit addition pattern that produced the overflow in the first place. The second line of defense had the same hole as the first.

That is the subtle lesson for other chains and for XRPL itself going forward. A conservation invariant is only as strong as the arithmetic it is written in. Rewriting the summation with explicit checked-add primitives, or in saturating arithmetic that would have left the invariant tripping on the maximum, is what the 3.4.1 fix does. Expect the postmortem to drive a wider audit pass over invariant checks on other core objects (trust lines, escrows, AMM pools) that use similar accumulator patterns.

Impact and attribution

• Reported exploitation: none, per XRPLF's own on-chain review.
• Scope of exposure: all mainnet payments routed through order-book offers between the 2015 payment-engine rewrite and the 3.4.1 upgrade.
• Discoverers: Cayden Liao and Veria AI (payment-engine overflow); Denis Angell and Mayukha Vadari (fixBatchV1_2).
• Reward: the disclosure does not publish the bounty amount.
• CVE: not assigned in the report at publication.

Separate reporting from Cryptoast adds a construction detail — the exploit path would require "several hundred specifically-crafted offers from several hundred accounts, seeded with only a few hundred XRP" — per their writeup. That characterization is not in the XRPLF primary; take it as reporting color, not protocol-foundation guidance.

Context

A silent arithmetic flaw in a payments primitive that could print the base asset is the exact shape of bug that chain security budgets exist to catch. The outcome here — a bounty submission, a point-release fix, a public disclosure once mainnet caught up, no observed exploitation — is close to a textbook response. The disclosure also surfaces the structural issue: XRPL's invariants are a safety net, but a safety net is not meaningful if it is woven from the same thread as the thing it is meant to catch.

The fact that the bug outlived both of Ripple's major client rewrites and sat on a chain running a 100-billion-unit cap tells its own story about how long a dormant edge case can survive when nobody is specifically looking for inflation attacks on a non-inflationary asset.

What to watch

1. A post-rippled-3.4.1 audit sweep of other XRPL invariants that use unchecked accumulator patterns — the AMM, Clawback, and trust-line conservation checks are the obvious next places to look.
2. The disclosure's follow-up. XRPLF has flagged a longer technical write-up to follow the summary. Specific state-tree diffs, if the foundation publishes them, will matter for any downstream chain forking rippled.
3. Downstream fork hygiene. Any chain running a rippled-derived codebase (Xahau, forks of older rippled) should flag whether their fork point sits before or after the September 25 patch.
4. Bounty-program disclosure cadence. The 17-day window between report and public disclosure is on the short side for a flaw of this age; the next publishable question is whether XRPLF plans to open-source the write-up template for the next finding.