The XRP Ledger spent more than a decade carrying a flaw that violated one of its most basic assumptions: no new XRP can be created after launch.
A vulnerability disclosed on October 9 could have allowed a specially constructed payment to create spendable XRP from nothing. Veria AI researcher Cayden Liao said a proof of concept produced roughly 18 trillion XRP in a single transaction, around 184 times the original 100 billion supply.
There is no evidence the vulnerability was exploited on a public network. RippleX reproduced the issue privately, rated it critical and shipped a fix in xrpld 3.4.1 on September 25.
The extraordinary number is the easy headline. The more interesting part is how the network patched a consensus-critical monetary bug without using its normal two-week amendment process.
The Bug Was an Accounting Overflow, Not a Broken Private Key
The vulnerability lived in the payment engine that consumes offers from the XRP Ledger built-in exchange. Each offer could be valid on its own, but the engine added many large XRP amounts using a fixed-width integer.
When the total became too large, the number wrapped around to a small value instead of failing. Offer owners could receive their full quoted XRP while the buyer was charged only the wrapped total. The difference was newly created XRP.
A safety invariant designed to detect XRP creation used a similar summing method, so it could wrap around too and fail to notice the inflation.
The exploit required hundreds of deliberately abnormal offers and a payment crafted to consume them together. It could not happen through an ordinary retail payment or trade.
The Fix Changed Transaction Processing Immediately
XRP Ledger rule changes normally ship as amendments. Validators vote, and a change activates only after more than 80% support is maintained for two weeks.
The overflow fix did not wait for that process. The patched server rejected overflowing totals as soon as a validator upgraded. More than 80% of validators on the default Unique Node List were already running 3.4.1 on release day.
XRPL developers said the alternative was worse. Publishing a normal open-source release while leaving the vulnerable rule active for weeks would have given attackers a clear exploit path before the amendment could turn on.
That decision exposes a real tradeoff in decentralized protocol governance: predictable activation rules are valuable until following them mechanically would make a critical vulnerability easier to exploit.
The Closed-Source Window Was a Security Tradeoff Too
The binaries for 3.4.1 were distributed before the source code for the sensitive fix was published. Critics described the period as XRP Ledger running closed-source code.
RippleX argued that modern AI-assisted code analysis changes the disclosure problem. A critical patch hidden inside a routine public diff could be identified and reverse-engineered quickly, shortening the safe upgrade window.
The source was later published after the network was protected. That does not make delayed disclosure ideal. It shows why open-source infrastructure needs an incident-response policy for the rare case where immediate transparency can materially increase exploitability.
AI Found the Bug. AI Also Makes Secret Patches Harder
Veria AI says an AI agent found the overflow and built the working proof of concept. RippleX now plans to expand AI-assisted bug hunting and formal verification.
That creates an unusual symmetry. AI can increase the defender ability to search enormous codebases for subtle state combinations, while also making it easier for attackers to inspect a patch and infer the vulnerability it closes.
Optimisus covered a related security tension last week when Ethereum researchers debated whether AI could accelerate cryptographic breakthroughs faster than protocol migration plans expect. The XRPL incident is a more immediate example: AI is already changing vulnerability discovery and disclosure workflows, even when the underlying cryptography remains intact.
A Fixed Supply Is Ultimately a Software Property
XRP is often described as having a hard maximum supply because all 100 billion units were created at genesis and transaction fees destroy small amounts over time.
The vulnerability is a reminder that monetary policy on a blockchain is enforced by code. If code can incorrectly credit balances, the written supply rule is not enough.
Bitcoin, Ethereum, XRP and every other digital asset ultimately depend on implementations correctly enforcing the protocol rules users believe they own.
The good outcome here is that the failure remained hypothetical, a bug bounty found it, validators upgraded rapidly and the invariant itself was hardened with a wider counter.
The more durable lesson is that a decade without exploitation is not evidence that a critical path contains no critical bugs. It is evidence that security review has to remain continuous even after the monetary rules feel settled.
This is not financial advice.
Sources
- XRP Ledger – Vulnerability Disclosure Report for xrpld 3.4.1 – Primary technical disclosure for the payment-engine overflow, remediation and incident timeline.
- The Block – XRP Ledger patches decade-old bug – Independent reporting on the bug, bounty and estimated 18 trillion XRP proof of concept.
- CoinDesk – XRP Ledger patched decade-old XRP minting bug – Independent reporting on the exploit mechanics and emergency release.
