XRP Ledger Fixes Critical Bug, Confirms 100B Supply Safe

What happened and why it matters

The XRP Ledger (XRPL) team disclosed and patched a critical vulnerability in the network's payment engine that, in a worst-case scenario, could have allowed an attacker to create spendable XRP far beyond the protocol's hard-capped 100 billion supply. The bug originated in legacy code from 2015 and was discovered during automated security testing by Veria AI and security researcher Cayden Liao. XRPL contributors and RippleX issued an emergency software update, xrpld 3.4.1, and validators moved quickly to install the fix. The incident highlights important lessons about open-source security, responsible disclosure, and validator coordination for blockchain networks.

Key takeaways

Immediate facts

• The bug was a 64-bit integer overflow in the XRPL payment engine that handled multi-offer payments and order book interactions.
• Security researchers demonstrated a proof-of-concept showing roughly 18 trillion XRP could be produced by a specially crafted transaction under laboratory conditions. That amount equates to approximately 184 times the ledger's intended 100 billion supply.
• XRPL contributors released xrpld 3.4.1 as an emergency patch, and more than 80% of default validators upgraded within days, preventing exploitation on mainnet.
• The XRPL Foundation and RippleX reported no evidence that the vulnerability was used on public networks, and no user funds or private keys were compromised.
• The researcher who reported the issue through the official bug bounty program received the maximum reward of $250,000.

How the vulnerability worked: a technical explanation

The flaw stemmed from arithmetic limits in legacy code handling payments that span multiple offers in the decentralized exchange and order book. When the XRPL payment engine aggregates XRP amounts across many offers, it used a 64-bit integer to compute the total amount owed by a buyer in a single multi-offer settlement.

An integer overflow occurs when a calculation exceeds the maximum value that can be stored in the chosen integer type. In this case, researchers showed an attacker could place hundreds of specially priced offers and craft a single atomic payment transaction that consumed many of them. If the aggregated total exceeded the 64-bit limit, the integer could wrap around to a much smaller number. The engine would then mistakenly allow the payment to process while still crediting sellers with the full original offer amounts. The difference between the wrapped-around buyer amount and the full seller credits would effectively create new XRP out of thin air.

Importantly, this was not an ordinary trading scenario. Exploitation required a deliberate sequence: creating many accounts and offers with extreme pricing, then executing a single, carefully constructed transaction to trigger the overflow. The supply verification routine used the same arithmetic, so it did not detect the created XRP. Additionally, the newly minted balances could be distributed across multiple accounts to bypass simple balance checks.

Discovery and disclosure: timeline

September 21 2026

Veria AI's automated security tooling flagged a potentially dangerous condition inside the open-source XRPL codebase. Automated fuzzing and targeted tests surfaced the integer overflow scenario.

September 22 2026

Researchers built a working proof-of-concept on a local testnet environment, demonstrating the mechanics and the potential scale of the issue. Cayden Liao submitted the finding to the XRPL bug bounty program via coordinated disclosure.

September 23 2026

RippleX engineers reproduced the behavior on an isolated server and confirmed that a crafted multi-offer payment could produce spendable XRP in a subsequent transaction.

September 25 2026

After rapid engineering and review, the XRPL community released xrpld 3.4.1 as an emergency security update. The patch added defensive checks to prevent calculations that exceed permitted integer ranges and replaced fragile arithmetic with wider counters to strengthen supply verification.

October 8 2026

Veria AI received the $250,000 maximum bug bounty for responsible disclosure.

October 9 2026

A follow-on disclosure addressed a separate validation issue tied to the Batch transaction feature, which was patched and safely activated that day.

Emergency deployment and governance implications

XRPL implements protocol changes through its amendment system, which normally requires more than 80% support from trusted validators for two consecutive weeks before activation. Because publishing a patch in the public repository can disclose both the flaw and its remediation, the XRPL community judged that waiting through the regular amendment timetable would create an unacceptable risk window. Attackers could have studied the public fix to craft exploits while the amendment was pending.

To reduce immediate risk, developers and validator operators coordinated an emergency upgrade: the fix became effective as validators installed xrpld 3.4.1. This emergency path carries operational trade-offs, including the risk of temporary disagreement if validators run different software versions. Network proponents emphasized their decision was made in consultation with validator operators, RippleX, and the XRPL Foundation, and they prioritized rapid mitigation over the usual amendment timeline. By September 25, over 80% of default validators had upgraded, avoiding a prolonged exposure period.

Batch transaction vulnerability and amended rollout

