ERC-8211

ERC-8211 是由 Biconomy 与 Ethereum Foundation 联合提出的链上执行标准，发布于 2026 年 4 月 6 日。它不修改以太坊协议层，而是在合约编码层引入一种新的批处理原语：Smart Batching（智能批量）。

它的核心洞见只有一句话：

这句话看似简单，却把多步 DeFi 流从"时间快照的拼接"变成了"实时协议的执行"。对于需要在链上自主操作的 AI Agent 来说，这是它们真正进入 DeFi 的通行证。

静态批量的困境 ↑ top

"批处理不是新东西，ERC-4337 早就支持 UserOperation 批量提交。"这是大多数开发者在第一次听到 ERC-8211 时的反应。这个判断并没有错——但它描述的是一种不同的批量。

ERC-4337 的 UserOperation 批量是静态批量：所有参数——token 数量、滑点上限、目标合约地址——在用户签名时就固定下来。从签名到链上执行，这中间可能有数分钟的延迟，而 DeFi 的链上状态是实时变动的。

对于手动操作的人类用户，失败了重发就好。但对于需要全天候自主运行的 AI Agent，静态批量的高失败率意味着：要么保守地串行执行每一步（多次签名、多次 gas），要么接受频繁失败带来的资金损耗。

ComposableExecution 架构 ↑ top

ERC-8211 的核心数据结构是 ComposableExecution[]——一个批次入口的数组。每个入口描述一次链上调用，但与静态批量不同，它的参数不是直接写死的值，而是一组参数声明：告诉执行引擎"在执行时去哪里取这个值，以及这个值必须满足什么条件"。

每个 ComposableExecution 由三个维度控制：

Fetchers — 参数来源

Fetcher 是 ERC-8211 最关键的设计。它让每一个参数都能在执行时从链上"现取"，而不是从签名时的快照里读取。

Balance Fetcher 是解决"下一步的输入 = 上一步的实际输出"这个经典 DeFi 问题的关键。AI Agent 不需要猜测 swap 之后会得到多少 token，执行引擎在那一刻直接读账户余额，传给下一步。

Constraints — 执行条件

Constraint 是与 Fetcher 配套的校验器：当一个参数被 Fetcher 解析出来之后，Constraint 验证它是否在可接受范围内。如果不满足，整个批次立即 revert。

Constraint 与 Fetcher 的组合覆盖了 DeFi 中绝大多数的"前提条件"需求。过去需要在链下预估然后硬编码的参数，现在可以在链上执行时动态验证——更实时，也更安全。

Predicates — 纯断言门控

Predicate 是一种特殊的 ComposableExecution 入口：它的 target 字段被设为 address(0)，表示这个步骤不发起任何合约调用，只做链上条件断言。

如果 Predicate 的断言失败，整个批次 revert。Predicate 通常被插入两个操作步骤之间，充当"阶段门"：

Solidity 接口参考 ↑ top

ERC-8211 定义在合约编码层，不修改任何 EVM 协议。接口由核心数据结构和一个执行函数组成：

enum FetcherType {
    Literal,      // 内联字节，签名时直接写死
    StaticCall,   // 执行时 staticcall view 函数，取返回值
    Balance       // 执行时读取 ERC-20 balanceOf(account)
}

enum ConstraintOp {
    None,   // 无约束，直接透传
    Gte,    // >=  滑点保护：输出 ≥ 最低可接受金额
    Lte,    // <=  价格上限：不超过某阈值
    Eq,     // ==  精确匹配合约状态
    Neq     // !=  防止某状态出现（如 pool 被暂停）
}

struct ParamEntry {
    FetcherType  fetcherType;
    address      fetchTarget;   // StaticCall / Balance 的目标地址
    bytes        fetchData;     // StaticCall 的 calldata；Balance 时忽略
    ConstraintOp constraintOp;
    uint256      constraintVal; // 约束右值
    bytes32      storeSlot;     // 可选：存入临时 slot，供后续步骤引用
}

struct ComposableExecution {
    address      target;   // address(0) = Predicate（纯断言，不发起调用）
    bytes4       selector;
    ParamEntry[] params;
}

function execute(
    ComposableExecution[] calldata batch
) external returns (bytes[] memory results);

