On September 25, 2025, the XRP Ledger shipped version 3.4.1. No amendment vote. No public changelog. No two-week validator approval period. Instead, more than 80% of default UNL validators were already running the new binary on release day โ before the source code was public.
The patch sealed a 64-bit integer overflow in the payment engine. Left open, it could have allowed an attacker to mint XRP beyond the total supply. Silence before the breach. The timeline is what I want to dissect, because the bug is the smaller story.
The XRP Ledger is not an EVM chain. It is a payment and settlement L1 with a native DEX and a path-finding engine. Its core invariant is easy to state and hard to enforce: XRP cannot be created or destroyed outside the genesis allocation and the fee burn. Call it the conservation invariant. It is the ledger's trust root.
XRP's entire valuation rests on a single word: fixed. A hard cap of 100 billion. No inflation schedule, no mint function, no governance lever to dilute holders. Everything else โ the ODL corridors, the exchange listings, the settlement narrative โ is downstream of that cap. Break the cap, and you break the asset.
For roughly a decade, that invariant was assumed to hold. Code review, formal reasoning, and a funded bug bounty program all pointed to the same conclusion. The ledger counts correctly.
Governance runs on amendments. A change to transaction processing requires 80% validator support sustained for two weeks. This is slow by design. The slowness is the security model. It gives the ecosystem time to detect, argue, and exit.
On September 22, a researcher named Cayden Liao submitted a report through the XRPL bug bounty program. The finding was generated with the help of an AI auditing tool, Veria AI. RippleX engineers independently reproduced the mint and confirmed the resulting XRP was spendable. Three days later, the fix was live. Ten days after that, it was public.
The XRPL Foundation later framed the discovery plainly: AI makes this class of vulnerability easier to find for attackers and defenders alike. That framing is honest and strategically useful. It converts a near-catastrophe into evidence that the bounty program works.
Let me lay out the mechanism, because the mechanism is the story. The bug was a classic integer overflow. The exposure path was not.
Reconstructed pseudocode, based on the disclosure:
for each offer in payment_path:
sum_debt += offer.amount_owed // unchecked 64-bit addition
credit(offer.maker, offer.amount_owed)debit(payer, sum_debt) ```
The payment engine totaled the payer's obligations across all routed offers using unchecked 64-bit addition. If the sum overflowed, it wrapped to a very small number. Each offer maker was credited in full. The payer was debited only the wrapped value. The difference was newly minted XRP.
The attack required no exotic access. An attacker opens hundreds of accounts. Each account posts a deliberately mispriced offer โ a tiny amount of some token in exchange for an enormous amount of XRP. A single payment is routed through every offer at once. The sum overflows. The vault is short.
Path payment is the feature that made this exploitable in one transaction. Rather than settling offers sequentially, the engine aggregates a route and computes the payer's total obligation in a single pass. That aggregation is efficient. It is also a single point where the whole route's arithmetic collapses into one number. When that number wraps, the route's integrity wraps with it.
Here is the part that should concern anyone who audits payment rails. Two independent defenses existed. Both failed.
The conservation invariant should have blocked XRP from being created. It didn't. The invariant was computed with the same unchecked arithmetic. The check and the operation shared a single dependency. One unchecked loop, one drained vault. A defense that reuses the vulnerable operation is not a defense. It is a mirror.
A per-account balance limit existed too. It would only trigger if a single account held more than the entire supply. The threshold was set so high it could never fire in practice. This is a control that exists in the documentation but not in the threat model.
In traditional settlement infrastructure, this class of bug is handled by construction. Financial ledgers use arbitrary-precision arithmetic or mandatory overflow checks at every accumulation point, precisely because a wrap in a balance is a silent insolvency. The XRP payment engine instead relied on a downstream invariant that reused the same arithmetic. That is a design choice, not an accident. It is the first thing I would flag in any review.
The attack cost was a few hundred XRP in reserves, recoverable, plus fees. The upside was unbounded issuance. That asymmetry is the signature of a critical finding.
In my own audit work, I have seen this pattern before โ a guard clause that reuses the very arithmetic it is supposed to constrain. On a lending protocol I reviewed in 2020, the liquidation threshold check shared a rounding path with the interest accrual. The check passed because the accrual passed. Both were wrong in the same direction. Single-dependency defenses fail together. That is the lesson XRP just paid tuition on.
Now the governance layer, where the disclosure gets interesting.
This was the first deliberate transaction-processing change in more than a decade that bypassed the amendment vote. The official justification: xrpld is open source. Had the fix gone through the normal two-week vote, the patch would have exposed the vulnerability while the window remained open. Validators could have reverse-engineered the fix and weaponized the bug before the amendment activated.
I accept the logic. I do not accept that it is free.
By the disclosure's own account, 80%+ of default UNL validators were running version 3.4.1 on release day, with source code still private. That is a coordinated private rollout. It requires the ability to distribute binaries and instructions to a supermajority of the validation set ahead of publication. Whatever the network's nominal decentralization, this operation reveals a quasi-permissioned coordination layer underneath it.
A bug that lives for ten years and is found in days by an AI tool tells you something about the audit history, not just the audit tool. The disclosure notes the flaw may have existed since 2015. If accurate, that is roughly a decade of payment-engine code that passed human review. The conservation invariant was verified by the same class of reasoning that missed the overflow. Verification > Reputation โ and reputation had a decade of unearned confidence.
The fix has since been validated. Version 3.4.1 shipped September 25. No evidence indicates the vulnerability was exploited on any public network. A second issue, fixBatchV1_2, was corrected via amendment activation on October 9. Note the contrast: the Batch fix went through the normal amendment path. The payment-engine fix did not. The network used the exception only where it judged exposure risk to exceed process risk. The Foundation confirmed that approximately 99.986 billion XRP exist โ a figure precise to three decimal places, which is itself a trust-repair gesture.
The market is reading this as a technical near-miss. I read it as a governance event with a technical appendix.
Every headline focuses on the overflow. The overflow was fixed in three days. The deeper artifact is the precedent: a core team and a validator supermajority can, under a self-declared exception, ship a transaction-processing change without a vote. The official statement insists this case "does not change how the XRP Ledger makes protocol changes." But the exception is now documented, exercised, and defended. Its boundary is a subjective judgment โ "worse than network downtime" โ held by the same parties who would invoke it.
Code is law, until it isn't. Here, the code that defines "law" was rewritten out-of-band, and the justification was urgency. Urgency is a variable any future actor can claim.
There is also a number worth flagging. Liao publicly stated $9.4 billion was at risk. The official disclosure gave no dollar figure at all. That gap is not a rounding error. It is a difference in incentive: the discoverer benefits from severity; the foundation benefits from calm. Both are motivated. Only one produced a reproducible proof. Verification > Reputation applies to both parties.
And note the disclosure window: fixed September 25, disclosed October 9. Roughly two weeks of asymmetry. I am not alleging misconduct. I am noting that the window existed and that the network has published no monitoring data to close it.
The supply was not corrupted. The trust model was. A ledger whose scarcity guarantee depends on the correctness of a single unchecked addition has told the market exactly where its value anchor sits โ and that the anchor is one code path deep.
The next question is not whether XRP counts correctly. It is who decides when the counting rules can change without asking.