In the Binance hack, is EIP-7702 responsible for making the damage worse, or is it just a neutral tool and the real problem is the key leak?
Protocol design · 7 participants · 7 quotes · 2026-10-30 ~ 2026-10-30
decentrek, an account abstraction contributor, said EIP-7702 itself is not broken, but its batching feature did help the hacker drain 64 tokens including ETH and USDT in a single transaction and so made the damage worse. They urged improving operational practices and moving to endgame account abstraction such as EIP-8141 frame transactions. FigoETH, AzianMike, ETH_MAXER and others countered that 7702 is a safe, neutral UX tool and that the problem is the private key leak and Binance's sloppiness.
Background
EIP-7702 (Set Code for EOAs), proposed by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and lightclient and now in Final status, lets an externally owned account (EOA) delegate smart contract code to its own account through a special signature called a '7702 authorization', enabling batching that bundles approve and transfer into one transaction. In the Binance hack, the hacker used this feature to drain 64 tokens including ETH and USDT in a single transaction. Without 7702, each token would have needed a separate transaction, and many would likely have failed while competing for the nonce with legitimate withdrawal transactions. EIP-8141 (Frame Transaction, Draft), which decentrek named as the endgame, is an account abstraction proposal that builds accounts only from multisig contracts and lets post-conditions such as 'no transfer above 1000 ETH without an additional signature' be set on the transfer function. EIP-8141 is currently being tested on bogota-devnet-1.
Why it matters
Whether the side effects of transitional account abstraction are fixed through protocol design or prevented through operational practice will shape the priority and pace of the account abstraction roadmap. The points to watch are whether the rule of not exposing 7702 signing endpoints becomes a standard among wallets and exchanges, and whether EIP-8141's post-conditions make progress on devnet.
Key points
- Does EIP-7702's batching feature structurally increase hack damage, or does the scale of damage come from the root cause, a private key leak?
- Is an operational rule that wallets and exchanges must not expose 7702 authorization or raw message signing endpoints enough?
- Is endgame account abstraction, such as the post-conditions of EIP-8141 frame transactions, the fundamental solution?
For — 7702 made the damage worse, so it needs safeguards and caution
Derek Chiang | Ethlabs, Liberty Swap | C.R.O.P.S. on PulseChain 🗽, louisli.eth |💊| BIP-360
- 7702 itself is not broken, but its batching feature helped the hacker drain 64 tokens including ETH and USDT in a single transaction, stealing as much as possible as fast as possible.
- Wallet developers and exchanges that run hot wallets must never expose a 7702 authorization or raw message signing endpoint, even for internal use.
- 7702 is only a transitional EIP. With EIP-8141 frame transactions, Binance could have built its wallets only as multisigs and set post-conditions such as 'no transfer above 1000 ETH without an additional signature', limiting the damage even if the key was stolen.
- More than 40% of 7702 authorization accounts across 8 chains used a hacker contract, which shows that a feature promoted as a UX improvement is being seriously abused in practice.
- MetaMask enables 7702 by default, so users have to turn it off themselves, and it is better not to use it for the time being.
Against — 7702 is a safe, neutral tool and the problem is the key leak
figo.eth, Michael Luo, Eon Seongjae
- 7702 is safe (safu) and the problem is Binance. For the hacker to use 7702, they either had the private key or tricked Binance into giving a signature.
- 7702 only sped up the hacker's movement. The root cause is the leak of the private key and permissions, and 7702 is a purely neutral tool for better UX.
- In the end, the problem is that the all-in-one wallet's private key was stolen, not the wallet or 7702.
Neutral — The root cause may be the signing infrastructure, not the key
Odysseus | phylax.systems
- It may not be the private key itself but the signing infrastructure that was breached.