如果你最近在搜「EIP-7702 是不是很危险」「钱包里多出来的授权要不要撤销」，多半是被 Binance 那起 63 亿美元黑客事件的相关报道吓到了。先把结论说清楚：EIP-7702 不是这次被盗的起因，调查方没有发现钱包私钥泄露，问题出在签名环节——攻击者拿到了签名基础设施的访问权，让签名器签了一笔本不该签的交易。但安全公司 Blockaid 同时指出，7702 可能被用来绕过提现防护、把原本需要多笔交易才能完成的清扫压缩成一次批量操作。对你我这样的普通钱包用户来说，真正要处理的问题不是「以太坊升级坏不坏」，而是「我手上有没有指向恶意合约的 7702 授权，有的话怎么查、怎么撤」。
EIP-7702 到底是什么，为什么会被卷进这次事件
EIP-7702 是以太坊在 2025 年 5 月 Pectra 升级中引入的改进提案，核心作用是让普通钱包临时具备智能合约能力：可以一次发起多笔操作（批量交易），也可以由第三方代付 Gas。听上去是体验优化，但它改变了一个关键前提——过去普通钱包地址只能用自己的私钥签名转账，现在这个地址可以被「委托」给一段合约代码执行，授权一旦签出去，后续行为就由那段代码决定。
问题就出在这里。2025 年 5 月，做市机构 Wintermute 就报告过，早期绝大多数 EIP-7702 授权都指向了恶意合约，这些合约被设计成自动转走被入侵钱包里的资产；到 2025 年 9 月，World Liberty Financial 代币持有者也报告了与恶意 7702 授权相关的损失。以太坊社区成员 VEER 在评论 Binance 事件时说得很直白：这次攻击看起来比单一恶意签名范围更大，但 7702 确实给了攻击者「在以太坊上一键清扫的按钮」。注意这句话的分寸——是放大器和快捷键，不是入口。
再看 Binance 这边的事实链：交易所确认遭遇 63 亿美元盗窃并承诺承担全部损失，CEO Richard Teng 表示没有发现私钥泄露的证据；Blockaid 联合创始人 Ido Ben-Natan 的判断是，攻击者很可能先入侵了一台开发者电脑，进而接触到钱包签名基础设施，最终让一个保管热钱包的签名器签下了不该签的交易。钱包服务商 Ambire 的 Ivo Georgiev 补充说，黑客本来就有能力发起授权交易，7702 对这次攻击「几乎没有影响」，但他特别提醒：工程师在重新接管系统后，很容易忽略撤销恶意 7702 授权这一步。
动手之前先搞清楚：你的钱包里哪些东西算「授权」
很多人把「授权」和「转账」混为一谈，其实两者差别很大。转账是你主动把资产发出去，链上立刻可见；授权是你允许某个合约在将来动用你某类资产，额度可能是无限，而且签完之后钱包界面往往不会一直提醒你。EIP-7702 带来的是一种更底层的授权——把地址的执行逻辑委托出去，它不像 ERC-20 的 approve 那样在钱包里显示成一个明确的「额度」，所以更容易被忽略。
准备阶段你需要三样东西：一是这个钱包地址在以太坊主网上的完整交易历史（用来回溯授权记录），二是一个能读取 7702 委托状态的区块浏览器或授权检查页面，三是少量 ETH 作为撤销时的 Gas。这里有个容易踩的坑：不要用「余额看起来没少」来判断安全，恶意 7702 合约的常见做法是潜伏，等你有大额入账时再自动清扫；也不要只在手机钱包里翻记录，很多委托关系在钱包 UI 里根本不展示，必须去链上看。
另外提醒一句，检查时优先用你自己长期持有、金额较大的地址，而不是临时撸活动说明的小号。攻击者盯的是有余额的地址，小号即使被授权，损失也有限，反而会让你误以为「没事」。
怎么查自己的地址有没有被 7702 委托，具体看哪几个位置
第一步，打开以太坊区块浏览器，输入你的钱包地址，进入账户详情页。重点看两个地方：一是账户类型标识，如果这个地址被设置了 7702 委托，通常会显示为带有委托代码的账户，而不是普通的 externally owned account；二是交易列表里有没有你本人没有印象的、由第三方发起但涉及你地址的调用记录。看到「delegation」相关字样或代码字段不为空，就要进一步核对委托指向的合约地址。
第二步，把那个被委托的合约地址单独搜出来，看它的创建时间、部署者、历史交互对象和是否被安全平台标记。判断标准很实际：如果合约是几天内新部署、部署者地址只做过这一件事、交互记录里全是零散个人钱包，基本可以按恶意处理；如果它属于你主动用过的正规批量工具或代付服务，你应当能回忆起当时是在哪个界面签的。
第三步，回到钱包端做交叉验证。以常见的以太坊钱包为例，在账户设置或安全中心里找「已连接的站点」「授权管理」「合约授权」这类入口，逐条核对每个授权的对象、额度、最近使用时间。发现不认识的委托或无限额度授权，先不要急着操作，把合约地址复制下来，去安全公司的授权检查工具再查一遍，确认风险等级后再决定是否撤销。做错的地方通常是：看到可疑就直接点「撤销全部」，结果把正常在用的定投、质押或批量转账授权也一起断了，后续还要重新配置。
发现恶意 7702 授权后怎么撤销，操作顺序别弄反
撤销的动作本身不复杂，顺序错了会白花钱。正确做法是：先在钱包的授权管理里对可疑条目发起「撤销」或「取消委托」，把交易的 Gas 上限调到一个合理区间（普通撤销交易通常在几万到十几万 Gas 量级，具体以钱包预估为准），确认收款地址和调用目标是撤销合约而不是转账；签名前最后核对一遍弹窗里的合约地址，和你刚才查到的恶意地址是否一致。签名后等交易上链确认，再刷新区块浏览器，确认委托字段已经清空。
如果钱包界面根本不提供撤销入口，就走备用路径：用区块浏览器连接钱包，直接对 7702 委托合约调用清除委托的方法，或者把委托重新指向一个空实现。这条路径要求你对 ABI 调用不陌生，填错参数可能产生一笔无效交易甚至新的风险，所以更稳妥的做法是先把资产转到一个全新生成、从未签过任何授权的地址，再慢慢处理旧地址。转账时注意，如果旧地址已经被恶意委托，转出操作本身也可能被拦截或替换，务必先小额测试一笔。
还有一个容易被忽视的动作：撤销完成后，检查该地址的其余授权（ERC-20 approve、NFT 的 setApprovalForAll）是否也需要清理。Binance 事件里 Georgiev 提醒的那一点同样适用于个人——系统「恢复」之后人们往往只处理眼前的问题，忘了把攻击者留下的后门关掉。
普通用户要不要因为这次事件放弃使用 7702 相关功能
不必一刀切。EIP-7702 的设计目标是批量交易和代付 Gas，这两项对经常做多步操作的人是实打实的效率提升。真正该收紧的是签名习惯：任何一次 7702 委托，都要看清委托对象是谁、这个合约有没有被审计、是不是你主动访问的官方界面发起的。Ben-Natan 在评论里提到，交易模拟可以帮助在恶意请求被批准之前识别出来，所以签名弹窗里如果提供了模拟结果，别跳过，逐行看资产变化。
相对地，如果你只是长期持有、极少操作，那更适合保持「零授权」状态：不连接不熟悉的站点，不签看不懂的委托，不用来历不明的批量工具。对这类用户，7702 带来的便利远小于潜在风险，选择不参与是完全合理的。至于把资产放在交易平台的人，这次事件的教训不在用户侧，而在机构侧的签名权限管理——个人能做的是关注平台是否披露了签名系统加固和授权清理的进展，而不是自己在家焦虑。
常见问题：没被盗但收到异常签名请求，算不算已经被盯上
算信号，但不等于已经失守。收到异常的 7702 委托请求，说明你的地址已经进入某个钓鱼名单或批量扫描范围，攻击者正在试探你是否会签。此时不要签名、不要为了「看看是什么」而确认，直接关闭页面并把该站点从钱包连接记录里删掉。随后按上面的步骤做一次全量授权检查，重点看有没有你不知情的委托已经生效。
另一个高频疑问是「交易平台被盗，我的币在平台上还安全吗」。从公开信息看，Binance 承诺承担全部损失，且调查未发现私钥泄露，普通用户的账户余额不受链上 7702 授权影响——受影响的是平台热钱包的签名流程。你需要做的区分是：资产放在平台账户里，风险和平台的风控绑定；资产放在自托管钱包里，风险和你的签名习惯绑定。两者不要混着判断。
适用边界说明：本文的检查与撤销步骤适用于以太坊主网及已启用 Pectra 升级相关功能的网络上的自托管钱包，不适用于中心化平台内部账户（你无法也不应直接操作平台的签名系统），也不适用于把资产全部托管在交易平台、从不自建钱包的用户。不适用的情况还包括：地址已被完全控制、私钥确认泄露——这时撤销授权没有意义，正确做法是立刻生成全新地址、转移剩余资产，并停止使用旧地址接收任何入账。如果你不确定自己的地址属于哪种状态，先做一件事：把这个地址的委托字段和最近十笔交易截图留存，再找有链上分析经验的人帮你逐笔核对，别在没看清的情况下连续签名。