执行流程 ↑ top

当 execute(batch) 被调用时，执行引擎按以下步骤处理每个 ComposableExecution 入口：

关键特性：原子性。整个 batch[] 要么全部成功，要么在任意失败点 revert，不存在部分执行的中间状态。这与传统多笔独立交易的最大区别——过去如果第 3 笔失败，前两笔已经上链，资金状态进入一个"半截"的中间状态。

实战：4 步 DeFi 流 ↑ top

以下是 ERC-8211 官方规范中给出的典型场景：将 WETH 通过 Uniswap 换成 USDC，校验余额，存入 Aave，最后质押凭证 token。整个流程打包进一笔原子交易。

用静态批量完成同样的操作需要：4 笔独立交易 × 4 次用户签名，中间状态暴露在链上，任一步骤失败都需要手动恢复。ERC-8211 将这个流程压缩为 1 笔原子交易，gas 消耗降低约 89%。

TypeScript SDK ↑ top

ERC-8211 配套了一套 TypeScript SDK，开发者在高层描述意图，SDK 自动编译为 ComposableExecution[] 的链上编码。下面是与 4 步 DeFi 流对应的完整写法：

import { SmartBatch, FetcherType, ConstraintOp } from "@erc8211/sdk";
import { UNISWAP_ROUTER, AAVE_POOL, AAVE_STAKING, WETH, USDC, aUSDC } from "./addresses";

const batch = new SmartBatch();

batch.addCall({
  target:        UNISWAP_ROUTER,
  selector:      "exactInputSingle",
  params: [{
    fetcherType:   FetcherType.Balance,   // 执行时读取账户实时 WETH 余额
    fetchTarget:   WETH,
    constraintOp:  ConstraintOp.Gte,
    constraintVal: 1n,                   // 余额必须 ≥ 1 wei，防空仓
  }],
});

batch.addPredicate({
  fetcherType:   FetcherType.Balance,
  fetchTarget:   USDC,
  constraintOp:  ConstraintOp.Gte,
  constraintVal: parseUnits("900", 6), // 不足 900 USDC → 整批 revert
});

batch.addCall({
  target:   AAVE_POOL,
  selector: "supply",
  params: [{
    fetcherType:  FetcherType.Balance,  // 取 swap 后实际到账的 USDC 余额
    fetchTarget:  USDC,
    constraintOp: ConstraintOp.None,   // 无额外约束，全额存入
  }],
});

batch.addCall({
  target:   AAVE_STAKING,
  selector: "stake",
  params: [{
    fetcherType:   FetcherType.Balance,
    fetchTarget:   aUSDC,             // Aave 存款后到账的 aUSDC 凭证
    constraintOp:  ConstraintOp.Gte,
    constraintVal: parseUnits("1", 6), // < 1 USDC 的 dust 不质押
  }],
});

const encoded = batch.encode();        // 编译为 ComposableExecution[] ABI 编码
await smartAccount.execute(encoded); // 单笔原子提交，1 签名

兼容标准 ↑ top

ERC-8211 被设计为账户无关的编码标准，兼容现有所有主流账户抽象框架：

与 ERC-8004 的协作

ERC-8004 解决"Agent 可不可信"，ERC-8211 解决"Agent 能不能执行"。两者分工明确，组合使用时，一个完整的 Agent DeFi 操作路径如下：

1. 调用方通过 ERC-8004 ReputationRegistry 查询执行 Agent 的声誉分
2. 声誉校验通过后，构造 ComposableExecution[] 批次
3. 将声誉分 StaticCall 查询作为批次第一个 Predicate，链上实时确认身份信任
4. 后续步骤原子执行 DeFi 操作

与 ERC-8183 的协作

ERC-8183 定义了 Agent 之间的任务市场——Client 发布任务，Provider 执行并获得报酬。ERC-8211 让 Provider 在链上交付时更高效：

• Provider 将任务所需的多步链上操作打包为 ERC-8211 批次
• 批次成功执行 = 交付完成，Evaluator 通过 deliverable_hash 验证
• 相比串行执行，单笔原子交易降低失败概率，减少争议产生

安全考量 ↑ top

总结速查 ↑ top

测验 ↑ top

5 道题，测试你对 ERC-8211 的理解：