ERC-8211 Aims to Enable Dynamic Execution for AI Agents in DeFi

Starting in 2025, many people may gradually become accustomed to a new way of interacting: telling GPT or Gemini, “Plan my trip to Hong Kong next week and recommend suitable flights and hotels,” and it will silently perform a series of steps in the background—searching for information, filtering criteria, selecting routes, comparing prices—before presenting only the final results for your confirmation.

However, bringing the same expectations to the chain tells a completely different story.

For example, if you give a DeFi Agent the instruction: “Swap all ETH in my wallet for USDC, bridge it to the Base chain, and deposit the full amount into Aave,” objectively speaking, today’s agents may not struggle with “understanding the request” or “planning the path”—the true gap lies in the execution phase:

You will likely still need to complete a series of steps gradually—signing, authorizing, exchanging, bridging, and depositing—each exposed to risks such as slippage, gas fluctuations, bridge delays, and on-chain state changes. This means that if any single step deviates from expectations, prior actions may not be reversible, and subsequent steps might fail to trigger, leaving behind only an incomplete, half-finished process on the chain.

The issue isn't that AI isn't smart enough, but that the on-chain execution layer still lacks a truly agent-compatible way of expression.

Precisely for this reason, in early April 2026, Biconomy, in collaboration with the Ethereum Foundation, introduced ERC-8211 to address the "static limitations" in current smart contract execution, providing a more expressive execution layer for AI agents and complex DeFi workflows, aiming to fill this missing piece of the puzzle.

Over the past one to two years, the crypto industry's focus has clearly shifted from L2 scaling and RWA liquidity toward the highly disruptive topic of how AI agents can truly take over on-chain operations.

Objectively speaking, we have recently seen numerous practical implementations ranging from "using natural language to execute multi-step DeFi strategies" to "allowing autonomous agents to manage entire cross-chain investment portfolios," and most of these concepts have already matured at the demo level—including natural language generation of multi-step DeFi strategies, autonomous rebalancing, automated yield migration, cross-chain position adjustments, and even more complex portfolio management.

From the perspective of reasoning and orchestration, AI's capabilities have advanced rapidly, but when truly deployed in production environments, the shortcomings at the execution layer are becoming increasingly apparent.

When it comes to production environments, this limitation can be summed up in one sentence: DeFi is dynamic, but most current batches are still static.

The official ERC-8211 website and discussion posts clearly address this issue: existing ERC-4337 and EIP-5792 have indeed advanced the old model of "one signature per call" to the new stage of "one signature bundling multiple calls," but the parameters within these calls are still largely frozen at the moment of signing.

In other words, the amount, target value, and expected output entered by the user during signing will not be automatically adjusted when executed, even if the on-chain state changes.

DeFi itself is inherently uncertain. The actual output of a swap depends on slippage and liquidity within the executing block; the arrival time and final amount of a bridge transfer depend on the bridge’s own mechanism and fees; and the share-to-asset ratio of lending protocols or Vaults also continuously changes.

After all, the value users or agents see when signing is often just a current estimate, not the actual result at execution.

To understand what ERC-8211 solves, consider a typical example: suppose an Agent wants to do something that seems straightforward—exchange ETH in their account for USDC and deposit the full amount into Spark to earn interest.

Under the current static batch processing model, the Agent must estimate in advance how much USDC it will receive after the Swap, often forcing you to hardcode the input amount for the second step at signing time. If the estimate is too high and the actual received amount falls short, the entire batch rolls back; if it’s too low, some funds remain idle in the wallet, unused.

In other words, it essentially falls into a classic dilemma: either accept the risk of failure or bear the opportunity cost. This is why many on-chain processes that seem straightforward quickly become fragile once they extend to five, eight steps, or even span two chains—not because the strategy itself is too complex to describe, but because the current execution paradigm relies too heavily on pre-defined, rigid parameters.

In short, the upper limit of static batch capabilities effectively determines the upper limit of strategies an Agent can safely execute.

From this perspective, ERC-8211 aims not to solve how AI agents make decisions, but to provide a more natural, stable, and secure way on-chain to execute those decisions once they’ve been made—enabling on-chain execution to have, for the first time, a native expression designed specifically for AI agents.

The core breakthrough of ERC-8211 is not about cramming more steps into a single signature, but about upgrading batch processing from a hardcoded sequence of transactions to a "program whose parameters are dynamically evaluated at execution time."

It may sound abstract, but it’s not hard to understand—the official description is simple: From transactions to programs.

This means that ERC-8211 no longer treats a batch as a sequentially ordered list of actions, but rather as a runtime-evaluated execution program with safety conditions. Specifically, it achieves this through three composable primitives:

