批量调用前先备好代币：ERC-7795 给钱包加的前置条件

用支持批量调用的钱包做 NFT 操作时，常遇到一种尴尬：一笔“授权加铸造”或“批准加质押”的组合调用里，某一步因为余额不够、没有授权而失败，整批回滚，gas 照付。EIP-5792 解决了“一次签多笔”的问题，但没有规定钱包要不要先检查条件。ERC-7795 就是补这块的：它扩展 EIP-5792，让 dApp 能把“执行前必须满足哪些代币条件”说清楚，钱包据此提前帮用户凑齐。该提案在 ercs 仓库的状态是 Draft（草稿），创建于 2024 年 10 月 22 日，涉及 ERC-20、ERC-721、ERC-1155 三种代币标准。

能力是怎么声明的

这套机制借用 EIP-5792 已有的两个 RPC 方法。钱包先用 wallet_getCapabilities 回答自己支持哪些能力，比如返回结构里会出现 erc20MinBalance 这样的键，带上 supported 布尔值和版本列表。dApp 再在 wallet_sendCalls 请求里直接写入条件对象，例如 erc20MinBalance 参数里包含版本、链 ID、owner 地址、token 地址和 minAmount，意思是：执行之前，owner 在这条链上对该代币的余额必须不低于 minAmount。达不到，钱包可以提示用户先去补余额，而不是让交易上链后 revert。

条件面向哪些场景

从规范文本看，能力覆盖了“执行前账户应当具备的状态”这一类问题：最少余额、特定代币的存在等。对 NFT 用户来说，最直观的收益是把铸造流程从碰运气变成可预期：要求最低一笔 ERC-20 的调用，会在签名弹窗之前就被钱包检查一遍，避免批量事务在中途某一步炸掉。规范同时允许 dApp 干脆不用这套能力，自行处理条件满足的流程，所以它不是强制标准，更像一份通用备忘录。

边界与风险

要清楚三件事。第一，这是钱包与 dApp 之间的约定，链上并没有一个合约在强制执行这些条件；条件是否真的被检查，取决于钱包实现，最终防线仍是链上合约自己的要求检查。第二，条件表达的是最低要求而不是精确要求，凑齐余额不等于整批调用一定成功，价格、滑点、合约状态变化仍可能让执行失败。第三，能力声明是版本化的，钱包返回 supported 但版本不匹配时，行为可能有差异，遇到批量调用异常时可以把“版本口径”当成排查方向之一。

怎么用好它

一次铸造失败的完整复盘

设想一个典型场景：你用一个接了批量调用能力的钱包参与某个需要 ERC-20 支付的 NFT 铸造，dApp 把“检查授权、划转资金、执行铸造”三笔调用打包成一次签名。如果第 2 步因为钱包里该代币余额不足而 revert，整个包全部回滚，这一轮你付出的 gas 不退还。接入 ERC-7795 的理想流程里，钱包在弹签名框之前就按 dApp 声明的 erc20MinBalance 算了一遍账，发现缺口就引导你先去兑换或转入，失败点从链上挪到了链下。反过来说，如果你的钱包在执行前既没提示余额也没提示授权，有两种可能：dApp 压根没声明能力，或钱包没有实现——这时批量调用退回到“裸签多笔”的原始风险，逐笔核对调用列表就格外必要。

顺带说明它与其他批量相关标准的关系：EIP-5792 定义批量签名骨架，ERC-7821 定义账户侧执行内核，ERC-7795 填的是执行前那一步检查，三者串起来才是完整的批量操作链路，任何一环缺失时行为都会退回到旧模式。

如果你操作的是多步 NFT 流程，优先选择支持批量能力、并且会展示前置条件的钱包；看到钱包在执行前提示补充授权或余额，说明检查在起作用；如果钱包对条件毫无反应，也不要因此放松——那可能只是它没有实现这个能力。批量授权仍然要逐笔看清 to 地址和 calldata，检查前置条件和检查授权范围是两件互补的事，不能互相替代。本文为机制说明，不构成任何投资建议。