图片资料：官方来源
EIP-7702引入的授权机制，常被误解为一种“一次性”操作：交易执行完毕，授权似乎就该随之消散。但规范所定义的行为恰恰相反——通过有效授权元组写入的委托指示器是持久存在的状态变更，它不会因为交易结束而自动消失，也不会因为同一交易中执行阶段发生revert而被回滚。理解这一点，需要把“设置委托”和“执行业务逻辑”看作两个不同层面的状态变化。
先看写入路径。当一笔交易携带有效的授权元组时，协议会处理该元组并把委托指示器写入相应账户。这个写入动作发生在执行阶段之前，属于授权处理本身的结果。随后交易进入执行阶段，若业务调用因条件不满足而revert，回滚的是执行阶段产生的状态变更，而已经处理的委托指示器并不在执行回滚范围内。换句话说，执行失败不等于授权失败。两者虽然同处一笔交易，却分属不同的处理环节，回滚边界并不重叠。这也解释了为什么有人看到交易“失败”却仍发现委托已经生效——失败的是业务执行，不是授权写入。
由此可以进一步区分两个概念：设置委托与业务执行是不同状态。设置委托改变的是账户的代码指向关系，属于账户层面的持久配置；业务执行则是该账户在具体调用中做了什么、是否成功。把二者混为一谈，就容易产生“交易结束授权就没了”或“执行revert授权就撤了”的错觉。规范事实是，有效授权元组一旦被链处理，委托指示器便留存下来，后续交易仍会看到这一状态。至于具体操作层面如何发起、如何管理这类授权，取决于钱包的支持情况，不同钱包的处理方式并不一致。
那么如何移除委托？同样需要一笔交易，携带有效的零地址授权元组，并且该元组实际被链处理。这里的关键词是“有效”和“实际被链处理”：链ID、nonce、签名都必须符合要求，否则元组可能被跳过，委托指示器不会改变。空授权列表的交易则是无效的，不能指望用它来完成清除。需要强调的是，清除委托并不等于撤销ERC20额度，两者是不同层面的授权，不能互相替代；清除委托也不能证明此前没有发生过损失，它只改变未来的代码指向关系，不追溯已经发生的事实。检查当前代码和查阅历史记录回答的是不同问题：前者告诉你现在委托指向何处，后者告诉你过去发生过什么，二者不能相互推断。
因此，EIP-7702授权的持久性并非设计疏漏，而是规范有意为之的状态模型。有效授权元组写入的委托指示器留存于链上，执行阶段的revert不触及它；移除需要另一笔有效的零地址授权被实际处理。把设置与执行分开看，把当前状态与历史记录分开看，许多关于“授权为何还在”的困惑便会自然消解。