授权也会过期：ERC-8255 给代币审批加上有效期

在链上资产被盗的案例里，攻击者往往不是破解了私钥，而是利用了用户多年前随手点下的一笔授权。只要这笔授权没有被撤销，合约就一直有权从账户里划走资产。ERC-8255 提出一个直白的思路：授权不该是永久命令，它应该到期作废。该提案在 ercs 仓库中的状态是 Draft（草稿），创建于 2026 年 5 月 6 日，扩展的对象是 ERC-20 代币标准，如果合约同时实现了 ERC-2612 的 permit 签名授权，也一并受同一套规则约束。

三个函数与一个事件

按规范文本，兼容 ERC-8255 的合约要在 ERC-20 之外实现三样东西。第一个是 maxApprovalDuration()，返回一个以秒为单位的常量上限，表示普通授权从创建起最长能有效多久，它同时也是普通 approve 的默认时长。第二个是 approveForDuration(spender, amount, duration)，允许授权人自选时长，但自选值必须小于或等于上限，超出的调用必须回滚或返回 false。第三个是 allowanceAndExpiration(owner, spender)，同时返回存储的过期时间戳和授权额度——即使已经过期，它也会把原始存储值如实读出来。此外合约会发出 ApprovalExpiration 事件，把授权双方的过期时间戳记在日志里，方便索引器追踪。

过期是怎么算的

规则非常机械：调用 approve 时，过期时间等于 block.timestamp 加上 maxApprovalDuration()；调用 approveForDuration 时，等于当前区块时间戳加上自选的 duration。有一个有意思的边角：duration 传零时，过期时间就等于当前区块时间戳，授权只在当前区块内有效——这相当于制造一笔“只活一个区块”的授权，适合一次性操作。判定方面，只有当过期时间戳小于当前 block.timestamp 时才算过期，恰好等于当前时间戳仍算有效。额度为零的授权会把额度清零，并且应当把过期时间也归零。

过期之后会发生什么

对普通调用方来说，allowance() 在授权过期后必须返回零，transferFrom 必须把过期授权当作零额度处理，也就是说曾经给过的额度一旦过期就自动失效，不需要授权人再发一笔撤销交易。这里的关键收益是：忘记撤销的授权有了自动兜底。需要注意的是，如果实现使用无限额度哨兵值（type(uint256).max），未过期时 allowance 返回该哨兵值，而 allowanceAndExpiration 会返回存储的真实值，两者口径不同，读数据时要分清。另外当转账把未过期额度扣减到零时，实现可能把存储槽清零，此时 allowanceAndExpiration 会返回过期时间零，即使原本的过期时间还没到。

permit 的 deadline 不是一回事

如果合约同时支持 ERC-2612 的 permit，规范特别说明：permit 函数签名、签名数据结构和 nonce 机制都保持不变，不新增时长参数；成功的 permit 授权同样按默认时长规则设置过期。最容易混淆的是 permit 里原有的 deadline 参数——它只规定这份签名最晚可以在什么时间被提交上链，不是授权的过期时间，两者不能互相替代。也就是说，签名提交窗口和授权有效期是两条独立的时间线。

对 NFT 持有者的启发

与灵魂绑定与许可证类接口的分工

授权过期解决的是“额度长期悬空”，而 NFT 侧另有两类锁权接口：ERC-6454 之类的可锁定代币管“这枚资产暂时不许动”，ERC-6147 之类的 Guard 管“转让要通过检查”。它们与 ERC-8255 各管一段，互不替代：市场挂单靠的是转让授权或订单签名，过期授权管的是 ERC-20 划转额度；一场活动结束后，清理工作应当是一次系统性核对——ERC-20 侧的 allowance 有没有归零、ERC-721 侧的 setApprovalForAll 有没有撤销、订单有没有 cancel，三张清单都过一遍才算闭环。把“会自动过期”误解为“什么都不用管”，是对这类标准最典型的误用。

ERC-8255 本身作用在 ERC-20 上，并不直接管 ERC-721 的 setApprovalForAll，NFT 市场挂单常用后者，整个系列的转让权并不因为这个提案而自动过期。但它的思路对所有人都是提醒：给市场、聚合器、铸造页面的授权，本质上是把资产划转权交出去。在支持过期授权的代币上，优先用带时长的接口；不支持的资产上，仍然要靠手动撤销与定期体检。该提案仍是草稿，参数和行为以上线实现为准。本文为机制说明，不构成任何投资建议。