• Fetchers: Define where this parameter retrieves its value; it can be a real-time query of the current balance at a specific address, ensuring the parameter reflects the on-chain state at the moment of execution rather than a snapshot taken at signing time;
• Constraints: After parameters are extracted, they must pass inline constraint checks—such as “the received USDC must be ≥ 2500” or “slippage cannot exceed 0.5%”—these constraints are validated before the values are routed to the next call; if any check fails, the entire batch is immediately rolled back;
• Predicates (trigger conditions): Think of them as gatekeepers between steps—they don’t generate values, but determine whether execution should continue. For example, in a cross-chain scenario, the batch on the Ethereum side can use a predicate to wait until the WETH transferred from another chain has been received, and only proceed once the condition is met.

In this design, each parameter must answer two questions: first, where should this value come from at runtime; second, what conditions must it satisfy before being used in the call. Together, these three elements transform a batch from a simple sequence of transactions into a program with embedded security checks.

Ultimately, the mental model for static batch processing is a checklist—execute steps A, B, and C in sequence; whereas the mental model for ERC-8211 is a conditional program—after A executes, take A’s actual output as B’s input; B proceeds to C only if constraints are met; if any step fails, the entire batch rolls back.

We can simply think of it as a "smart batch processing" mechanism designed specifically for AI agents and complex DeFi operations, since traditional on-chain actions often require multiple separate transactions to execute a complex DeFi strategy: withdrawing funds from a lending protocol, swapping tokens, and then depositing them into another protocol (see further reading: Comprehensive Guide to Crypto AI Protocols: How to Build a New Operating System for AI Agents Starting from Ethereum’s Core?).

Each step requires individual signing and confirmation, which is already cumbersome for human users and a bottleneck for AI agents requiring high-frequency autonomous operations. ERC-8211 solves this by allowing multiple blockchain operations to be combined and executed in a single transaction, dynamically resolving actual values during execution and requiring predefined conditions to be met before proceeding to the next step.

For example, an agent can complete this in a single signed transaction: withdraw funds from Aave → swap the actual received amount on Uniswap → deposit the swap result into Compound—all executed atomically without requiring a new smart contract.

ERC-8211 is worth attention from the wallet industry not only because it is suitable for agents, but also because it will redefine the role of wallets in the interaction flow.

In the past, wallets functioned more like secure signers, responsible for storing private keys, displaying transactions, allowing users to confirm them, and then sending out the signatures. This role was crucial in the EOA era and remains valid in the era of account abstraction. However, if an increasing number of on-chain operations are carried out by Agents in the future, the wallet’s role will become even more central and critical.

The reason is simple: when users stop manually executing on-chain actions one by one and instead begin authorizing an Agent to carry out a full set of objectives, wallets must be able to handle this higher-level interface. They must no longer display only a contract address and a piece of calldata, but an entire execution program of “intent—value logic—conditional checks—final outcome.”

Therefore, future wallets need to understand not just transactions, but programs. ERC-8211 provides wallets with a clearer interface at this level, because it explicitly encodes these execution semantics into the structure—where parameters come from, what conditions must be met, when to proceed, and when to rollback—are no longer hidden black boxes in backend logic, but objects that wallets can interpret, simulate, and display.

From a wallet perspective, this entire mechanism ultimately points to one thing: users are no longer signing a string of low-level calls they can hardly understand, but rather signing a result-oriented, well-bounded, and verifiably conditional execution program:

• AI Agent can handle understanding user intent and generating pathways;
• The wallet will display this path in a clearer format for user review;
• The relayer is only responsible for submitting when conditions are met and does not have the authority to alter the results;

This is precisely why non-custodial execution is considered 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, as it embeds the ability to "securely express complex intentions" into the protocol-level standard.

Notably, 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 rather adds a layer of programmatic execution semantics for Agents on top of it.

If ERC-4337 addresses "who can act on my behalf to initiate transactions" and EIP-7702 addresses "how an EOA can temporarily gain smart contract capabilities," then ERC-8211 addresses whether an Agent, once authorized to act for me, can complete an entire decision chain within a single signature.

Looking back at the evolution of on-chain interaction patterns on Ethereum over the past 10 years:

• Phase 1: One signature = One function call (EOA era)
• Phase 2: One signature = a bundled set of static calls (ERC-4337, EIP-5792 era)
• Stage 3: One signature = A dynamically evaluated intent program (ERC-8211 era)

Each leap means users (or agents representing users) can express more complex goals with less friction.

Although ERC-8211 is still in draft form and technical discussions are ongoing, with large-scale protocol adoption still requiring time, the direction it points to is already clear: when AI agents truly begin making on-chain decisions on behalf of users, the chain will need a native execution syntax to match.