你授权某个交易平台或协议动用你的代币之后，按 ERC-20 的原生规则，只有你自己——授权的所有者——能改这个额度。ERC-7410 提出了一个方向相反的小扩展：让支出方也能主动把别人给它额度降下来甚至清零。这个提案在标准仓库中标注为草案（Draft），下面按”它改了什么、谁需要它、你现在能用上吗”三层讲清楚。
规则本身：一个函数、一条事件、一个编号
按规范，支持该扩展的合约要实现 decreaseAllowanceBySpender(address owner, uint256 subtractedValue) 这个外部函数：任何被授权的支出方，都可以对 owner 给自己的额度执行下调。下调量 subtractedValue 大于或等于当前额度时，新额度直接归零——规范特别强调，哪怕当前额度是无限额度（type(uint256).max），也必须同样归零。每次调用都要发出 ERC-20 已有的 Approval 事件，所以区块浏览器上这条降额和普通授权变更长得一样，都能在授权记录里查到。合约还须通过 supportsInterface 应答接口编号 0x12860fba，这是 ERC-165 的标准查户口方式：工具在调用前先问一句”你支持吗”，不支持就退回常规路径。
提案自己给出的理由：所有者动作慢的那些钱包
规范在动机部分点名的场景是国库钱包和多签钱包。这类钱包给外部协议批了额度之后，想降额要走多签人凑齐签名那一套流程，慢是结构性的；而真正第一时间察觉风险的往往是支出方自己——协议发现代码可能被攻击时，最希望的是立刻停止动用所有客户的授权额度。此时与其等几百个所有者各自操作，不如支出方发一笔交易，把每位所有者给它的额度统一下调。安全语义上也更稳：支出方先降额，再处理漏洞，即使事后有人想利用旧额度做文章，可动的余量已经缩小。
别和所有者侧的降额搞混
普通用户更熟悉的是所有者侧的两条路：直接 approve 改成新值，或者用 decreaseAllowance 往下减。USDT 一类老合约还有一条”改额度要先归零再设新值”的双交易规矩，来龙去脉在USDT改授权为什么要发两笔交易：approve先归零规则的来龙去脉里讲过。ERC-7410 动的不是这两条路，而是第三条：发起签名的是支出方合约而不是你。对普通用户,这意味着一个此前不存在的撤销通道——但注意，它撤销的是”你给某协议的那份额度”，动作者换成了对方，你要确认的是对方是否真通过合约公开实现了这个接口，而不是任何声称”帮你一键降额”的网页。
你现在能不能用到
三层现实先摆清楚。第一，它是草案，实现面很小，主流代币合约大多没有这个函数，用 ERC-165 编号 0x12860fba 在浏览器上查一下 supportsInterface 就知道目标合约支不支持。第二，即使支持，支出方降额发出的 Approval 事件仍然只说明额度字段变了，不等于授权清单上别家协议的安全——日常盘点仍按链上授权与取消授权：先查清单、再按需撤销的安全习惯的”先查清单、再按需撤销”来做。第三，多签组织如果同时是所有者又是支出方，两种身份的签名流程完全不同，前者要凑签名，后者一笔交易就行，别把两条路径的操作纪律弄混，多签侧的排队规则见多签钱包只有一个全局序号：Safe 的 nonce 怎么让交易互相排队与替换。
一个值得记住的权限视角
这篇的真正用处是给你换一副眼镜：过去你把”授权”当成一面只在自己手里有开关的闸，ERC-7410 提醒你闸门的另一侧也可能装开关。评估任何长期授权时,除了问”我什么时候撤”，还可以加问一句”对方有没有能力、有没有承诺在出事时主动降额”——这个能力目前只能从已验证的合约源码里查，而不是从公告里读。
风险提示：授权额度的任何变化都可能影响你资产的在控状态，降额通道是否真实存在以链上合约实现为准，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。