XRPL Activates Batch Security Fix

XRP Ledger completed the network stage of a Batch transaction correction on October 9, 2026, when the fixBatchV1_2 amendment became active on Mainnet. The rule change followed the September 25 release of xrpld 3.4.1. That software release addressed the Batch validation problem and a separate arithmetic flaw in the payment engine.

The official disclosure treats the two findings as distinct issues. One concerned the object used to wrap an inner transaction inside a Batch. The other concerned the way XRP amounts were added when a payment crossed many offers in the decentralized exchange order book. Their different mechanics explain why they did not share one activation method.

For the Batch problem, affected versions did not insist that every inner transaction use the required RawTransaction container. A specially encoded transaction could use another object field and still be accepted. The inner operation still needed a valid signature and sufficient balance, but the resulting record could be non-standard and could be interpreted differently by server releases that knew different object fields.

XRPL said the relevant Batch amendments had not been enabled on Mainnet when researchers found the defect. On that basis, the project reported that Mainnet accounts and funds were not affected by this Batch issue. The correction nevertheless mattered because mixed server versions could disagree over whether an unusual Batch was valid, creating a risk to consistent ledger validation after the feature became active.

Why the two fixes followed different paths

The Batch correction changes a shared transaction rule, so XRPL delivered it through an amendment. Once fixBatchV1_2 is active, an entry that places an inner transaction in a wrapper other than RawTransaction is rejected as malformed. Applying that requirement at the same ledger boundary prevents acceptance from depending on which object types a particular server version happens to recognize.

The payment-engine flaw required a faster software response. It could arise when one payment consumed hundreds of deliberately prepared offers. Every offer amount could fit within the allowed integer range, while the running total could exceed that range and wrap to a smaller number. The seller credits could then exceed the amount charged to the buyer.

The report also explains why an existing supply invariant was not enough. That check used arithmetic capable of wrapping in the same way, so an extreme total could evade the intended comparison. Version 3.4.1 adds checks to the order-book total and to totals combined across payment paths. It also uses a wider counter for the separate no-XRP-created safeguard.

XRPL stated that it found no evidence of public-network exploitation. That statement is the project’s conclusion from its investigation, not a guarantee that every historic transaction has been independently reviewed. The technical report says an exploit would have needed a deliberately constructed group of offers and a payment designed to consume them together; ordinary payments and trades did not meet that condition.

The operator consequence is concrete. Servers needed xrpld 3.4.1 or a newer release before the amendment became active. Older servers became amendment blocked rather than continuing to participate under an incompatible rule set. This separates the user-facing headline about an activated fix from the operational requirement that made the activation safe across validators.

What the disclosure establishes

The report establishes that two bugs were disclosed, corrected in xrpld 3.4.1, and handled according to their network effects. It does not establish that XRP was created through the payment flaw or that Mainnet funds were lost through the Batch flaw. Those outcomes are specifically outside the project’s reported findings.

Readers should also distinguish release date from activation date. Shipping corrected code on September 25 protected an upgraded server from the payment overflow immediately. The Batch behavior changed for the network only when the amendment gained support and became active on October 9. Using one date for both events would blur the difference between software availability and consensus-rule enforcement.

The useful lesson is procedural. A blockchain defect can require a local binary upgrade, a coordinated amendment, or both. The deciding factor is whether the correction changes only how one server performs a calculation or changes which transactions every validator must accept. XRPL’s disclosure documents both cases in the same release cycle without presenting them as the same vulnerability.

• Node operators should run xrpld 3.4.1 or newer after the Batch amendment activation.
• The Batch correction enforces the RawTransaction wrapper for inner operations.
• The payment correction checks totals before integer overflow can occur.
• The project reported no evidence that either issue was exploited on a public network.

Denne artikkelen er kun for informasjon og er ikke investeringsrådgivning.

admin_wcContributor · World-CryptMore from