钱包弹窗从一个变三个还没完？EIP-5792 批量调用与 NFT 多步操作

做一次 NFT 空投认领，常要经历“授权代币、认领藏品、设置所有权”三步，每步一次确认、一次手续费，新手还容易在某一步失败后留下半完成状态。EIP-5792（Wallet Call API）就是为这类场景准备的钱包侧接口：它让应用把多笔调用一次性打包交给钱包，由钱包决定怎么执行、怎么报告状态。该提案为 Interface 类标准，提案页当前状态是 Final，创建于 2022 年 10 月 17 日，依赖 EIP-1193。本文按提案文本解释机制，不针对任何具体钱包做功能承诺。

为什么 eth_sendTransaction 不够用

规范动机写得很直接：开发者想把多笔调用装进一次 RPC 请求，很多智能账户能在同一笔交易里原子执行它们，还想用上 ERC-4337 里 paymaster 这类新交易能力，而 eth_sendTransaction 既没法表达“一批调用”，也没法表达这些附加能力。EIP-5792 的思路是加一组 wallet_ 前缀的 JSON-RPC 方法：三个方法负责发起批量调用与查询执行状态，一个方法查询钱包到底支持哪些能力。与 NFT 相关的典型收益场景：铸造加设置加挂单可以一笔交出去；用智能账户时还能顺带用费代付。规范对四个方法的分工也写清楚了：三个方法负责发起批次与查询批次状态，第四个方法让应用先问钱包支持什么再决定怎么调用，这种“能力协商先行”的姿态是这组接口区别于旧式硬塞参数写法的根本。

原子性是这个接口里最该看懂的字段

批量执行有两种态度。atomicRequired 设为真时，钱包必须原子且连续地执行：要么所有调用全部成功、要么链上看不到任何实质效果，并且中途不许插入别人的调用。设为假时，钱包可以按顺序逐笔执行，一笔失败不保证回滚前面已成功的部分。对 NFT 用户，这意味着一个此前不存在的细节：同样的“一键三步”，在支持原子性的钱包里是成功或全无，在只做顺序执行的钱包里可能是“做了一半停在第二步”，留下授权却丢了认领、或认领却没挂单等中间态。执行前先查 wallet_getCapabilities 报告里钱包对原子性的承诺，是新手最省事的一层保护。

NFT 流程里的实际形态

以“授权加认领加挂单”为例：应用把三笔调用打包发起，钱包端可以合并成一次弹窗审阅、一笔交易上链，失败时整体回滚。反过来，钱包也有明确写进规范的权利：来源地址与当前账户不符时可以拒绝，顺序模拟预判会失败的调用包可以拒绝，出现它不认识且未被标记为可选的能力声明时必须拒绝。规范还允许钱包在有能力时自行升级原子性保证——先升级到支持再提交，而不是默默降级成顺序执行。

实操注意事项

1. 弹窗里出现了“多笔调用”列表时，逐条看清目标合约与操作含义，批量不该等于草率通过。
2. 用 wallet_getCapabilities 确认原子性、账户与费代付支持，再决定把多步流程交给一键操作。
3. 中途失败后不要盲目重试整包：先用规范提供的批次状态查询方法轮询执行结果，再查每笔调用的链上落点，避免重复授权或重复支付铸造费；状态未确认前把上一包视为“可能已部分生效”来对待，远比当作“肯定没发生”安全。
4. 批量接口不改变授权本身的性质，涉及 NFT 所有权授权的项目仍按最小授权原则处理。

本文只讲协议与接口机制，不构成投资建议；钱包对批量与原子性的支持以各钱包官方文档与实际能力声明为准。