ERC-8211 turns a sequence of dependent onchain steps into a single signed bundle. You describe the intent in TypeScript, the SDK compiles it into a ComposableExecution[] array with predicates and runtime references, and the smart account executes the whole bundle atomically. One signature, one Merkle root, no custom Solidity. This guide walks through the reference SDK, the five integration paths, four production patterns, and the testing flow we use before submitting bundles to mainnet.
​

Answer capsule: ERC-8211 standardizes composable, predicate-gated, runtime-referenced batch execution for smart accounts. As a developer, you get atomic multi-step bundles, output-to-input chaining without offchain orchestration, and a single signature for the whole sequence. No new contracts to deploy if you adopt the reference module.
​

Before ERC-8211, batching a swap, a balance check, a supply, and a stake required either custom periphery contracts or a backend that watched mempool state and re-signed each step. The SDK collapses that into one call: each step declares its dependencies on prior outputs, and predicates abort the bundle cleanly if a precondition fails. The smart account verifies a Merkle root covering all steps, so signature reuse and partial execution are both prevented.
​

Answer capsule: The reference SDK at github.com/bcnmy/composable-batch-erc compiles a fluent TypeScript builder into the ComposableExecution[] wire format. You import primitives like swap, predicate, supply, and stake, pass runtime references like fullBalance(), and the SDK emits the ABI-encoded bundle plus the Merkle root to sign.
​

A typical four-step DeFi bundle looks like this:
​

Read top to bottom: swap all WETH to USDC, assert at least 2,500 USDC landed, supply the full USDC balance to Aave, then stake every aUSDC share received. fullBalance() is a runtime reference. The smart account reads the actual balance after each step rather than baking in a value at sign time. That is what makes the bundle slippage-tolerant without offchain re-signing.
​

One signature covers the Merkle root of all four steps. The SDK handles encoding, predicate ordering, and the gas estimation hints the bundler needs. You write no Solidity and deploy no custom contract.
​

Answer capsule: ERC-8211 ships in five integration shapes. Pick based on the account standard you already support and whether you want to gate the new behavior behind an explicit module install.

Most teams start with the ERC-7579 executor module because the install is a single transaction and existing accounts keep working. Teams shipping their own account contract usually pick the native path so they avoid the per-call module dispatch overhead. ERC-7702 is the right choice when you are optimizing for users who refuse to move off an EOA.
​

Answer capsule: Use a runtime balance reference plus a predicate floor so the deposit step sizes itself off the actual swap output and the bundle reverts cleanly if slippage breaches your floor.
​

The predicate is your slippage floor. If the swap underdelivers, the supply step never runs and the user pays only the failed-bundle gas. No partial state, no stuck funds.
​

Answer capsule: Redeem the vault, reference the returned asset balance, then size the next step off that runtime value rather than a stale offchain estimate.
​

This pattern matters because vault share-to-asset rates move between quote and execution. Hard-coding the redemption amount means the next step either leaves dust behind or overshoots and reverts. fullBalance() on the asset token after redemption is the fix.
​

Answer capsule: On the destination chain, gate the rebalance bundle behind a predicate that asserts the bridged funds have arrived. The bundle stays valid in the mempool and only executes once the precondition is true.
​

The source-chain bundle initiates the bridge. The destination-chain bundle reads:
​

Until USDC lands, the predicate fails and the bundle reverts. Once funds arrive, the same signed bundle executes. This replaces the watcher service most cross-chain DeFi teams currently run.
​

Answer capsule: Loop over a token list, swap any non-zero balance to a target asset, and supply the consolidated amount. Predicates skip empty positions without aborting the bundle.
​

The SDK supports conditional steps via predicate blocks that mark the next step as optional rather than required. A dust sweep of fifteen tokens compiles into one bundle, one signature, and one transaction.
​

Answer capsule: Use eth_call against the smart account with the encoded ComposableExecution[] payload. Predicate failures revert with a typed error you can decode, so simulation tells you exactly which step would fail and why.
​

The flow we run in CI:

Because predicates revert cleanly with typed errors, a failed simulation is actionable. You know whether to raise the slippage floor, wait for bridge arrival, or top up the source token before signing.
​

Answer capsule: The SDK emits per-step gas hints based on the resolved runtime references. Bundlers that speak ERC-4337 or EIP-5792 accept these hints directly. For native or ERC-7702 paths, the account's execute function returns a gas-used trace you can use to set the next bundle's limit.
​

Answer capsule: ERC-8211 is a payload format. ERC-4337 and EIP-5792 are transport. You can sign an ERC-8211 bundle and ship it through either transport layer. They are not competitors.
​

If you want the long version of this comparison, see the dedicated breakdown linked below.
​

Drafted from the ERC-8211 reference SDK at github.com/bcnmy/composable-batch-erc and the standard's tracking discussion in EIP PR #1638. Integration-path mapping follows the ERC-7579 executor module interface and the ERC-6900 manifest model. Tested patterns are from reference bundles target Aave V3 markets. No customer data is included.
​