ERC-7710 授权赎回：应用替你在钱包上执行操作之前要验什么

“用我的账户替我签这一单”——智能合约钱包时代的授权流转需要一个统一出口，ERC-7710 就是那个出口：它定义 DelegationManager 合约上的 redeemDelegations 函数，让持有授权的应用或代理，以一致的方式在钱包合约上执行被委托的操作。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该提案状态为 Draft。

三个数组必须等高

redeemDelegations 收三个数组：_permissionContexts 装“凭什么执行”的权限凭证字节，_modes 装“按什么行为执行”的模式字，_executionCallDatas 装“具体执行什么”的调用数据。三者按同一个下标配对成一组组赎回元组，长度不一致必须整体回退。这里的 mode 与执行数据不是自造格式，而是直接引用 ERC-7579 模块标准里执行行为部分的定义——单发调用、批量调用等行为编码都能复用。规范还明确要求批量必须原子：一批里每一条要么全成，要么全废，不允许执行到一半留下半套状态。

流程上谁验证谁：应用（被委托方，即赎回方）调用 Delegation Manager 上的这个函数，Manager 校验权限凭证有效后，再回头调用钱包一侧约定的特权执行入口。注意一个边界——委托怎么“发出去”并不在本提案范围内，获取授权的方式可能走 ERC-7715 那类执行权限请求协议或其他定制流程；ERC-7710 只管“赎回时怎么验、怎么执行”这半程。

先模拟，再执行

接口没有内置“查询我还剩哪些授权”的函数，规范给的建议是：应用在执行前先模拟一遍 redeemDelegations，用模拟结果确认权限仍在范围内、调用不会失败。对用户，这意味着一条实用纪律：任何声称走 ERC-7710 代执行的应用，都要能在弹窗之外给出可核对的三样东西——它引用了哪份权限上下文、mode 是什么、调用数据指向哪个目标地址和函数。批量执行把多笔操作压成一次签名，省 Gas 也省点击，但一次误签的爆炸半径同样更大。

和 NFT 场景的连接

一个具体场景：游戏批量领取

设想一个游戏化 NFT 应用要做“每日批量领取加自动挂单”。传统做法要用户点两次签名、等两笔链上确认；走委托路线时，用户先通过授权流程给会话密钥圈定范围，应用之后每天调用一次 redeemDelegations：三个数组等长排列，每条元组带着一份指向那次授权的权限上下文、一个批量模式的 mode 和拼好的领取与挂单数据，Manager 逐条验证后交给钱包执行，整批要么全成要么整体回退。用户体验上从“每天三次弹窗”变成“装好之后的静默运行”，这正是规范所谓“更接近对话式的钱包连接”的由来。静默的另一面是审计责任转移给了权限上下文本身——凭证写得越宽，静默运行的风险敞口越大，所以规范的模拟先行建议才值得每个接入方当成硬流程而不是可选项。

权限从哪来：与 ERC-7715 的接缝

本提案把“获取授权”留在范围外，但生态已经给出常见答案：ERC-7715 的执行权限请求流程里，应用向钱包提交一份结构化请求——目标合约、可调函数、金额或代币范围、过期时间、调用次数上限，钱包据此渲染可读弹窗并签出发放凭证。回到 ERC-7710 的视角，那份凭证就填进 _permissionContexts。用户侧的核对因此有了抓手：凡是绕开请求流程、直接要一个“宽泛长期令牌”的应用，等于放弃了标准化的可读性红利，风险直觉应当立刻拉响。

挂单、批量认领、设置授权这类操作最容易被打包进委托执行。判断标准不变：授权的有效期、可操作代币范围、可调用函数范围越具体越好，“全系列无限期”永远是高风险选项。提案尚未定稿，各钱包实现进度不一，接口细节以仓库正文为准。本文为协议机制科普，不构成任何投资建议；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。