
XRP Ledger patched decade-old bug that could create billions of dollars in XRP from nothing
CoinDesk reports that researcher Cayden Liao and Veria AI found a flaw, believed to date to 2015, in the XRP Ledger's built-in exchange. Hundreds of crossed offers made the total XRP owed too large for the software to count correctly. The buyer was charged almost nothing while the sellers were paid in full, so XRP was created from nothing. The bug slipped past the ledger's post-transaction no-new-XRP invariant check, which relied on the miscounted total, and past per-account receive limits, because the XRP was spread across hundreds of accounts. RippleX reproduced it on a standalone server and fixed it in xrpld 3.4.1 on Sept. 25 without disclosing the cause. It found no evidence of exploitation on public networks.
What it is
A supply-creation bug in the XRP Ledger's built-in exchange (the offer/order-book crossing logic). The page says it is believed to date to 2015. Cayden Liao and Veria AI found it and reported it internally on Sept. 22. RippleX fixed it in xrpld 3.4.1 on Sept. 25. The release notes did not say what the fix repaired. CoinDesk's report of the mechanism was published Oct. 10.
How it works
The summary covers the overall counting error. The page adds the attack's construction and why it was cheap:
- The attacker opens hundreds of accounts.
- Each account posts an offer giving a tiny amount of a token in exchange for an unusually large amount of XRP.
- A single payment then buys every offer at once.
- The total XRP owed is too large for the software to count correctly. The sellers are paid in full and the buyer is charged almost nothing.
flowchart LR
A[Hundreds of crossed offers] --> B[Total XRP owed overflows count]
B --> C[Post-transaction invariant check]
B --> D[Per-account receive limit]
C -->|uses miscounted total| E[Passes]
D -->|XRP spread over many accounts| E
E --> F[New XRP created and spendable]The two safeguards failed for different reasons. The invariant check ran on the same miscounted total, so it saw no new XRP. The per-account receive limit never triggered because no single account received enough.
The page says the method needed only a few hundred XRP to open the accounts, most of which could be recovered, plus transaction fees. RippleX reproduced it on a standalone server and confirmed the created XRP could be spent in a later transaction.
Preconditions / Affected
- Affects XRP Ledger server software (xrpld) older than 3.4.1. The page does not name an exact vulnerable version range.
- The attacker needs a few hundred XRP of working capital and the ability to open many accounts.
What to do
- Upgrade xrpld to 3.4.1 or later if you run a node or validator. The page gives no upgrade commands.
- The page lists no detection method or indicators. RippleX reports no evidence of exploitation on public networks.
Caveats
- The "no evidence of exploitation" claim is RippleX's own. The page gives no detail on how the ledger history was checked.
- The 2015 origin is stated as "believed", not confirmed.
- The attack is described as theoretical ("could have") on public networks. The working reproduction was on a standalone server.
- The page does not say how many nodes have upgraded, and the fix shipped without a stated cause for about two weeks.
Organisations named here
Technologies named here
- xrpld
- XRP Ledger
- xrpld 3.4.1
- xrpld versions before 3.4.1
- Veria AI
- XRP Ledger built-in exchange
- XRP Ledger per-account limit on XRP received
Also named here
- Cayden Liao
Related in Blockchain

THORChain Exploit Report #2 — GG20 root-cause disclosure

Black Thursday revisited: MakerDAO keeper exploited for $500K
.jpg)