The XRP Ledger Bug That Sat Dormant for 11 Years — and Nobody Read the Mechanism

Here is the data. On September 22, a researcher named Cayden Liao and an AI auditing system called Veria AI submitted a vulnerability report to RippleX. Three days later, on September 25, the team shipped xrpld 3.4.1. On October 10, they disclosed it publicly. The bug they fixed had been sitting in the XRP Ledger's core code for roughly eleven years — traceable to 2015. What did it do? It let an attacker mint XRP from nothing. Not a rounding error. A supply-integrity failure that breaks the 10 billion hard cap. The same class of defect as Bitcoin's 2010 value overflow bug, which conjured 184 billion BTC out of thin air. Same family as CVE-2018-17144. The market watched XRP barely move. That is the tell. Nobody read the mechanism. Understand the architecture before you judge the severity. XRP Ledger is not Ethereum. Its exchange is not a smart contract sitting on top of the protocol. It is the protocol. The order book, the matching engine, the cross-currency settlement — all of it lives in the core ledger code. That design has real advantages. Low fees. High throughput. Atomic settlement between assets without a third-party bridge. But it concentrates risk. On Ethereum, a broken DEX is a broken application. You patch the contract and move on. On XRP Ledger, a broken DEX is a broken chain. There is no application layer to absorb the blast. Payment, exchange, and token supply share one attack surface. XRPL runs on a validator consensus model. Protocol upgrades normally move through an Amendment process requiring 80% validator agreement, with an activation window measured in weeks. That timeline exists so the network can agree on behavioral changes before they go live. Keep that in mind. The disclosure timeline is itself textbook. Report to fix in three days. Fix to public disclosure in roughly fifteen. That ordering — patch first, talk second — is responsible disclosure working as designed. Reconstruct the attack. It is elegant, which is why it survived so long. The attacker creates hundreds of accounts. Each posts a standing offer on the built-in DEX — a small amount of one token for a large amount of XRP. Then, simultaneously, the attacker submits a Payment transaction. That Payment triggers offer crossing. The protocol auto-executes against the standing offers. Here is the defect. When the software calculated the total value of the crossed transaction, the math failed. The seller account received its full XRP. The buyer account paid almost nothing. The ledger recorded a settlement that never economically happened. Net effect: XRP created from nothing, credited to the attacker, spendable. This is not a throughput bug. It is a correctness failure in the settlement logic of a payment engine. Severity grade: maximum. Note the asymmetry. A normal XRP transaction burns a tiny amount of XRP as a fee — a drip of deflation. This bug was a flood of inflation. The two mechanisms operate at completely different orders of magnitude. One manages scarcity over years. The other could have erased it in a single block. That is the scale of what almost happened. The comparison set is small and grim. Bitcoin 2010 — 184 billion BTC minted, patched within hours. Bitcoin 2018, CVE-2018-17144 — an inflation bug caught before exploitation. Both were found by people reading code, not price charts. Both share this one's DNA: the failure is not in the economic model, it is in the implementation of the economic model. I have done this work by hand. In 2017 I audited the initial release of the Parity multisig contracts, tracing function calls with a home-built Python script before public launch. I found an integer overflow in the ownership transfer logic. I emailed the team. They patched in 48 hours. That taught me something permanent: a code review without active simulation is theater. You do not find these bugs by reading. You find them by executing the machine against adversarial inputs and watching where the accounting breaks. XRPL's bug lived in a path where offer crossing, payment execution, and multi-asset settlement interacted. That is where accounting errors breed. Now the part the headlines skipped. RippleX says there is no evidence the bug was exploited. Read that carefully. "No evidence" is not "confirmed not exploited." Those are different claims, and the gap between them is where the risk sits. The bug is eleven years old. Chain monitoring in the early years was primitive. If someone ran this in 2016 against a thinner order book, the traces could be faint, or buried in data nobody was watching. I am not asserting exploitation. I am asserting that the confidence interval around "no evidence" is wider than the press release implies. Here is the second blind spot. Everyone framed this as good news — caught and patched. That framing misses the structural signal. A defect that can mint tokens from nothing survived eleven years in a codebase trusted with institutional settlement. Ask the uncomfortable question: if this path was never adversarially tested, what else wasn't? Trust is a variable I solve for, never assume. One dormant supply-integrity bug is not an isolated event. It is a data point about the maturity of the whole code path. Audits reveal intent; code reveals reality. And the reality is that this code only revealed its hole after an outsider — plus an AI system — went looking. That last detail deserves its own line. Veria AI is credited alongside a human for finding a bug human auditors missed for a decade. That is a signal about where security review is heading, and how much of the audit industry was pattern-matching rather than simulating. Watch for a second disclosure. If another researcher surfaces a related defect in the same path, the "isolated bug" narrative collapses and the risk grade moves up. Until then, treat this as an open question, not a closed file. Strip the story. Keep the mechanics. The fix shipped as xrpld 3.4.1. Its effectiveness depends on validator adoption. A client patch nodes do not install is not a fix — it is a proposal. If upgraded and non-upgraded nodes disagree on how a crossed transaction settles, you get a window where consensus and behavior diverge. Watch the adoption rate, not the press release. XRP price did not flinch. The market priced this as a near-miss, not a wound. Fair enough for now. But institutional settlement runs on verifiable scarcity, and "a supply-cap bug existed for eleven years" is now a permanent line in every serious due-diligence file. The market doesn't owe you an exit, only a price. The same is true of code you have not tested. If you hold XRP for the settlement thesis, verify the validator upgrade spread before you assume the hole is closed. And ask the question nobody wants to ask: how many other ledgers are running on trust instead of simulation?