Multi-Send and Batch Transaction Construction

Safe's MultiSend and MultiSendCallOnly contracts are the canonical mechanism for constructing batch transactions that execute multiple operations atomically from a single Safe. Rather than requiring signers to approve and execute each interaction individually—an impractical constraint for DAO treasury operations, protocol parameter adjustments, or complex DeFi position management—the MultiSend pattern encodes an ordered sequence of calls into a single bytes payload. This payload is passed to the Safe's execTransaction function, where it is processed by the MultiSend contract through a delegatecall (for MultiSend) or a series of call operations (for MultiSendCallOnly). The distinction between these two execution modes is the single most important security consideration for any team building batch transaction tooling.

The MultiSend contract uses delegatecall to execute each operation in the batch within the Safe's own execution context. This means each call inherits the Safe's storage, msg.sender, and msg.value, enabling powerful patterns like stateful multi-step deployments or operations that require intermediate storage writes. However, it also introduces a critical security boundary: any delegatecall into an untrusted or compromised contract can corrupt the Safe's storage, potentially overwriting the owner set, guard configuration, or module registry. The MultiSendCallOnly variant eliminates this risk by using standard call operations, executing each transaction in the target contract's context. This is the safer default for most integrations, particularly when constructing batches that interact with external protocols, token contracts, or any address not under the Safe's direct control.

For dApp developers, DAO tooling teams, and wallet integrators, the operational challenge extends beyond choosing the correct MultiSend variant. Batch construction requires precise encoding of operation types (CALL vs DELEGATECALL), correct ABI packing of target addresses, values, and calldata, and careful ordering when operations depend on intermediate state changes. Frontends that allow users to compose batches must validate that delegatecall operations are never directed at user-supplied addresses. Backend services that programmatically construct batches for automated treasury actions or protocol operations must implement rigorous simulation and pre-flight checks. Chainscore Labs can audit batch transaction construction logic, review delegatecall safety boundaries, and help teams build robust simulation frameworks that catch dangerous batch configurations before they reach the signing queue.

Safe's MultiSend contracts are the canonical mechanism for batching multiple operations into a single on-chain transaction. Two variants exist: MultiSend, which executes a sequence of calls via delegatecall, and MultiSendCallOnly, which uses standard call. The core data structure is a tightly packed byte sequence encoding an operation uint8 (0 for call, 1 for delegatecall), a to address, a value uint256, and a dataLength uint256 followed by the data payload. This sequence can be repeated to construct a batch that is executed in order within a single execTransaction from the Safe.

The delegatecall-capable MultiSend is the more powerful and dangerous variant. When an operation type of 1 is used, the target contract's code executes within the MultiSend contract's own storage context. This allows a batch to modify the MultiSend contract's state, which is almost never the intended behavior for standard asset transfers or contract interactions. The primary legitimate use case for delegatecall within a batch is a library-style call that intentionally reads from or writes to the MultiSend's transient storage, a pattern that is exceptionally rare. For virtually all integrations—token transfers, staking, governance voting, and DeFi interactions—the MultiSendCallOnly contract is the correct and safe choice. Using MultiSend without a rigorous understanding of the storage collision risk can lead to silent corruption of the batch executor's state or unexpected reverts.

The atomicity guarantee is a critical operational property: if any single sub-transaction in a batch fails, the entire execTransaction reverts. This is not a feature of the MultiSend contract itself but a consequence of how the Safe core contract invokes it. The Safe's execTransaction makes a single delegatecall to the MultiSend contract, and the MultiSend iterates through the batch. A revert in any sub-operation causes the entire top-level call to revert, unwinding all state changes. This atomicity is essential for operations like DEX swaps that require a multi-hop route or for DAO treasury actions that must be executed as a single logical unit. Builders must design their batch construction logic to handle this all-or-nothing behavior, particularly when constructing batches that interact with protocols that have time-sensitive or non-idempotent operations.

For teams integrating batch transaction construction into custom UIs or backend workflows, the primary engineering challenge is correctly encoding the transaction data and presenting the decoded batch to users for review. The Safe Transaction Service API and client SDKs handle this for standard Safe interfaces, but custom integrators must implement their own encoding and decoding logic. A common failure mode is a mismatch between the operation type presented to the user and the one encoded in the transaction, which could trick a signer into approving a delegatecall they believed was a simple call. Chainscore Labs can audit custom batch construction pipelines, review the safety of delegatecall usage within batches, and verify that user-facing decoding logic accurately represents the transaction's true effects.