EIP-7702, the Ethereum feature added with the Pectra upgrade, was the tool used on Binance 14, one of the hot wallets hit in the Binance hack, and blockchain records show how. A single transaction at 20:20:59 UTC on 29 October carried 50 authorizations signed for that wallet. One was valid. The sweep came 3 minutes 24 seconds later, worth about $2.5 billion on the estimates of CoinDesk and Blockaid. The records cannot show how the attacker got signatures from Binance’s own wallet in the first place.
The argument over Ethereum’s design turns on that gap. Ido Ben-Natan, chief executive of the security firm Blockaid, told Cointelegraph the funds could have been stolen without EIP-7702. Ivo Georgiev, chief executive of the wallet maker Ambire, said the attackers could already authorize transactions. For the theft itself, the sums and the freezes, read our main report on the Binance hack. This piece deals with one question: how much of it belongs to the feature.
EIP-7702 and the Binance hack: the tool on one wallet, not the cause of the loss
Binance puts the total impact at about $6.3 billion and TRM Labs counts $6.36 billion, while Blockaid says over $5.5 billion. Binance 14 was the only wallet delegated, according to drk.vc, an analyst blog. So the sweep that made the headlines is about two-fifths of the total on TRM’s count, and TRM describes standard signed transfers on the other chains.
Two Ethereum figures circulate and they measure different things. CoinDesk writes of about $2.5 billion from one Binance wallet in under four minutes. TRM counts $3.79 billion on Ethereum in all, a total that also covers later sweeps and wallets that were never delegated.
What is EIP-7702? A permission that names no amount and no recipient
An Ethereum account of the ordinary kind, controlled by a private key, has no code. EIP-7702 changed that when Pectra went live on 7 May 2025. According to the proposal’s text, the owner signs a short message naming a chain, a contract address and a nonce, the account’s running transaction counter. Anyone can then put that signature into a transaction of the new type 4 and pay the gas. From that moment the account behaves like the named smart contract.
The intended uses are mundane: batching several actions into one transaction, or letting someone else cover fees. The danger sits in what the signature leaves out. It sets no recipient and no amount. Whoever controls the code of the delegate contract controls what the account does, and the delegation stays in place until the owner replaces it.
The authors flagged a narrower version of the risk. A poorly built delegate, the EIP warns, can “allow a malicious actor to take near complete control over a signer’s EOA”, EOA being the technical name for an ordinary key-controlled account. A contract written by the attacker needs no flaw at all.
Two rules matter for what follows. An authorization counts only if its nonce equals the account’s current nonce, and an accepted one raises that nonce by one, so it cannot be used twice. A mismatch does not sink the transaction: the EIP tells nodes to skip that authorization and move to the next one in the list. The owner can also cancel at any time by delegating to the zero address, which clears the code.
One transaction, 50 signatures, one hit
Those rules explain the odd shape of the attack. The transaction of 29 October was sent by an attacker address, 0x7C86…5CA0, which Etherscan labels “Binance Hot Wallet Exploiter”, in block 26300753. All 50 authorizations named Binance 14 as the signer and the same contract as the delegate. Their nonces ran from 18,914,775 to 18,914,824. The network skipped 49 of them, and the transaction still succeeded. The one that matched was 18,914,809, which sits 34 above the lowest guess. The Etherscan page quotes Blockaid: “Only 1 of 50 was a hit.”
Why 50? A wallet’s nonce rises with every transaction it sends, and this one was processing customer withdrawals, so a signature prepared in advance has to guess where the counter will be when it lands. Journal du Coin reports that the attacker did not know the live nonce. TRM Labs reads more into it: the batch “suggests the access may have been limited in time”, or that signatures had to be requested “through a system”. That is an assessment. The fact underneath it is simpler: 50 signatures for Binance 14 existed before 20:20:59 UTC.
The contract was ready well before that. Blockaid, in a report summarised by TechFlow, and CoinDesk both place its deployment around 16:00 UTC, more than four hours earlier. Its source code is unpublished on Etherscan. Drk.vc says the code requires the caller to be the attacker’s own address, and CoinDesk also describes a contract only that wallet could operate.
From delegation to revocation: 3 hours 50 minutes of open access
The first sweep shows what the delegation bought. The attacker called a function named sweep on Binance 14 itself, value zero, and paid 0.000413776 ETH in fees, less than a dollar. Out came 167,464.2479 ETH and 63 tokens, about 1.615 billion USDT among them. No new signature from Binance was needed.
Because the delegation stayed in place, deposits reaching Binance 14 after the first sweep were taken too. The wallet was also an operator on a smart custodial wallet that CoinDesk and Blockaid call Hot Wallet 34, so calls through it moved USDC as well.
| Time (UTC) | Event | Source |
|---|---|---|
| 29 Oct, about 16:00 | Sweeper contract deployed | Blockaid via TechFlow, CoinDesk |
| 29 Oct, 20:20:59 | Delegation: 50 authorizations, one valid | Etherscan |
| 29 Oct, 20:24:23 | First sweep of Binance 14, 3 min 24 s later | Etherscan, TRM |
| 29 Oct, 20:41:23 | 780 million USDC moved through Hot Wallet 34; 43 million more later | Blockaid via TechFlow |
| 29 Oct, 20:41 to 23:56 | Follow-on sweeps at 20:41, 20:59, 21:04, 21:44, 22:39 and 23:56 | TRM |
| 30 Oct, 00:10:35 | Binance 14 revokes the delegation to the zero address | Etherscan |
The revocation is a type 4 transaction that Binance 14 sent to itself, with a valid authorization pointing to the zero address. Since the wallet is the sender, the signature came from its own key. That suggests Binance had its signing back under control by 00:10 UTC, about 3 hours 50 minutes after the delegation, though Binance has not said so in the sources we read.
The rest of the loss needed no EIP-7702
The best evidence for the sceptics comes from the same evening. Twenty-four seconds after the first sweep, Binance 16, which was never delegated, signed a transfer of 28,005.6 ETH and about $108 million in tokens, according to drk.vc. On Bitcoin, Tron, the XRP Ledger and Solana the funds left in ordinary signed transfers, CoinDesk and drk.vc report.
So the attacker could get signatures on Ethereum with or without EIP-7702, and on chains without the feature, such as Bitcoin. Why it was used on one wallet only remains unexplained.
Stolen key or hijacked signing system: the accounts conflict
Here the chain stops helping. Each explanation below fits the transactions, and none has been proven in public.
| Who | What they say | Status |
|---|---|---|
| Binance | The first investigation “may involve a compromised DevOps engineer’s laptop”; “no evidence of any wallet private key leak”; further breach points since found, not named | Company account, not independently verified |
| Blockaid | Its post, embedded by crypto.news: “an attacker used a stolen key to drain $5.5B”; its report says the key leak and the 7702 mechanism were confirmed within 11 minutes, per TechFlow | Vendor claim, no public proof |
| TRM Labs | The most likely explanation is that the attacker could make “Binance’s hot wallet signing system sign transactions of its choosing across chains” | Assessment, labelled as such |
| drk.vc | Someone holding the raw key could have sent transfers directly, so it infers access to the signing path; it cites SlowMist saying a key leak “may be involved” | Analyst inference |
TRM’s reasoning is the most detailed one on offer. It points to valid signatures on different chains, key types and signing schemes within about half an hour, which a phishing attack on one Ethereum signer would not explain. Co-chief executive Richard Teng added on X, as quoted by CoinDesk: “The attacker did not simply use one engineer’s permissions, and this was not a single ‘one-click’ action.”
Read side by side, Binance’s “no evidence” and Blockaid’s “stolen key” do not fit together, although crypto.news, which carries both, does not try to reconcile them. Ben-Natan himself, according to Journal du Coin, speaks of misuse of the key and not of theft. Readers have seen this kind of dispute before: earlier this week the Bloom trading bot case also set “no keys leaked” against wallets that each signed their own drain. For why the distinction matters, our guide to private and public keys covers the basics.
What Ben-Natan, Georgiev and VEER say about EIP-7702
Three named voices carry the debate so far, all in Cointelegraph’s report of 30 October by Helen Partz.
Ben-Natan says the money could have been stolen without the feature. “The 7702 upgrade is a way to do this in one sweep and maybe a way to bypass some sort of checks they may have,” he told the outlet. Without it, he says, the attackers would have needed several transactions. He thinks a compromised developer computer may have reached the signing infrastructure and that the signer “signed a transaction that they shouldn’t have”. He warned that other exchanges face the same kind of attack on their signing systems, and said simulating transactions could catch malicious requests before approval.
Georgiev’s view is that the feature made little difference, since the attackers could already authorize transactions and could have drained the funds by other means. “This is a problem with EIP 7702, it’s just very very poorly understood,” he said. His practical worry: exchange engineers who regain control of a wallet might forget to revoke a malicious delegation.
VEER, whom Cointelegraph identifies only as a member of the Ethereum community, pointed to warnings raised during the 2024 discussions of the proposal. VEER also said the attack looked broader than one malicious signature, but that the feature gave the attackers “a handy sweep button on Ethereum”.
Cointelegraph summed this up as EIP-7702 not causing the hack but possibly amplifying it, and that wording is the outlet’s. What follows is Coindaro’s own reading, not a finding and not an accusation. Ben-Natan’s clause about bypassing checks raises a question: if a post-mortem were to show that Binance’s policies would have stopped ordinary withdrawals but let a type 4 authorization through, the feature would move from convenience to something closer to a cause. Nothing published shows that those policies worked that way, and we are not saying they did.
EIP-7702 abuse before Binance: sweepers and small losses
The pattern is older than this hack, at a very different size. On 30 May 2025, three weeks after Pectra, Wintermute posted on X that “over 97% of all EIP-7702 delegations were authorized to multiple contracts using the same exact code”, contracts it described as sweepers. That wording appears in CoinDesk’s report and other coverage. Two figures circulate: CoinDesk’s own text and a Bitget News summary say more than 80% of delegations used copied contracts, and the 97% is the one in Wintermute’s post. We could not open the post itself. The firm wrote: “The CrimeEnjoyor contract is short, simple, and widely reused.”
Taylor Monahan, a security researcher, said at the time that the core problem was weak private-key protection, and SlowMist, founded by Yu Xian, advised wallets to show the destination contract clearly when a user signs a delegation. Scam Sniffer reported in May 2025 that one wallet lost about $146,551 in a batch of malicious transactions, which SlowMist tied to Inferno Drainer. Cointelegraph also recalls World Liberty Financial holders reporting losses linked to malicious delegations in September 2025.
Blockaid counts four EIP-7702 incidents in the first half of 2026, for about $1.08 million in total. Binance 14’s first sweep alone is more than 2,000 times that. Bybit, the previous record at about $1.5 billion in February 2025, came before Pectra, so the feature played no part: its attackers compromised a signing interface.
What exchanges and wallets can change
Most proposals so far aim at the moment before a signature, and they come from people with a stake. Blockaid sells this kind of protection, so its advice should be read with that in mind. It wants every transaction, including 7702 authorization lists, simulated and reviewed against whitelists and limits before signing, and rejected even if approvers have agreed. It also wants monitoring that flags a hot wallet suddenly gaining code, with automated moves or revocations in response. It also says wallets should have revocation transactions prepared in advance, and it claims alerts 1 minute 55 seconds after the first sweep.
- Journal du Coin lists three guardrails: block type 4 transactions from withdrawal hot wallets, allow only approved delegate contracts, and simulate before signing.
- SlowMist’s 2025 advice applies to consumer wallets: show the delegate contract before the user signs.
- Georgiev’s warning applies after any incident: check for delegations and revoke them, as Binance 14 did at 00:10:35 UTC.
For someone holding a personal wallet, the same logic applies at a smaller scale. A delegation request is closer to handing over an account than to approving a payment, because it names neither a sum nor a recipient. To remove one, the account owner delegates to the zero address, the method the EIP defines and the one used on Binance 14.
What is still unknown about the EIP-7702 attack
Binance has promised a post-mortem and an updated proof of reserves, with no date for either. Until the post-mortem lands, these points stay open:
- How the 50 signatures were produced: a laptop, a signing service or a key.
- Whether a key leaked at all, given Binance’s “no evidence”, Blockaid’s stolen key and TRM’s signing system.
- Why Ethereum was the only chain with a delegation, and only on Binance 14.
- Whether other exchanges have delegations on their hot wallets, since we found no published scan.
- What Ethereum’s developers make of it: we found no statement from a core developer, Vitalik Buterin or the Ethereum Foundation in the sources checked by midday on 30 October.