XRPL's October 9 security report describes a second, independent flaw in the Batch transaction feature. Unlike the payment-engine overflow, this bug threatened ledger availability and data compatibility, not the supply of XRP. A crafted inner-transaction wrapper could have been interpreted differently by servers on different versions. The developers say Batch had not been activated on Mainnet when the bug was found, and no funds were lost and no consensus failure occurred.
Why a field name could split a network
Batch allows a group of signed transactions to be submitted together. Each inner transaction is supposed to be carried inside a field called RawTransaction. The faulty validation logic accepted other object-type wrapper fields if that field had no restrictive template.
Older xrpld 3.3.0 and newer 3.4.0 defined different object fields. A deliberately nonstandard Batch payload could be accepted and relayed by one version but fail deserialization in another. If enough validators ran the incompatible combinations, the trusted validator group could disagree on the contents of a ledger and potentially stop validating new ledgers.
The technical issue is distinct from private-key theft. Every inner transaction still required ordinary valid signatures and balance checks. The attacker could not simply authorize another user's payment without that user's signature. The exploit incentive was disruption, not a direct unauthorized asset transfer.
Indexers could have retained a permanent problem
Even without a consensus stall, a malformed Batch accepted into the chain's immutable history could have broken SDKs and block explorers that assume the expected RawTransaction wrapper. Such history cannot be rewritten without invalidating signatures. Clients would then require permanent special-case handling of the malformed record.
The critical security insight is that transaction serialization rules must be consensus rules, not an accidental consequence of which fields a particular binary version recognizes.
Why mixed-version consensus is more dangerous than a local parser bug
A network node that cannot parse a malformed record might simply stop serving some API requests. A validator that assigns different meaning to the same proposed transaction can create a broader consensus problem. If one software version sees a transaction as acceptable and another cannot deserialize it, the versions no longer agree on what state transition they are being asked to approve. That is a liveness risk even when no attacker has obtained anyone's keys.
The wrapper rule closes the ambiguity at the transaction layer: the inner transaction must appear under the one specified RawTransaction field. Once every active validator rejects alternatives consistently, a client and an indexer can rely on the same wire-format expectation. The remedy addresses a subtle but important class of protocol bugs in which a serialization boundary accidentally becomes a source of divergent consensus rules.
How activation was delayed and the fix sequenced
The original finding came from a Sherlock Attackathon and initially received a low-severity rating. Denis Angell of the XRPL Foundation found on September 18 that the previous fix was incomplete. On September 22, RippleX identified mixed-version consensus risk and escalated the issue to a release blocker.
The network's planned BatchV1_1 activation was then delayed: Ripple and other validators withdrew supporting votes, resetting the timer. On September 25, xrpld 3.4.1 shipped a new fixBatchV1_2 amendment. The fix and BatchV1_1 both activated on October 9, with the fix slightly ahead of the feature.
After activation, a Batch using an unexpected wrapper is rejected with temMALFORMED. The fix is scoped to wrapper validation, and older nodes unable to support the active amendment become amendment-blocked.
Why this deserves separate monitoring from the XRP overflow
The two flaws shared a release, not an attack path. One involved checked arithmetic and token-supply invariants; this one involved serialization and differing interpretations of consensus data. A custodian or exchange's operational response differs too: there is no known need for user token migration, but XRPL infrastructure operators must run compatible software and confirm indexing services handle the active Batch amendment.
Evidence Status: Confirmed / Official. The disclosure, release, votes and activation sequence are documented by XRPL. Loss: None reported. Risk Level: High as a potential network-liveness vulnerability, with the relevant fix active before Batch became usable on Mainnet.
