一笔外层转账金额显示为零的交易，内部却转走约16.75万枚ETH，以及约16.15亿枚USDT。币安热钱包这次巨额异动，值得看的不只是余额，更是此前那笔EIP-7702授权：钱还在原地址里，账户执行规则已经变了。
如果安全检查只回答“这笔交易准备转出多少钱”，它就可能漏掉另一个问题：“这次签名，准备让谁的代码替这个账户做事？”后者拿到的权限，未必能用单笔转账额度衡量。
不过，解释机制与宣布破案是两回事。链上能看到授权、调用和资金流向，签名究竟从哪里来，还需要链下取证；把签名机被渗透、供应链投毒或内鬼写成既定事实，都走得太快。
币安热钱包发生了什么，先把交易顺序排清楚
2026年10月29日，币安（Binance）相关钱包出现巨额资金转移。美联社报道，币安表示正在调查潜在安全问题，并称用户资金安全；这项表态不能替代完整的根因报告，也不能拿来计算事件的最终净损失。出处：美联社报道
下面这条路径，可以在链上浏览器Blockscout的交易、授权列表和内部调用记录中复核。这里沿用浏览器的“Binance 14”“Binance 16”地址标签，重点看以太坊上的几笔具体动作，不把其他链的异常转账直接归入同一种攻击。
| 时间（UTC，10月29日） | 链上动作 | 能说明什么 |
|---|---|---|
| 20:20:59 | 向标记为Binance 14的账户设置EIP-7702委托 | 账户开始使用指定代码 |
| 20:24:23 | 调用该账户的sweep方法 |
内部转出约167,464.25枚ETH，并转移大量代币 |
| 20:24:47 | 标记为Binance 16的账户转出28,005.6枚ETH | 资金进入同一收集地址 |
| 20:38:47 | 收集地址再转出195,460枚ETH | 这是后续转出，不能与前面的流入重复累计 |
设置委托与首次清扫之间，相隔三分二十四秒。核对记录时，必须把“改规则”和“按新规则执行”分开看，否则只盯着最后那笔大额转账，就会漏掉入口。链上记录：设置委托、首次清扫
原先流传的“19万余枚ETH单笔从Binance 14转走”，混合了不同阶段的资金流。约19.546万枚ETH确实有一笔后续转账，但它来自收集地址；把它再加到此前流出的ETH上，就像把银行转账和收到钱后的再次转账，各算一遍损失。链上记录：另一钱包转入、195,460枚ETH后续转出
EIP-7702改变的，是账户执行规则
普通外部账户，简称EOA，原本主要靠私钥签名发起交易。EIP-7702让这类账户能够设置一个代码委托，执行所指向合约的代码，获得批量操作、费用代付等智能账户功能；它随2025年5月7日的Pectra升级上线，并非为了攻击而设计。出处：以太坊Pectra说明
这里最容易误解的是“委托”两个字。它不是先把资产搬进另一个合约，也不是把原钱包地址注销，而是让指定代码在原账户的执行上下文中运行，能够影响这个账户的资产与状态。
可以把它理解为：公司账户号码没变，负责处理付款的程序换了。你打开余额页面，可能还觉得一切正常，但下一次有人调用这套程序时，它执行的规则已经不同。
这份委托也不是交易结束就自动消失。它可以跨交易持续，直到被替换或清除；如果某个钱包提供限时会话，那是具体实现增加的权限安排，不能把它当成7702委托天然附带的到期机制。出处：Alchemy的EIP-7702文档
在这条路径中，之后的sweep调用外层金额为零，内部却发生了大额ETH转移。外层金额为零不等于没有资产后果，这也是为什么风控不能只扫一眼交易金额，就盖章放行。
当然，把账户委托给代码，不代表任何调用者都自动获得无限权限。实际能做什么，要看那份代码怎样验证调用者、怎样限制操作；选择什么实现，本身就是一次安全决策。出处：EIP-7702安全考量
EIP-7702的50组授权，到底证明了什么
设置委托的交易里，确实有50组授权。Blockscout解析显示，它们的授权主体都是Binance 14，指向同一个代码地址，使用一段连续的nonce候选值；其中49组因nonce不符未生效，1组生效。
Nonce可以理解为账户用来校验顺序的计数值。这里的50组，既不是50个人投票，也不是50个钱包一起授权，更不能直接写成“50人多签被攻破”。可复核数据：交易授权列表
关键约束在于，授权需要有能对应到该EOA的有效签名，并满足协议校验。负责提交外层交易、支付手续费的人，可以与授权账户不同；所以“交易由另一个地址发起”，不等于另一个地址能凭空改写你的钱包。出处：EIP-7702规范
有效签名证明的是密码学上的授权关系，不能证明业务上经过了正确审批。它也不能单独证明明文私钥已经被导出。
攻击者可能掌握了私钥控制权，也可能滥用了有权生成签名的接口，或者拿到了此前生成、仍能被协议接受的签名材料。要在这些可能性之间作出选择，需要签名服务日志、权限变更、审批记录等证据，链上不会自动告诉你是哪位员工、哪台机器出了问题。
覆盖多个nonce的做法值得调查，但它同样不能替代这些证据。看懂了一组链上参数，不代表已经看到了攻击者的整段入侵录像。
私钥没有离开保险箱，业务也可能签错
签名机、密钥管理系统（KMS）或内部权限问题，都是值得调查的方向。不过，应该写成调查假说，不能直接宣布这次事件的根因就是“交易所签名流水线不认识7702”。
以亚马逊云服务（AWS）的KMS文档为例，签名接口可以使用密钥，对消息或摘要生成签名，调用者需要相应签名权限。从工程上说，保护密钥不被导出，与判断这份消息是否符合业务意图，属于不同的控制目标；这个例子不代表币安使用了该服务。出处：AWS KMS签名接口说明
假设一套系统只审查普通提款的收款地址和额度，却允许同一条签名通道处理改变账户执行规则的授权，那么即使私钥没有离开受保护环境，它也可能签出危险指令。这是需要防范的架构情形，不能反过来当作币安已经存在该缺陷的证据。
同样，API凭证、私钥分片和完整签名能力也不能混着写。拿到某个凭证是否足以触发签名，泄露一个分片是否达到门限，都取决于具体权限和实现；“多签”“MPC”这些名词本身，并不回答谁能批准什么。
还有一个容易被忽略的边界：EOA委托后，原始私钥仍保留控制能力。以太坊的开发指引特别提醒，把EOA委托给多签钱包代码，并不自动让它变成原私钥无法绕过的合约多签账户。出处：以太坊7702开发指引
我的判断是，这起事件最值得追问的，是高价值账户的签名权如何被约束。看到合法格式的签名，就宣布密码学失败，或宣布所有合约都没有问题，都不够严谨。
稳定币能被冻结，为什么ETH仍能转走
资金转移之后，链上出现了针对收集地址的冻结动作。USDT相关交易日志中，可以看到正式代币合约发出的AddedBlackList事件；USDC则有一笔成功的blacklist调用，目标也是该收集地址。链上记录：USDT黑名单事件、USDC黑名单调用
这说明发行方动用了代币层的控制能力。它限制的是相关稳定币的后续转移，不是把该地址上的所有资产一起封住，也不是将此前的链上交易倒带。
Circle的帮助文档明确区分了黑名单冻结与撤销交易：限制地址发送或接收USDC，不等于能够撤回已经完成的转账。因此，“冻结了多少钱”“最终追回多少钱”“用户最终损失多少”，需要分别核算。出处：Circle冻结机制说明
原生ETH则没有Tether或Circle那样的发行方黑名单按钮。对一个地址冻结USDT或USDC，不会顺便冻结它的原生ETH；但这也不代表追赃绝无可能，后续仍可能涉及司法调查及资金进入受控平台后的处置。
这里也别补出一个没有证据的剧情：“转到新地址，所以已经完成混币。”中转、兑换、进入混币服务和最终兑现，是不同动作；本次能核到195,460枚ETH后续转出，不能据此宣布整批资金已经被洗白。
平台要审查权限变化，用户要看清自己签了什么
如果由我来审查这类系统，我会把改变账户执行规则的授权，与普通转账分开审批。不需要7702的业务默认不签这类授权；确实需要时，再明确允许的链、代码实现、初始化与权限条件，而不是让它混在日常提款流里。
审查也应延伸到执行后的状态。除了余额和收款方，还要看账户代码委托有没有变化、哪些权限会持续存在，以及所指实现是否可能升级；模拟执行可以帮助发现问题，但不能代替对实现和权限的审查。
对托管平台而言，还需要限制热钱包承担的资产规模，并准备异常时停止签名、自动补款和相关业务的处置路径。否则一个地址已出现异常，其他自动化流程却继续按旧假设运作，风险就可能扩散。
普通用户不需要因此放弃全部智能账户功能，但应知道“连接钱包”“批准代币额度”和“设置账户委托”不是同一件事。清掉ERC-20的approve额度，不代表7702委托也被移除了。
可以通过钱包官方提供的账户功能查看、管理或撤回支持的智能账户设置。MetaMask的官方说明也提醒，智能账户仍由原私钥控制；如果私钥已经泄露，仅仅撤销委托，不能让旧钥匙重新安全。出处：MetaMask智能账户说明
若怀疑钱包正在被自动清扫，不要盲目往里面补ETH当手续费，应先通过可信渠道寻求协助。也别因为看到交易所新闻，就去签所谓“补偿领取”或“紧急解冻”的陌生请求；着急处理第一场事故时，很容易又批准了第二场。
小结
EIP-7702让普通账户获得可编程能力，也让签名审查必须回答更多问题：这次允许谁的代码执行、权限如何限制、变化会持续多久。
币安相关钱包的链上路径，能够支持对委托、清扫和资金归集的分析，仍不足以把私钥泄露、签名接口滥用或内部权限问题中的任何一种写成最终结论。把事实和假说分清楚，才能知道下一份取证报告究竟补上了什么。
下次看到钱包弹出签名请求，先看它批准的是一笔操作，还是账户未来的执行规则。对平台也应问同一个问题：你保护的是钥匙本身，还是连“这把钥匙可以签什么”也管住了？