Compound Transaction

Overview

Compound transactions arise when one user intent requires more than a simple transfer. A decentralized exchange action can approve a token, swap assets, pay a fee, and deposit the result. A merchant payout can split value among several recipients and update accounting records. These actions may be encoded as one Contract Transaction that triggers internal calls, as several instructions in one transaction, or as a coordinated sequence across separate transactions.

The term overlaps with Batch Transaction, but the emphasis is different. A batch groups multiple operations for execution efficiency, while a compound transaction describes a combined outcome whose components depend on one another. A batch can contain unrelated transfers, and a compound workflow can span more than one transaction. Documentation should avoid using the labels interchangeably unless the implementation truly provides the same atomicity and failure behavior.

Risk increases with composition. Each external contract, token, oracle, approval, and callback adds a trust or failure boundary. Transaction ordering, slippage, reentrancy, allowance changes, and intermediate balances can affect the final result. A top-level success status may not reveal whether every expected transfer occurred, particularly when a contract catches errors or uses optional branches. Simulation and event decoding should be matched with post-state checks.

Payment systems should represent the compound action as a business workflow with explicit components rather than as one opaque hash. They should store the top-level transaction, internal calls or instructions, expected outputs, actual outputs, and recovery state. Idempotent retries are especially important because resubmitting a partially completed workflow can duplicate transfers. The relevant settlement decision should reflect the complete intended outcome, not merely the inclusion of the outer transaction.