给钱包发通行证：ERC-7715 执行权限请求

链游挂机、批量铸造、订阅扣款——这些场景的共同摩擦是每笔操作都要弹窗签名。ERC-7715（Request Permissions from Wallets）给出的答案是”发通行证”：应用向钱包申请一份写明边界的执行权限，钱包确认后，在边界内的交易可以免逐笔弹窗代执行。该提案状态为 Draft（草案），创建于 2024 年 5 月 24 日，依赖 ERC-4337 与 ERC-7710。本文讲机制与防守要点，不构成任何操作建议。

请求长什么样

应用调用 wallet_requestExecutionPermissions，每条请求包含：链标识 chainId、目标合约 to（可选发起地址 from）、一个权限对象和一个可选的规则数组。权限对象带 type 名字（规范特意强调不同权限不能重名，否则应用要的是 A 钱包给成 B）和 isAdjustmentAllowed——后者决定钱包能否在用户同意前自行收紧额度。规则数组里可以叠加上限：规范给出的例子是 expiry 规则，写明一个 Unix 时间戳，过了就作废。配套还有 wallet_revokeExecutionPermission 撤销、wallet_getSupportedExecutionPermissions 查钱包支持哪些类型、wallet_getGrantedExecutionPermissions 列已生效的授权。

与传统 approve 授权的关键区别

ERC-20 的 approve 是把额度记在代币合约上、对全网公开的长期授权；ERC-7715 的权限记在钱包或智能账户一侧，天然带到期与调用边界，且面向”替我发交易”而非”我能花你多少钱”。两者可以互补：权限的底层执行仍可能落到带许可的调用上。规范的安全考虑一节明确提醒钓鱼风险——应用可以请求权限，名字听起来人畜无害，边界却宽到危险。

授权面板上的防守清单

1. 看 to：通行证只对这一个合约生效，目标地址必须是你正在用的那个应用的官方合约，拿不准就去官方渠道比对。
2. 看规则：有没有 expiry？金额或频次上限是多少？只有”允许批量调用”却没有上限的通行证，等于把油门焊死。
3. 看 isAdjustmentAllowed：应用拒绝任何收紧时值得警惕，正常批量场景通常接受更严的条件。
4. 用完即撤：用 wallet_getGrantedExecutionPermissions 定期列一遍，不用的权限用撤销函数清掉；钱包不支持该标准时，这条就不适用，回到逐笔签名的老路并不丢人。

通行证怎么被”用掉”

授权之后的执行路径值得了解：应用拿着钱包返回的权限上下文，向 ERC-7710 定义的委托管理合约调用 redeemDelegations，附上想要账户执行的具体调用数据（目标地址、金额、calldata 组成的执行结构），由委托管理器核实权限后替账户发出动作。规范还处理了一个边角情况：若涉及的智能账户还没部署，响应里会带上 ERC-4337 风格的工厂与调用数据，让应用先完成部署再兑现权限。这套”先授权、后兑现”的结构意味着权限本身是一份可验证的数据，而不是应用服务器上的记账——它随链走，撤销状态也由钱包与链上管理器共同维护。

权限类型从哪里来

规范刻意不做权限类型的穷举清单：只要应用与钱包双方都支持某个类型名，它就合法；未来新的权限与规则类型应由附加的 ERC 来定义，且必须继承基础结构。这个”开放注册”的姿态带来互操作红利，也带来一种欺诈面——规范原文特别警告：两个不同含义的权限若共用同一个类型名，应用请求的是 A、钱包授予的可能是 B。防守动作因此又多一条：授权弹窗显示的类型名，要能在钱包的受支持类型列表（wallet_getSupportedExecutionPermissions）里得到明确解释；对一个你从未见过的类型名，直接拒绝不需要理由。

权限授权是效率工具，不是信任证明；任何”免弹窗”都以收窄边界为使用前提，本文只讨论防御性操作，不构成投资建议。