ERC-5792批量调用状态怎么查？ 图 1
ERC-5792批量调用状态怎么查？ · 图 1

ERC-5792 把多个 wallet call 放进一个请求，但“批量”不自动等于“原子”。应用要先读取钱包 capabilities，再提交 calls，最后用批次 ID 查询状态；任何一步都不能用单笔交易的假设代替。

Capability 是运行时合同

wallet_getCapabilities 可按 chain 返回钱包支持的能力和参数。应用应在当前账户、当前链上读取，并根据结果启用 atomic batching、paymaster 或其他选项。缓存另一个账户的能力会造成错误 UX。

批量调用返回的三层状态

  1. Capability 是运行时合同：ERC-5792定义wallet_sendCalls提交一组调用，并通过wallet_getCapabilities协商钱包支持的批处理能力。
  2. sendCalls 返回的是批次引用：请求被钱包接受后返回批次标识，应用仍需用wallet_getCallsStatus区分pending、confirmed与failed等后续状态。
  3. 状态要按钱包返回语义解释：批量调用是否原子、由EOA还是智能账户执行取决于钱包能力；应用不能默认所有调用必然一起成功。

sendCalls 返回的是批次引用

wallet_sendCalls 接收 from、chainId、calls 及可选 capabilities，钱包接受后返回 id。这个 id 说明请求被接收，不表示链上已确认；用户拒绝、能力不支持或参数非法应作为明确错误处理。

从钱包请求追到每个Call

  1. 先读取目标 chain 的 capabilities，并保存原始响应。
  2. 逐条核对 call 的 to、value、data 和顺序，再让用户确认批次。
  3. 保存返回 id，按退避策略查询状态，不重复创建相同批次。
  4. confirmed 后逐项检查 receipt、事件和余额；failed 时展示哪一层失败。

状态要按钱包返回语义解释

wallet_getCallsStatus 用 id 返回 pending、confirmed、failed 等状态和可能的 receipts。应用只有在获得目标链回执并验证业务结果后才显示完成；批内部分执行是否可能发生，取决于钱包声明的原子能力和实现路径。

页面重开仍是Pending时

如果钱包不声明原子能力，应用不能承诺“要么全部成功、要么全部回滚”。可把有依赖关系的动作改为合约内原子调用，或明确提示用户可能出现前一项成功、后一项失败。

未知状态不能偷偷重发

capabilities 不明、chainId 与会话不一致或无法说明批内失败语义时停止发送。

批次状态如何落库

钱包界面应把一次批量请求拆成用户可以理解的动作清单，逐项展示目标合约、资产、金额和授权变化。调用返回后，应用保存 batch id 与每个 call 的预期效果，再通过状态接口和链上回执核对；部分成功、全部失败与状态未知必须使用不同提示。若重开页面仍处于 pending，应恢复原批次追踪，不能静默新建同内容请求。

ERC-5792接口定义

  1. Ethereum EIPs：用于核对ERC-5792批量钱包调用的候选主题的一手字段、产品说明或事件发现。
  2. MetaMask Wallet API：用于核对ERC-5792批量钱包调用的实现路径、交叉验证或风险边界。

相关站内主题：钱包会话权限、权限模型。资料访问时间为2026-07-22；协议、接口、监管清单与产品界面均可能更新。

风险提示：批量调用可能处于未知、部分执行或最终失败状态，重复发送相同意图可能产生额外授权和转账。应用必须恢复原Batch ID并逐项核对结果；钱包提示无法解释时，不要为了“刷新状态”再次签名。