XRP Ledger Flaw Found by AI Exposed an 18.45 Trillion XRP Minting Path

Veria AI found an XRP Ledger flaw that researchers say could mint 18.45 trillion XRP, despite the cryptocurrency’s fixed 100 billion supply.

The exploit combined faulty arithmetic in the ledger’s payment engine with a safety check that repeated the same mistake. A specially constructed payment could credit hundreds of seller accounts while charging the buyer almost nothing.

RippleX reproduced the exploit, classified it as critical, and released xrpld 3.4.1 on September 25, 2026. The official disclosure says investigators found no evidence that anyone exploited the vulnerability on a public network.

That distinction matters. This was not an 18 trillion XRP theft, nor did the theoretical amount carry a realizable market value. It was a credible path for violating XRP’s defining supply rule.

The incident also tests a larger promise surrounding AI-assisted security. An AI agent apparently found a decade-old defect that audits and conventional testing had missed. Yet human researchers still had to validate the result, coordinate a confidential repair, and persuade validators to upgrade.

The XRP Ledger Flaw Was Patched Before Public Disclosure

The immediate story is a successful emergency response to a vulnerability that had remained reachable for nearly a decade.

Veria Labs says it directed its security agent at rippled, the open-source server software used by the XRP Ledger. The company says its system identified the vulnerable code, developed a working exploit, and tested it on a local network.

The firm’s technical reconstruction dates the initial AI finding to September 21. The system produced a working proof of concept the following day, according to Veria.

Researcher Cayden Liao reviewed the result and reported it through the XRPL bug bounty program on September 22. RippleX engineers confirmed the issue that day after reproducing it on a standalone server and inside their test framework.

The confirmation went beyond showing a bookkeeping discrepancy. RippleX established that the newly created XRP could be transferred in a later payment, making the output operationally spendable.

Developers merged a fix on September 23 and released rippled 3.4.1 two days later. Public disclosure waited until October 9, after operators had received time to install the repaired software.

Veria says more than 80 percent of validators were running the release on September 25. The official XRPL account similarly reports that over 80 percent of validators on the default Unique Node List upgraded that day.

A Unique Node List, or UNL, identifies the validators that a server trusts when evaluating consensus. Rapid adoption among those validators reduced the danger created by older nodes continuing to accept the vulnerable transaction.

The response departed from the normal route for changing transaction behavior. XRPL generally introduces consensus-sensitive changes through amendments, which validators consider before activation.

Developers instead placed the overflow repair directly into the server release. They withheld the relevant source changes temporarily, limiting the chance that attackers could reverse-engineer the vulnerability before enough validators had upgraded.

That choice concentrated trust in maintainers and validator operators for a short period. It also prevented a public amendment process from becoming an instruction manual for an immediately exploitable inflation bug.

The official report says the XRPL Foundation, RippleX, and participating validators considered the confidential upgrade safer than leaving an open exploit available for weeks. The fix became public after the network crossed the necessary safety threshold.

Veria received the maximum critical bounty of $250,000 on October 8. The amount recognizes the severity rating, but it should not be confused with a measured loss.

No unauthorized XRP was found, no user funds were reported missing, and no public ledger transaction has been tied to the exploit. The emergency concerned what the code accepted, not damage already observed.

That outcome makes the event easy to minimize. However, avoiding exploitation does not reduce the importance of a defect that could invalidate the asset’s fixed-supply assumption.

How the XRP Ledger Flaw Could Create Spendable XRP

The exploit worked because two monetary safeguards performed vulnerable calculations in nearly the same way.

The first defect appeared in the payment engine’s handling of offers from the XRP Ledger’s built-in decentralized exchange. Offers allow accounts to exchange XRP or issued assets through the ledger’s order books.

An attacker would begin by creating many controlled accounts and issuing a worthless token. Those accounts would then place hundreds of artificial offers demanding extremely large XRP amounts for that token.

Veria’s proof of concept used 256 offers. Each requested slightly more than 2^56 drops, with one drop representing one-millionth of an XRP.

The attacker would then submit one payment designed to consume the entire collection of offers. The payment engine had to add the XRP amounts associated with every offer before charging the buyer.

