Transaction Bundles

Overview

A transaction bundle is an ordered list of signed transactions that execute atomically:

1. Transactions execute sequentially in bundle order.
2. If any transaction fails, the entire bundle is reverted.
3. State changes are committed only after all txs succeed.
4. Gas is charged for all executed transactions up to the failure.

Bundles are useful for multi‑step workflows, on‑chain arbitrage, and ensuring interdependent actions either all succeed or none do.

Bundle Structure (Conceptual)

A bundle includes:

• txs: ordered list of signed transactions
• tip: optional incentive for block builder prioritization
• bundle_nonce: prevents bundle replay
• authorizer: address that authorizes the bundle
• signature: authorizer signature over the bundle hash

Max size: 32 transactions per bundle.

When to Use Bundles

• Atomic multi‑step actions (e.g., approve → swap → transfer)
• Arbitrage across multiple pools
• Conditional sequences where partial success is unacceptable

Simulation First

Always simulate before submission:

• Use chain_simulateBundle to check ordering, dependencies, and gas
• A failing transaction will revert the whole bundle
• Simulations are only valid for the current chain head

See /guides/tx-simulation/ for general simulation guidance.

RPC Workflow

Bundle submission is currently exposed via RPC:

• tx_submit_bundle — submit an atomic bundle
• chain_simulateBundle — simulate a bundle with dependency analysis

Refer to /reference/rpc-api/ for request/response types.

Notes and Tips

• Ordering matters: hash and execution depend on tx order.
• Tip responsibly: tips can improve inclusion priority.
• Signer consistency: bundle authorization is separate from per‑tx signatures.
• Validate locally: ensure each tx is well‑formed and signed before bundling.

Related

• /reference/rpc-api/ — bundle RPC endpoints
• /guides/tx-simulation/ — simulation guide
• /concepts/private-mempool/ — sealed transaction behavior