If you have spent any time wiring up onchain batching in 2026, you have run into the same wall: ERC-4337, EIP-5792, and ERC-7702 all give you a way to bundle calls, but every parameter has to be locked in at signing time. ERC-8211 is the standard that fixes the parameter problem without replacing the infrastructure you already use.
This article compares the four standards side by side, explains where each fits, and shows how ERC-8211 layers on top of the others instead of competing with them.
The short answer
ERC-4337, EIP-5792, and ERC-7702 answer the question "how do I send a batch?" They define wire formats, RPC methods, and execution paths. ERC-8211 answers a different question: "what should each step in the batch resolve to at execution time?" The two questions are orthogonal, which is why ERC-8211 is designed to be composed with the others, not swapped in.
Put differently: ERC-4337 says HOW to send a batch. ERC-8211 says WHAT each step should resolve to when the bundler picks it up.
Comparison table
Standard | Purpose | Parameter model | Signature model | Composes with |
ERC-4337 | Account abstraction infrastructure: UserOperations, bundlers, paymasters, EntryPoint contract | Static. Every call's | Single signature over the entire UserOperation hash | EIP-5792 (as a transport), ERC-8211 (as a resolver layer), ERC-7579 (modular accounts) |
EIP-5792 | Wallet RPC standard: | Static. Calls array is fully materialized client-side before submission. | Wallet-defined; typically one signature per batch | ERC-4337, ERC-7702, ERC-8211 (the resolved batch can be submitted via |
ERC-7702 | EOA delegation: lets an EOA temporarily execute as a smart contract for one transaction | Static. Authorization list and call data fixed at signing. | Authorization tuple signed alongside the transaction | ERC-8211 predicates can gate ERC-7702 delegated calls |
ERC-8211 | Runtime parameter resolution and predicate gating for batched intents across multiple transactions | Dynamic. Parameters resolve at execution from oracle reads, prior-call outputs, and predicate checks. | Signature over the intent template plus resolution constraints, not over concrete values | All three above. uses ERC-4337 bundlers, EIP-5792 transport, ERC-7702 delegation as substrate |
ERC-4337: the infrastructure layer
ERC-4337 introduced account abstraction without protocol-level changes by routing UserOperations through a singleton EntryPoint contract. Bundlers gather UserOps from a mempool, paymasters sponsor gas, and smart-contract accounts validate signatures however they want.
What it gives you: batching inside a single UserOperation, gas sponsorship, custom signature schemes, social recovery primitives.
What it does not give you: any way to leave a parameter unresolved. The UserOperation hash commits to every byte of callData at sign time. If you want to swap "the best price available" or "whichever bridge is cheapest right now", you cannot. you have to pick at signing and live with whatever price exists when the bundler picks it up.
See the official spec at eips.ethereum.org/EIPS/eip-4337.
EIP-5792: the wallet RPC layer
EIP-5792 standardizes how dapps ask wallets to send batched calls. The wallet_sendCalls method takes an array of calls and an atomicRequired hint; wallet_getCallsStatus polls for results. Wallets implement the batch however they want. via ERC-4337, via ERC-7702, or via a native batch primitive.
What it gives you: a portable RPC surface so dapps stop writing wallet-specific batching code. Atomic execution when the wallet supports it.
What it does not give you: parameter dynamism. The calls array is materialized in the dapp before it hits the wallet, and the wallet signs over concrete values. If the dapp wants "swap X for the most Y available at execution", the dapp has to guess and lock in slippage bounds.
Reference: eips.ethereum.org/EIPS/eip-5792.
ERC-7702: the EOA delegation layer
ERC-7702, live on mainnet since Pectra, lets an EOA attach an authorization to a transaction that temporarily makes the EOA's code point to a smart-contract implementation. It is the cleanest path to batching for existing EOA wallets. no contract account deployment required.
It shares the same parameter-static limitation: the authorization tuple is signed alongside concrete calldata. Whatever the delegated implementation does, the EOA owner committed to those exact parameter bytes.
Spec: eips.ethereum.org/EIPS/eip-7702.
ERC-8211: the resolution layer
ERC-8211 does not replace any of the above. It defines a structure that sits above them and tells the executor: "this batch has three steps; resolve step 2's amountOut from step 1's return data; only execute step 3 if predicate P holds; if the batch spans multiple transactions, carry this context forward."
Three things make ERC-8211 different:
Runtime parameter resolution. Parameters can reference oracle reads, prior-call outputs, or signed price ranges instead of fixed bytes.
Predicate gating. Steps can be conditional on onchain state. execute the swap only if the pool's spot price is within a signed band.
Multi-transaction context. A single signed intent can span multiple transactions (useful for cross-chain flows or asynchronous settlement) without re-signing.
The wire format reuses ERC-4337 UserOperations or EIP-5792 call arrays as the transport. Bundlers compatible with ERC-4337 can be extended to understand ERC-8211 resolution metadata without rebuilding the mempool.
See the spec at github.com/ethereum/ERCs/pull/1638.
How do these compose in practice?
A realistic 2026 flow looks like this:
A dapp builds an ERC-8211 intent: "approve, swap with runtime-resolved
amountOutMin, bridge if balance on destination is below threshold."The dapp calls
wallet_sendCalls(EIP-5792) on the user's wallet, passing the intent template.The wallet, which uses ERC-7702 delegation, signs the intent template plus resolution constraints. not the final concrete values.
An ERC-4337 bundler picks up the resulting UserOperation, runs the ERC-8211 resolver against current state, and submits the materialized calldata to the EntryPoint.
Every standard does its job. ERC-8211 is the only one that touched the parameter problem.
When should I use which?
Need account abstraction features (gas sponsorship, custom signatures, recovery)? ERC-4337.
Need a portable RPC so your dapp works across wallets? EIP-5792.
Have an EOA user and want batching without deploying a smart account? ERC-7702.
Need parameters that resolve at execution, not at signing? ERC-8211. on top of any of the above.
If you are building anything that involves price-sensitive execution, conditional steps, or multi-transaction flows, ERC-8211 is the layer you have been missing. The rest of the stack stays the same.
Where ERC-7579 fits
ERC-7579 is the modular smart-account standard. it defines how validators, executors, and hooks plug into an account. ERC-8211 resolution can be implemented as an ERC-7579 executor module, which is the cleanest integration path for modular accounts. The two are complementary: ERC-7579 says how to extend the account; ERC-8211 says what one of those extensions should do.
Further reading
Methodology and sources
Standards references pulled from the canonical Ethereum Improvement Proposals repository (eips.ethereum.org) as of May 2026. ERC-4337 (Buterin, Weiss, Kasper, Drake, Wahrstätter, Tirosh), EIP-5792 (Coinbase Wallet team), ERC-7702 (Buterin, Sun, Drake, Beiko), ERC-7579 (Biconomy, Rhinestone, ZeroDev, OKX), ERC-8211 (Biconomy engineers (Mislav Javor, Filip Dujmušić, Filipp Makarov, Venkatesh Rajendran)). Composition patterns verified against bundler implementations from Pimlico, Stackup, and Alchemy.