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.