The October 9 disclosure included a separate issue with the Batch transaction feature. Batch allows grouping up to eight transactions into a single, atomic operation. During testing, researchers found a validation discrepancy in how individual transactions within a Batch were packaged. Specifically, the protocol expects the RawTransaction field for each component. Under certain conditions, alternative field names could be accepted by some server versions, which risked cross-version disagreement about transaction validity.

If Batch had activated with this validation inconsistency unresolved, the network could have experienced a consensus disruption. XRPL developers introduced the fixBatchV1_2 amendment, requiring the approved field format and rejecting malformed Batch entries. As a result, developers delayed the original BatchV1_1 activation schedule to apply the correction. Both fixBatchV1_2 and BatchV1_1 were activated on mainnet on October 9 after sufficient validator support. Servers still running older versions are now amendment blocked and must upgrade to xrpld 3.4.1 or later to remain in consensus.

Was any XRP actually created on mainnet?

No verified evidence indicates that any XRP was created or moved illicitly on public networks. The researchers demonstrated potential exploitation in a controlled environment only. XRPL contributors, RippleX, and the XRPL Foundation examined ledger history and network behavior and reported no signs of unauthorized currency inflation. No user funds were lost and no private keys were compromised.

Despite the lack of public exploitation, the severity was upgraded to critical because of the magnitude of the potential supply inflation and the plausibility of an attacker engineering the required multi-offer conditions.

Why the bug mattered for market integrity

The XRPL's fixed 100 billion supply is a core property relied upon by exchanges, custodians, market makers, and retail traders. Any credible path to creating new spendable XRP would call into question ledger scarcity, exchange balances, and price stability. In speculative terms, security researchers estimated the exposure by reference to a market capitalization figure near the time of discovery. However, that number reflected potential financial risk, not realized loss.

Quick detection and the coordinated emergency patch prevented an exploit window that could have threatened market confidence. The bug bounty payout and the transparent disclosure process also reinforced a model for responsible vulnerability reporting in the crypto space.

Response from the community and next steps

The XRPL Foundation has announced changes to its release verification process. Going forward, previously reported security issues must be re-tested against release candidates before a fix is classified as resolved. This additional verification requirement will apply to findings from audits, bug bounty submissions, AI-assisted security testing, and other assessments. The measure aims to close gaps between detection and successful remediation and to reduce the possibility of regressions.

Validator operators have emphasized the importance of maintaining current software and participating in timely upgrades. The incident also underscores the benefits of automated security testing, coordinated disclosure, and financial incentives for white-hat researchers.

What this means for exchanges, custodians, and users

• Exchanges and custodians should confirm they rely on validators that run up-to-date xrpld versions and that their deposit and withdrawal processes validate ledger state consistently.
• Developers building on XRPL should upgrade test environments and audit code paths that interact with order books, multi-offer payments, and the decentralized exchange to ensure they handle edge cases safely.
• Users should be reassured that no known exploit occurred on mainnet, but they should continue to follow standard security hygiene such as using trusted wallets and secure key management.

Lessons for blockchain security

Several broader lessons emerge from this incident:

• Legacy code can hide systemic vulnerabilities. Even well-established, open-source projects need ongoing automated and manual audits.
• Coordinated disclosure and meaningful bug bounties produce better outcomes than public exposure without mitigation. The $250,000 reward in this case incentivized responsible handling of a high-severity issue.
• Governance mechanisms must balance decentralization and safety. Amendment systems protect against unilateral changes but can slow emergency responses. The XRPL community selected a pragmatic emergency path to minimize risk exposure.
• Cross-version consensus risks deserve special attention for any feature that changes transaction semantics. The Batch vulnerability reinforced the need for cautious, version-aware rollouts.

Final thoughts

The XRPL security incident showed how a decades-old arithmetic assumption could create a theoretically catastrophic failure mode for a major cryptocurrency. Fortunately, modern security tooling, responsible research, and fast coordination between RippleX, the XRPL Foundation, and validator operators prevented exploitation on mainnet. The community responded with emergency patches, an extra verification requirement for future releases, and a transparent disclosure that balanced technical detail and risk communication.

For traders, developers, and institutions interacting with XRPL, the episode is a reminder that blockchain systems are software projects that require continuous security vigilance. It also demonstrates that the ecosystem can respond effectively when vulnerabilities are discovered responsibly.

Continue to follow verified XRPL Foundation, RippleX, and reputable crypto news sources for updates on xrpld releases, validator guidance, and any new advisories relating to the XRP Ledger.