That total exceeded the capacity of the unsigned 64-bit integer used for the calculation. An integer overflow occurs when a value passes its permitted maximum and wraps around to a much smaller number.

Here, the aggregate crossed 2^64 drops. The individual offer owners could receive their full amounts, while the overflow made the buyer’s combined charge appear to be only 256 drops.

This was more serious than an incorrect exchange quote. The credited balances represented XRP that no source account had supplied.

The result was approximately 18,446,744,073,709 XRP, before accounting for the source debit and transaction fee. Veria summarizes the usable output as about 18.45 trillion XRP across 256 accounts.

That distribution was essential. XRPL applies a limit to the XRP held by any single account, but each recipient stayed below that ceiling.

The attack therefore bypassed one safeguard by dividing the new XRP across many accounts. Researchers say the credited XRP could then move through ordinary payments or reach exchanges.

XRPL also had an invariant intended to prevent precisely this outcome. An invariant is a post-transaction safety condition that must remain true before the ledger accepts a change.

The XRPNotCreated invariant calculated the net XRP balance change across the transaction. It should have rejected any result showing that the transaction created more XRP than it destroyed through fees.

However, that calculation used arithmetic vulnerable to the same overflow. The net change wrapped around until it resembled an ordinary fee burn, allowing the transaction to pass.

In effect, the payment engine miscounted what the buyer owed. The independent-looking supply check then repeated the mathematical failure and approved the false result.

This shared failure is the critical design lesson. A backup control offers limited protection when it relies on the same data type, arithmetic behavior, or assumption as the component it monitors.

The attack was not something an ordinary trader could trigger accidentally. It required hundreds of deliberately priced offers and a payment engineered to consume them together.

It also required some XRP for account and offer reserves, plus transaction fees. The vulnerability report estimates the requirement at a few hundred XRP, with most reserves recoverable afterward.

The attacker did not need to control a validator. Once prepared and signed, the exploit transaction would enter the network as an otherwise ordinary payment.

The attack was also repeatable. Additional groups of controlled accounts could recreate the setup, allowing another 18.45 trillion XRP batch.

The repair introduced overflow checks into the offer-summing code. A total that exceeds the permitted range now fails instead of wrapping into a small charge.

Developers also widened the accumulator used by the supply invariant. Additional balance-summing paths received related hardening to reduce the chance of another shared arithmetic failure.

A Fixed Supply Made the Potential Damage Systemic

The real exposure was not the impossible face value of 18.45 trillion XRP, but the credibility of every legitimate unit already circulating.

XRP began with a total supply of 100 billion tokens. It is not produced through mining or staking, and ordinary transaction fees destroy small amounts over time.

That design gives users a simple monetary expectation. Transactions can redistribute XRP, but they should never increase the total supply.

The XRP Ledger flaw violated that rule at the accounting layer. If exploited, it could have placed newly created XRP into normal accounts without visibly marking those balances as different.

The reported 18.45 trillion output was about 184 times the original supply. However, multiplying that quantity by the market price produces a misleading measure of economic damage.

An attacker could not sell trillions of XRP at the pre-attack price. Available liquidity would disappear, exchanges could suspend trading, and the price would respond long before most tokens reached a buyer.

The more meaningful reference was XRP’s roughly $94 billion market capitalization when Veria assessed the vulnerability. That represented the value whose underlying scarcity assumption faced pressure.

Even this figure is not a guaranteed loss estimate. Market capitalization does not equal cash stored inside a network, and different holders would experience different outcomes.

The systemic risk came from confidence. Unauthorized issuance could dilute existing holders, overwhelm exchange liquidity, disrupt applications, and raise questions about the ledger’s accounting guarantees.

Institutions would also face operational uncertainty. Exchanges might need to identify affected deposits, payment providers could pause settlement, and custodians might restrict withdrawals during an investigation.

Those responses could harm legitimate users even if an attacker captured only a small portion of the headline amount. A supply failure spreads beyond the accounts directly involved.

This helps explain the confidential release. Maintainers were protecting both the protocol and the response window available to exchanges, validators, and infrastructure providers.

