Transaction Bundle

Overview

A bundle packages several signed transactions with an intended order. A searcher may need one transaction to buy an asset and another to sell it, with the strategy becoming unprofitable if only one executes. A wallet or smart-account system can bundle several user operations for convenience.

Some builder services support all-or-nothing semantics within one candidate block. Others only preserve order or attempt inclusion without a strict atomic guarantee. The blockchain’s normal transaction rules still apply, and the block producer can reject an invalid bundle.

Bundles can reduce public mempool exposure and front-running, but they introduce trust in builders, relays, or sequencers. The submitter may not know whether the bundle was shared with other parties or why it was excluded. Competing bundles can also depend on the same state.

Applications should monitor every transaction hash and the final block position. A bundle accepted by a relay is not confirmed. Reorganizations can remove the containing block, and one transaction can fail if the bundle’s conditions were not actually atomic.

Fee and incentive design matters. The bundle may include priority fees, direct producer payments, or conditional rewards. Documentation should state ordering, privacy, cancellation, and partial-execution rules clearly before critical workflows rely on it.

Bundle simulation should run against the expected block state and account for competing transactions that may alter profitability or validity. Submitters should define a deadline or target block so stale bundles do not execute under very different conditions. When partial execution is possible, the application needs compensation or rollback logic at the business layer. Bundle monitoring should record relay responses, target blocks, inclusion outcome, and reasons for rejection when available.