授权只在这一笔交易里有效：ERC-7674 临时授权用完即焚

对 ERC-20 的 approve 授权，老用户的共识是两条：要么不批，要么批完记得撤销。痛点在于“记得撤销”这件事本身就是风险敞口——你在 NFT 市场签过的那张无限额度授权，可能一躺几年。ERC-7674 ERC-20 临时授权扩展（Temporary Approval Extension for ERC-20）给出第三条路：授权的生命周期缩短到一笔交易之内。标准状态为 Review，创建于 2024 年 4 月 2 日，依赖 ERC-20 与 ERC-1153。

一个函数与它的生命周期

接口只比 ERC-20 多一个函数：temporaryApprove(spender, value)。它赋予 spender 在同一笔交易内代表你花费的额度，可以多次调用 transferFrom，总额以 value 封顶；这笔临时额度与正常永久额度并行存在，spender 在同一交易内能花的是两者之和。标准给了消耗顺序的建议：优先消耗临时额度，临时不够时才去读写永久额度的存储——这既是 gas 优化，也让“用完即焚”的语义尽量不波及长期授权状态。硬约束是两条 MUST：临时额度必须存活到创建它的那笔交易结束（除非被新的 temporaryApprove 覆盖或被 transferFrom 消耗），并必须在该交易结束时清除。

查询侧有个兼容注意点：allowance 必须返回临时加永久的合计，两者相加溢出时返回 type(uint256).max。标准的事件不是强制的，但建议实现可发一个 TransientApproval 事件方便索引器观察临时授权历史——否则这类授权在交易结束后于状态层面完全无痕。

实现层面，标准点名 ERC-1153 瞬态存储（TSTORE/TLOAD）：临时额度天然适合放在“交易结束自动清除”的存储槽里。槽位推导示例是给每个 owner 与 spender 组合算派生哈希——以合约自定义的命名空间常量为起点，逐层 keccak 拼接，避免同一空间内槽位互相踩踏；安全考量一节专门警告了这一点，瞬态存储槽位碰撞是这类扩展最直接的新风险。

它解决与不解决什么

解决的：批量操作场景最受益。一场铸造连续划转多笔代币、一个结算合约分几路扣款，过去要么预先挂一张长期授权、要么在流程里反复授权再撤销。有了 temporaryApprove，在同一笔交易的开头声明“这次总共允许花多少”，交易结束授权自动蒸发，授权残留这个长期攻击面被结构性压缩。

不解决的：它的前提是“你已经决定在这次调用里信任某个合约”。跨交易的风险它完全不管，它替代不了你对目标合约的甄别；被钓鱼者诱导签一个包含恶意 temporaryApprove 调用的交易，照样一笔成交就中招，区别只是这次损失有硬顶（value 的额度封顶）。与签名授权类方案（用签名换 approve）相比：那类解决“授权怎么免 gas 提交”，674 解决“授权存续多久”，两者正交，可以叠加也可以各缺其一。

落地前的现实核对清单

判断一笔授权属于哪类，决定你之后的检查位置：临时授权在交易后的链上状态里查不到残留（除非项目发了 TransientApproval 事件可查历史）；永久授权仍要用 revoke 或改小额来清理。活跃玩家的优先级：优先选支持 674 结算流程的合约与钱包路径，长期额度越少、撤销负担越重的事越少。给普通读者的操作版总结：交易确认页看到 temporaryApprove 字样，核对本笔上限数字与调用来源合约；看到永久 approve，保持“能撤销就撤销”的旧习惯；两套并行时，用定期扫描授权面板兜底。

存储细节决定实现质量：临时额度必须与永久额度使用不同存储槽，参考做法是以合约内唯一命名空间常量为起点，按 keccak256(spender . keccak256(owner . p)) 这类嵌套哈希派生瞬态槽位——命名空间选得潦草，槽位冲突可能让两个用户的临时额度互相覆盖，这是临时授权独有的新攻击面，审计时应要求实现方给出槽位推导说明。 最后提醒：本文讲授权机制与防御要点，不构成投资建议；任何授权都可能被合约逻辑在其范围内消耗，操作前请核对合约地址与调用参数。