​ERC-8211 is a Standards Track draft EIP that introduces Smart Batching for Ethereum account abstraction: a batch transaction format where parameters resolve at execution time and steps gate behind predicates instead of being frozen at signing. The draft was authored by Biconomy engineers Mislav Javor, Filip Dujmušić, Filipp Makarov, and Venkatesh Rajendran, opened as PR #1638 on the ethereum/ERCs repository on February 11, 2026, and is backed by Biconomy in collaboration with the Ethereum Foundation.
​

ERC-8211 solves the static-parameter problem in batched account-abstraction transactions. Existing standards like ERC-4337 and EIP-5792 freeze every calldata byte at signing time, so any batch whose later steps depend on the output of earlier steps fails when actual amounts differ from the signed amounts. Smart Batching makes those steps resolve at runtime.
​

The static-parameter limitation breaks three common DeFi flows. First, swap-then-supply: a user swaps USDC for WETH on Uniswap, then deposits the resulting WETH into Aave, but slippage means the deposit amount cannot be known at signing. Second, vault-withdraw-then-bridge: a withdrawal from a Morpho vault returns a share-converted asset amount that varies with interest accrual. Third, dust sweeps: sending the full BALANCE of a token to an address fails when the literal amount differs from what was signed by a single wei.
​

The draft frames this as a composability gap. ERC-4337 gave Ethereum smart accounts; EIP-5792 standardized wallet-side batch RPC methods (wallet_sendCalls). Neither addresses the case where step N's input is step N-1's output. Without runtime resolution, multi-step DeFi requires per-step signing, intent solvers, or off-chain pre-simulation, each of which adds latency, MEV exposure, or trust assumptions.
​

ERC-8211 works by introducing three primitives that layer onto any account-abstraction execution model: runtime parameter injection, pre and post predicates, and multi-transaction Storage context. The Smart Batching executor reads these primitives from the batch, resolves dynamic values immediately before each call, and reverts the call if predicate assertions fail.
​

The first primitive is the parameter fetcher. Instead of encoding a literal calldata value, the signer encodes a fetcher tag that the executor evaluates at call time. The spec defines three fetcher types: BALANCE reads the current token balance of a target address; STATIC_CALL performs a view call against any contract and returns the result; RAW_BYTES passes a literal value through unchanged for backward compatibility. A swap-then-supply batch encodes the supply amount as BALANCE(WETH, smartAccount) rather than a fixed integer.
​

The second primitive is the predicate. Before and after each batched call, the signer can attach assertions that compare a fetched value against an expected one. The draft specifies four predicate operators: EQ (equality), GTE (greater than or equal), LTE (less than or equal), and IN (membership in a set). A predicate that fails causes the executor to revert the entire batch, providing slippage protection, deadline checks, and oracle-bound execution gates without requiring a separate verifier contract.
​

The third primitive is the Storage context. A shared Storage contract persists arbitrary key-value state across multiple UserOperations within the same logical batch, including UserOps that span multiple transactions or chains. A batch that bridges funds and then deploys them on the destination chain writes the bridged amount to Storage on the source side and reads it as a runtime parameter on the destination side, with a predicate gating execution until the value is present. The Biconomy reference implementation lives at bcnmy/composable-batch-erc.
​

ERC-8211 differs from ERC-4337 and EIP-5792 along three axes: parameter resolution, predicate-gated execution, and cross-transaction context. ERC-4337 standardized the smart-account UserOperation; EIP-5792 standardized wallet-side batch RPCs. Neither defines runtime-resolved parameters, neither supports conditional reverts inside a batch, and neither carries state between calls.
​

The table below maps the three standards along the dimensions that matter for composable DeFi.

The three are not alternatives. ERC-8211 runs on top of ERC-4337 or EIP-5792, consuming their delivery mechanics and adding the missing runtime layer above. A wallet can send a Smart Batch through wallet_sendCalls as defined in EIP-5792; the bundler delivers it as a UserOp under ERC-4337; the ERC-8211 executor resolves the fetchers and runs the predicates immediately before each inner call.
​

ERC-8211 is designed as an execution layer that any modular smart-account standard can host. The draft explicitly lists compatibility with ERC-7579 as an executor module, ERC-6900 as a plugin, ERC-7702 as an EOA delegation target, and ERC-4337 or EIP-5792 as a delivery transport. Implementers pick the integration mode that matches their account stack rather than adopting a new account type.
​

Under ERC-7579, the Smart Batching logic ships as an executor module installed alongside validators and hooks. Under ERC-6900, it ships as a plugin with declared execution and validation manifests. Under ERC-7702, a regular EOA temporarily delegates its code to a Smart Batching contract for the duration of a single transaction, allowing externally owned accounts to run composable batches without a permanent migration to a smart account. The draft also notes interoperability with ERC-7683 cross-chain intents and ERC-7786 cross-chain messaging, which matters when the Storage context spans chains.
​

ERC-8211 use cases cluster around DeFi flows where step outputs feed step inputs, and around cross-chain operations where execution conditions depend on remote state. The canonical example in the Biconomy landing material is rebalancing a Morpho-on-Base position into Aave-on-Ethereum in eight steps signed once, with a predicate-gated Ethereum batch that fires only when bridged funds arrive.
​

Smart Batching maps cleanly onto four common patterns. Single-chain swap-then-supply flows: swap USDC to WETH on a DEX, then supply the BALANCE of WETH to Aave with a GTE predicate enforcing minimum slippage. Vault rebalancing: withdraw the share-converted asset amount from a Morpho vault and redeposit into a second vault with the runtime amount injected. Dust sweeps: send BALANCE of token X to a destination address without needing to read the balance off-chain first. Cross-chain rebalancing: bridge funds from Base to Ethereum, write the bridged amount to Storage, then run a predicate-gated supply on the destination side that waits for the value to be present.
​

Biconomy's SuperTransactions work covers the production-side build of this pattern. The Smart Batching primitives are the standardized version of the runtime layer that previously required a bespoke executor per integrator.
​

Eco Routes complements ERC-8211 as the cross-chain transport layer for batches whose Storage context spans chains. A Smart Batch that rebalances Morpho-on-Base into Aave-on-Ethereum needs funds to physically move between chains before the destination-side predicate clears. Eco Routes handles that transport: stablecoin and asset routing across 15 supported chains with intent-based execution, leaving ERC-8211 to handle the per-chain runtime resolution and predicate logic.
​

The pairing is natural. Smart Batching resolves the within-chain composability gap; Eco Routes resolves the between-chain transport gap. A composable batch built on ERC-8211 can encode an Eco Routes transfer as one of its steps, then gate downstream calls on the destination chain behind a predicate that reads the post-transfer balance.
​

Sources and methodology. Specification details verified against ethereum/ERCs PR #1638 (opened February 11, 2026), the discussion at ethereum-magicians.org, and the Biconomy landing page at erc8211.com. Reference implementation at github.com/bcnmy/composable-batch-erc. Draft status accurate as of May 2026; check the PR for current revision.
​