The flaw had likely existed since the payment engine was written in 2015. A second weakness in the supply invariant dated to 2017, according to Veria’s analysis.

That timeline puts pressure on the idea that longevity alone proves safety. Software can process billions of transactions while retaining an exploit path that normal activity never exercises.

Ripple said in March that XRPL had processed more than 100 million ledgers and three billion transactions since 2012. Those figures demonstrate extensive use, but they do not cover every possible arithmetic state.

The rare input mattered here. Normal payments could not approach the value required for the overflow because the legitimate XRP supply was far below that threshold.

An attacker had to fabricate extreme order-book values across many offers. Conventional tests based on plausible economic behavior may never have explored that combination.

Audits also did not eliminate the risk. Veria says the codebase underwent more than a dozen audits or audit contests from 2024 onward, alongside an established bounty program.

This does not prove that the audits were careless. Audits operate within time, scope, and incentive constraints, while rare interactions can remain hidden across separate components.

The lesson is narrower and more useful. Mature financial code needs tests that challenge machine limits, not only scenarios that resemble ordinary user behavior.

AI Security Found the Bug, but Humans Contained It

The discovery supports AI-assisted security, while the response shows why autonomous scanning is only one layer of protocol defense.

Veria attributes both the discovery and exploit construction to its AI security agent. The company says the system analyzed rippled, connected the two arithmetic weaknesses, and built a working local proof of concept.

That account is significant because the vulnerability required cross-component reasoning. Finding the payment overflow alone would not guarantee success if the supply invariant rejected the transaction.

The agent reportedly recognized that the invariant repeated the overflow. It then designed an input that triggered both failures inside one transaction.

Veria’s claims have meaningful external support. RippleX independently reproduced the exploit, confirmed the spendability of the minted XRP, and raised the report from major to critical.

The official XRPL disclosure does not provide a full evaluation of the agent’s autonomy. It confirms the report and technical result, but it does not independently measure how much human direction produced the discovery.

That gap matters when assessing AI security products. A successful finding can involve automated code analysis, human-authored prompts, iterative review, and manual exploit validation in different proportions.

The incident still provides more evidence than a benchmark score. It led to a confirmed critical vulnerability, a production release, and a maximum bounty payment.

Ripple had already announced a broader AI security program in March 2026. That program combined AI-assisted testing with a dedicated red team, fuzzing, formal verification, and stricter amendment review.

Fuzz testing feeds software unexpected or malformed inputs to expose crashes and invalid states. Formal verification uses mathematical techniques to test whether software satisfies defined properties.

Those methods address different failure modes. AI can inspect code and propose attack paths, fuzzers can explore input spaces, and formal methods can test critical invariants.

Human engineers still decide whether a finding is reachable, whether its impact is real, and how to repair it without disrupting consensus. They also manage disclosure across a decentralized operator base.

The XRP Ledger response illustrates this division clearly. The agent found the path, Liao reviewed it, and RippleX reproduced the exploit in controlled environments.

Developers then changed multiple arithmetic paths. Validator operators installed the release, while maintainers monitored adoption before disclosing the details.

No single participant controlled the entire outcome. The system depended on cooperation among a private security company, open-source developers, a foundation, RippleX, and independent operators.

That coordination is a strength because several parties examined the finding. It is also a governance dependency that deserves scrutiny.

The emergency patch was distributed before the source-level explanation became public. Validators had to decide whether to trust the release without receiving the normal transparency available for routine changes.

The alternative carried its own danger. Publishing the exact overflow mechanics before broad adoption would give attackers a working path against every unpatched validator.

This is the central tradeoff, not a simple contest between AI and human auditing. Faster discovery increases the value of fast, trusted, and carefully governed response procedures.

The same tools that help defenders inspect old code can also help attackers search for equivalent mistakes. RippleX engineer Mayukha Vadari warned in the disclosure that AI changes the timing around vulnerability discovery and exploitation.

A mature program therefore needs more than better scanners. It needs rehearsed confidential disclosure, clear severity standards, validator communication channels, and measurable upgrade readiness.

What the XRP Ledger Flaw Does Not Prove

