Batch Transaction - QA Test Report

Test Report Date: 9/8/2026
Prepared By: sgramkumar
Environment: GitLab CI Runner (nix-debian)
Network: xrpld devnet + private CI network

Overview

This report presents the results of QA testing performed on Batch (XLS-56) Transactions across xrpld servers. Coverage targets the BatchV1_1 amendment, which supersedes the original Batch amendment and tightened BatchSigner authorization and signing semantics.

1. Feature

Feature Name: Batch (Atomic) Transactions

Description: Prior to this feature, an account that needed several operations to succeed or fail together had no way to bind them atomically; each transaction settled independently, leaving the risk of partial completion. Batch allows an account to package up to 8 inner transactions into a single outer Batch transaction that is processed as one atomic unit. Inner transactions execute under one of four modes — AllOrNothing, OnlyOne, UntilFailure, or Independent — and may be authorized across multiple accounts (BatchSigners), via delegated authority, via multi-signing, or sequenced by tickets. This unlocks reliable multi-step and multi-party workflows on the XRP Ledger.

Specification Reference: https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0056-batch

2. Test Scope

This report covers the full Batch surface as it stands under the BatchV1_1 amendment (xrpld PRs #5060, #6446). Testing focused on ensuring that:

• All four execution modes (AllOrNothing, OnlyOne, UntilFailure, Independent) behave per the XLS-56 specification, including correct commit/rollback semantics
• The 2–8 inner-transaction bounds, fee calculation, and tfInnerBatchTxn rules are enforced
• Multi-account and multi-signed BatchSigner authorization is validated, including canonical signer ordering and the hardened BatchV1_1 signing preimage
• Batch composes correctly with the full range of inner transaction types (Payments, Offers, Checks, Escrow, MPT, Vault/Loan operations, and more), and with the features that have special interaction rules at the batch authorization/sequencing layer — Permission Delegation (inner Delegate field), Sponsored Fees & Reserves (outer/inner Sponsor rules), Confidential MPT (in-batch proof staleness), and Tickets (inner TicketSequence)
• Security-critical properties hold under adversarial input, including malformed BatchSigners, stale-proof inner transactions, replay, and structural/serialization attacks
• Inner-transaction metadata (sfParentBatchID) and same-ledger inclusion are correctly reported

3. Types of Testing Conducted

Testing Type	Description
Functional	Verifying each execution mode, inner-transaction type, fee path, and RPC/metadata surface against the XLS-56 specification
Regression	Running the full xrpld test suite to confirm Batch changes did not break existing functionality
Adversarial / Security	Attack-matrix scenarios probing malformed BatchSigners, signature-binding violations, stale-proof inner transactions, replay, over-size batches, and structural/serialization smuggling
Cross-Feature	Interactions between Batch and Permission Delegation (XLS-75), Sponsored Fees & Reserves, Confidential MPT (XLS-96), and Tickets
End-to-End	Full flows spanning batch assembly, multi-party signing, submission, atomic commit/rollback, and downstream metadata validation via xrpld

4. Test Results Summary

Testing Type	Total Tests
Batch — Core Functional (execution modes, multi-account/multi-sign, tickets/replay/metadata, vault/loan/transaction types, signature & structural validation)	106
Batch — Adversarial / Security	56
Batch — Cross-Feature (Delegation, Sponsorship, Confidential MPT)	27
Batch — Total	189
Regression — xrpld (full suite)	5,088

Testcases: https://dev.to/ripplexdev/batch-transaction-testcases-1klf

Feature commit history:

- Introduced as  Batch  in PR #5060 (2a61aee562, merged 2025-05-23)
- Disabled in v3.1.1 due to a critical bug discovered in the original implementation
- Replaced by  BatchV1_1  (hardened BatchSigners + signing preimage) in PR #6446 (86d8b244d6, merged 2026-07-01)

Related xrpld changes covered in this round:

• PR #5060 — Initial Batch (XLS-56) feature — four execution modes, parentBatchId propagation
• PR #6446 — BatchV1_1 — supersedes Batch/fixBatchInnerSigs, tightens BatchSigner authorization and signing-message construction
• PR #7736 — enforces kMaxBatchTxCount (rejects >8 inner transactions at STTx construction)
• PR #7279 — delegated Confidential MPT inner-transaction cases inside Batch

Related specification change:

• XRPL-Standards updated XLS-0056 to align with the BatchV1_1 implementation (BatchSigners sorting/signing payload, tfInnerBatchTxn common-field semantics)

5. Bugs Reported

All internal bugs are fixed and there are no Critical Open bugs.

6. Conclusion

Batch (XLS-56) Transactions have now been exercised across 189 dedicated tests spanning core functional coverage (four execution modes, multi-account/multi-sign authorization, tickets/replay/metadata, and inner transaction-type coverage), adversarial / security scenarios, and cross-feature interactions with Permission Delegation, Sponsored Fees & Reserves, and Confidential MPT. In addition, the full xrpld (5,088) regression suite has been executed to confirm no downstream breakage.

All security-critical properties documented in XLS-56 have been validated, including:

• Correct atomic commit/rollback semantics for every execution mode (AllOrNothing rolls the whole batch back on any inner failure; OnlyOne, UntilFailure, and Independent apply their defined subsets)
• Enforcement of the 2–8 inner-transaction bounds and rejection of over-size batches before preflight work (PR #7736)
• Correct BatchSigner authorization under the hardened BatchV1_1 signing preimage, including canonical ascending signer ordering and multi-signed BatchSigners
• Correct interaction with delegated authority, sponsorship, tickets, and Confidential MPT inner transactions, including stale-proof rollback under AllOrNothing
• Accurate inner-transaction metadata (sfParentBatchID) and same-ledger inclusion reporting

The feature is considered ready for production use at the tested commit level. Future updates to this report will follow any material additions to the Batch surface.