Starting in 2025, many people may gradually become accustomed to a new way of interaction: telling GPT or Gemini something like "Help me plan a trip to Hong Kong next week and recommend suitable flights and hotels," and it will silently complete a series of steps in the background, such as information search, condition filtering, route selection, and price comparison, finally handing you the results for confirmation.
However, bringing the same expectation on-chain tells a completely different story.
For example, if you give an instruction to a DeFi Agent: "Swap the ETH in the wallet for USDC, bridge it to Base chain, and then deposit the full amount into Aave." Objectively speaking, from the perspective of "understanding the demand" and "planning the path," today's Agent might not necessarily be incapable. The real gap lies in the execution phase:
You still likely have to complete operations step by step—signing, authorization, swapping, bridging, and depositing—with each step exposed to risks such as slippage changes, Gas fluctuations, bridge delays, and on-chain state changes. This means that if any step deviates from expectations, the previous actions may not be reversible, and the subsequent actions might not follow through, ultimately leaving behind an unfinished, half-completed process on the chain.
The problem is not that AI is not smart enough, but that the on-chain execution layer still lacks a truly Agent-adapted expression method.
It is precisely for this reason that in early April 2026, Biconomy and the Ethereum Foundation jointly released ERC-8211, aiming to solve the "static limitations" in current smart contract execution and provide a more expressive execution layer for AI agents and complex DeFi workflows, attempting to complete this missing piece of the puzzle.
I. The "Last Gap" for AI Agent Access On-Chain
Over the past one to two years, the focus of the crypto industry has clearly shifted from L2 scaling and RWA liquidity to the highly disruptive topic of how AI agents can truly take over on-chain operations.
Objectively speaking, from "using natural language to issue multi-step DeFi strategies" to "letting autonomous agents manage an entire cross-chain investment portfolio," we have recently seen many practices, and most concepts are already mature at the demo level—whether it's natural language generating multi-step DeFi strategies, autonomous rebalancing, automatic yield migration, cross-chain position adjustments, or even more complex portfolio management.
From the perspective of reasoning and orchestration, AI capabilities have advanced quite rapidly. However, when actually deployed in a production environment, the shortcomings of the execution layer become increasingly apparent.
To put it into a production environment, this shortcoming can be summarized in one sentence: DeFi is dynamic, but most batch processing today is still static.
As clearly explained in the ERC-8211 official website and discussion posts, existing ERC-4337 and EIP-5792 have indeed advanced the old model of "one signature corresponding to one call" to the new stage of "one signature can bundle multiple calls." However, the parameters in these calls are essentially still frozen at the moment of signing.
In other words, the amounts, target values, and expected outputs filled in by the user at the time of signing will not automatically adjust due to on-chain state changes when actually executed.
But DeFi itself is full of uncertainties. The actual output of a swap depends on the slippage and liquidity in the block where it is executed; the arrival time and final amount of a bridge transfer depend on the mechanism and fees of the bridge itself; the share-to-asset ratio of lending protocols or vaults also changes continuously.
After all, the values seen by the user or agent at the time of signing are often just current estimates, not the real results at execution time.
To understand what ERC-8211 solves, consider a typical example: suppose an agent wants to do something that seems very ordinary—swap the ETH in the account for USDC and then deposit the full amount into Spark to earn interest.
Under the current static batch processing model, the agent must estimate how much USDC will be obtained after the swap before signing, often forcing you to pre-write the input amount for the second step at signing time. If the estimate is too high, the actual amount received is insufficient, and the entire batch rolls back; if the estimate is too low, a portion of the funds will be left idle in the wallet, unable to be used.
In other words, you are basically caught in a dilemma: either bear the risk of failure or bear the opportunity cost. This is why many seemingly uncomplicated on-chain processes quickly become fragile once the steps extend to 5, 8 steps, or even across two chains. It is not because the strategy itself is too complex to describe, but because the current execution paradigm relies too heavily on pre-written parameters.
In short, the capability ceiling of static batch processing essentially determines the strategy ceiling that agents can safely execute.
From this perspective, what ERC-8211 aims to solve is not how AI agents make decisions, but rather, after the agent has made a decision, whether there is a more natural, stable, and secure way to execute it on-chain. This would allow on-chain execution to have, for the first time, an expression form natively designed for AI agents.
II. What Exactly Does ERC-8211 Change?
The core breakthrough of ERC-8211 is not about stuffing more steps into one signature, but about upgrading batch processing from a transaction sequence with fixed parameters to a "program where parameters are dynamically evaluated at execution time."
It sounds abstract, but it is not difficult to understand. The official description is: From transactions to programs.
This means that ERC-8211 no longer views a batch as a list of actions to be executed in sequence, but rather as an execution program that is evaluated at runtime and comes with safety conditions. To break it down specifically, it achieves this through three composable primitives:
- Fetchers: Define where this parameter gets its value from. It can be a query for the current balance of a certain address, making the parameter no longer a snapshot at signing time, but a real-time reading grabbed from the on-chain state at the moment of execution;
- Constraints: After the parameter is resolved, it must pass inline constraint validation—for example, "the swapped USDC must be ≥ 2500" or "slippage cannot exceed 0.5%." These constraints are checked before the value is routed into the next call. If any constraint fails, the entire batch immediately rolls back;
- Predicates: Can be understood as gatekeepers between steps. They are not responsible for generating values but for judging whether to continue execution. For example, in a cross-chain scenario, the batch on the Ethereum side can use a predicate to wait for the condition "the WETH bridged over has arrived" and not submit until it arrives;
In this design, every parameter must answer two questions: First, where should this value come from at execution time? Second, what conditions must it satisfy before being actually used in a call? After combining these three, a batch is no longer just a transaction sequence but a program with embedded safety checks.
Ultimately, the mental model of static batch processing is a checklist—execute steps A, B, and C in sequence; whereas the mental model of ERC-8211 is a conditional program—after A is executed, take the actual output of A as the input for B; B must satisfy constraints to proceed to C; if any step does not meet expectations, the entire batch rolls back.
We can simply understand it as a "smart batch processing" mechanism specifically designed for AI agents and complex DeFi operations. Because in traditional on-chain operations, completing a complex DeFi strategy often requires multiple independent transactions: withdrawing funds from a lending protocol, swapping tokens, and then depositing into another protocol (extended reading: "Crypto AI Protocol Panorama: Starting from Ethereum's Main Battlefield, How to Build a New Operating System for AI Agents?").
Each step requires separate signing and confirmation, which is already tedious for human users and even more of a bottleneck for AI agents that require high-frequency autonomous operations. The solution of ERC-8211 is to allow multiple blockchain operations to be combined into one transaction, with each step dynamically parsing the actual value at execution time and requiring predefined conditions to be met before proceeding to the next step.
For example, an agent can complete in one signed transaction: withdraw funds from Aave → swap the actually received amount on Uniswap → deposit the swap result into Compound—all executed atomically without writing a new smart contract.
III. Why It Matters More to Wallets, Especially Smart Wallets
The reason why ERC-8211 deserves attention from the wallet industry is not only because it suits agents, but also because it will redefine the position of wallets in the interaction chain.
In the past, wallets were more like secure signers. Their responsibility was to保管 private keys, display transactions, let users confirm, and then send out the signature. This role was important enough in the EOA era and continues to hold in the account abstraction era. However, if more and more on-chain operations are to be performed by agents in the future, the role of the wallet will become more central and critical.
The reason is simple: when users no longer control on-chain actions one by one but start authorizing an agent to execute a whole set of goals, the wallet must be able to handle this higher-level interaction object. What it needs to display is no longer just a contract address and a piece of calldata, but an entire execution program of "intent—value retrieval logic—condition judgment—final result."
Therefore, the wallet of the future needs to understand not just transactions, but programs. ERC-8211 provides a clearer handle for wallets at this layer because it explicitly writes these execution semantics into the encoding structure. Including where parameters come from, what conditions they must satisfy, when to continue, and when to roll back—these are not black boxes hidden in backend logic but objects that can be interpreted, simulated, and displayed by the wallet.
From the wallet's perspective, this entire mechanism ultimately points to the same thing: users are no longer signing a series of underlying calls that are difficult to fully understand, but are signing a result-oriented, clearly bounded, condition-verifiable execution program:
- AI agents can be responsible for understanding user intent and generating paths;
- Wallets are responsible for displaying this path in a clearer way for user review;
- And relayers are only responsible for submitting when conditions are met, without having the authority to tamper with results;
This is precisely why non-custodial execution is regarded as a prerequisite for Agentic DeFi—because agents can participate, but sovereignty, constraints, and final settlement remain on-chain. This is also where ERC-8211 truly aligns with smart wallets: it writes the "secure expression of complex intents" into the protocol layer standard.
It is worth mentioning that ERC-8211 is fully compatible with account abstraction frameworks such as ERC-4337, EIP-7702, and ERC-7579. It does not replace account abstraction but adds a layer of programmable execution semantics for agents on top of account abstraction.
If ERC-4337 solves "who can initiate transactions on my behalf," and EIP-7702 solves "how EOA can temporarily have smart contract capabilities," then ERC-8211 solves once an agent starts operating on my behalf, whether it can complete an entire decision chain in one signature.
Looking back at the evolution of on-chain interaction paradigms on Ethereum over the past 10 years:
- Phase 1: One signature = one function call (EOA era)
- Phase 2: One signature = a set of statically bundled calls (ERC-4337, EIP-5792 era)
- Phase 3: One signature = a dynamically evaluated intent program (ERC-8211 era)
Each leap means that users (or agents representing users) can express more complex goals with less friction.
Although ERC-8211 is still in the draft stage, technical discussions are ongoing, and large-scale protocol integration will take time, the direction it points to is clear enough: when AI agents truly start making on-chain decisions for people, the chain needs a matching, native syntax for execution.
