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. Read original: https://dev.to/ripplexdev/batch-transaction-qa-test-report-5g5g