EIP-7702-related developer Derek Chiang: EIP-7702 itself has no vulnerability, but it accelerated asset transfers from Binance hot wallets
ZeroDev founder and EIP-7702-related developer Derek Chiang said in a post on X that there is nothing wrong with EIP-7702 itself, and users of wallets that already support the standard, such as MetaMask, Uniswap, and Ambire, need not panic.
This proposal is part of account abstraction and allows an externally owned account (EOA) to sign a “7702 authorization” and then insert smart contract code, thereby completing transactions in batches, for example one-click authorization and swapping. But the same capability also allows attackers to transfer all tokens in a single transaction. In the Binance hot wallet incident, the attacker used this to transfer out ETH, USDT, and another 62 tokens in one transaction; without 7702, transactions would have to be initiated token by token, and they might also compete with the platform’s normal withdrawals for nonce, so 7702 helped the attacker steal funds faster and in greater amounts.
Derek Chiang said that for an attacker to use 7702, they must either possess the private key or trick Binance into signing a 7702 authorization; the latter is unlikely, but it cannot be ruled out before the official postmortem. For wallet developers and companies operating hot wallets, his advice is not to expose interfaces to request 7702 authorization or sign raw messages to the outside world; users should choose well-known wallets.
Original source:
Title: Quick notes on 7702 to dispel fud and keep your funds safe. Publisher: Derek Chiang | Ethlabs (@decentrek) Publication date: 2026-10-30 URL: https://x.com/decentrek/status/2115960332032299192 Source nature: original post by the party concerned Verification status: full text actually read in this request, verified on 2026-10-30 Supporting content: all core statements, including the judgment that EIP-7702 has no vulnerability, the explanation for users of wallets such as MetaMask, the account-abstraction batch transaction mechanism, the analysis that multiple types of tokens were transferred in a single transaction in the Binance incident, the preconditions for attackers to use 7702, and the advice for developers and hot wallet operators
ABAB AI Insight
As the founder of ZeroDev and an EIP-7702-related developer, Derek Chiang’s post is a technical clarification on how account abstraction features were used in a real attack. EIP-7702 allows an EOA to temporarily insert smart contract code by signing an authorization, enabling batch operations. This is designed to improve user experience, such as one-click swaps, but when a private key or authorization is abused, it can also increase the efficiency with which an attacker transfers multiple assets at once.
In the Binance incident, the company has already said in its initial review that it may have involved a DevOps engineer’s computer being compromised, and that no wallet private key leakage was found. Derek Chiang pointed out that if the attacker did not directly possess the private key, they would need to trick Binance into signing a 7702 authorization; the latter is unlikely, but cannot be completely ruled out before the official technical postmortem. His advice focuses on not exposing the relevant signing interfaces to the outside world, which points to the operational security of hot wallets or signing services rather than a flaw in the protocol itself.
This statement positions EIP-7702 as a transitional proposal and mentions that the future EIP-8141 (Frame Transactions) may improve security through multisig and post-conditions. Binance has not yet released a full postmortem, and Derek Chiang’s analysis is an individual technical interpretation by a developer, not a final confirmation of the attack path. The key indicator is whether the official postmortem involves the use of 7702 authorization or related signing interfaces.
ABAB News · Cognitive Law
Account abstraction improves batch operation efficiency while also amplifying the scale of losses when a single authorization is abused.
No vulnerability at the protocol level does not mean that systems using the protocol have no operational risk.
A developer’s clarification that their own proposal was used in an attack does not amount to official confirmation of the intrusion path.