The confirmed exploit was severe, but several headline interpretations go beyond the available evidence.

First, there is no evidence that 18.45 trillion XRP entered a public ledger. Researchers created the output in a controlled environment while validating the vulnerability.

Second, no source has established that attackers knew about the path before Veria reported it. The age of vulnerable code describes exposure time, not confirmed adversarial knowledge.

Third, the claimed $94 billion at risk should not be treated as a forecast loss. It describes the market whose scarcity guarantee faced potential damage.

Fourth, the incident does not establish that an AI system independently completed every stage of research. Veria provided the most detailed account of the agent’s role, while humans performed review and disclosure.

These caveats do not make the finding theoretical in the dismissive sense. RippleX reproduced the transaction and confirmed that a follow-up payment could spend the new XRP.

The vulnerability also reached production code. This was not a proposed feature caught before activation, unlike a separate Batch transaction issue repaired in the same 3.4.1 release.

Combining those incidents can create confusion. The Batch flaw concerned wrapper validation and possible disagreement between server versions.

That Batch amendment had not activated on the main network. Validators handled its repair through amendment voting, and the corrected version activated on October 9.

The XRP overflow followed a different path. It affected existing payment-engine behavior and was repaired immediately when nodes installed version 3.4.1.

The release record therefore contains two security fixes with different exposure and governance histories. Only the payment overflow created the alleged minting path.

Another uncertainty concerns historical detection. XRPL says it found no evidence of exploitation on public networks, but readers should distinguish “no evidence” from an absolute proof of absence.

An attacker using the exploit would create unusual balance changes and order-book activity. Those artifacts should aid retrospective analysis, especially given the need for hundreds of artificial offers.

However, the public disclosure does not present a complete forensic methodology or an independently audited search of ledger history. Its conclusion remains the maintainers’ reported finding.

The network’s rapid upgrade also deserves continued examination. More than 80 percent adoption among default-UNL validators reduced immediate exposure, but other nodes and infrastructure providers follow different schedules.

Older software cannot be made safe by a disclosure statement. Operators running rippled 3.4.0 or earlier remain responsible for upgrading.

Finally, this event does not show that AI has made blockchain auditing complete. It shows that one AI-assisted process found one important bug in a mature codebase.

The next test is repeatability. Security teams need evidence that similar systems find diverse, previously unknown vulnerabilities without flooding maintainers with weak reports.

They also need to evaluate adversarial use. Faster defensive discovery is valuable only when repair and deployment can outrun malicious reproduction.

Three Signals Will Show Whether the Security Model Improved

The next phase should be judged through code, validator behavior, and independently reproducible security results.

The first signal is continued adoption of rippled 3.4.1 or later. The critical overflow repair applies during software installation, so outdated nodes remain the clearest avoidable risk.

Public validator telemetry should show the vulnerable versions disappearing from meaningful consensus roles. Slow adoption would weaken the claim that XRPL can coordinate under urgent conditions.

The second signal is a technical review of monetary invariants beyond this specific patch. The failed supply check shared arithmetic behavior with the component it was supposed to monitor.

Developers should test other totals, conversions, and balance paths with wider accumulators and explicit overflow handling. Independent review would strengthen confidence more than another general assurance.

The third signal is evidence that AI-assisted testing produces repeatable findings under responsible disclosure. Confirmed vulnerabilities, low false-positive rates, and clear human oversight would support Veria’s broader claim.

A stream of sensational but unverified reports would weaken it. So would findings that require extensive undisclosed human reconstruction before they become actionable.

The incident already changes the security baseline. Long operation, previous audits, and a declining-supply design did not prevent a machine-limit error from threatening XRP’s core monetary rule.

At the same time, the response worked before a public exploit appeared. Researchers reported the issue, engineers reproduced it, and validators installed an emergency repair within days.

Developers and infrastructure operators should now ask whether their own safety checks fail differently from the systems they supervise. A duplicated assumption is not true defense in depth.

For readers tracking the XRP Ledger flaw, the most useful action is to watch version adoption, independent code review, and future bounty disclosures. Those signals will reveal whether this was an isolated repair or the start of a stronger security model.