Fifty keys for a single lock. To understand the Binance hack, you have to go through a line of Ethereum code. However, most users have never noticed it. Arriving with the Pectra update in May 2025, EIP-7702 allows a classic wallet to behave like a smart contract. The hacker used it to transform the “Binance 14” hot wallet into a vacuum cleaner. However, out of the 50 authorizations he had prepared, only one was successful.
Here is the technical anatomy of the attack, with the two opposing explanations for the origin of the signature.
The key points of this article:
EIP-7702 authorizes an ordinary account to delegate its execution to a contract, upon simple signature of its owner.
The attacker did not know the exact wallet counter. He therefore signed fifty consecutive authorizations, and one of them hit the mark.
This signature requires the private key of the account. The flaw is therefore located in the Binance signature chain.
Binance talks about a compromised engineer's computer, TRM Labs about a breached signing infrastructure.
EIP-7702: what Pectra has changed for wallets
Until May 7, 2025, Ethereum lived with two very separate types of accounts. On the one hand, the external accounts, the EOAs, controlled by a private key, those of your MetaMask or your Ledger. On the other hand, contract accounts, driven by code. An EOA could do nothing other than send transactions one by one. EIP-7702, pushed by Vitalik Buterin, has blurred this boundary. Concretely, the owner of an EOA signs an authorization. It basically says “until further notice, execute the code of this contract for me”. The account keeps its address and its balance, but begins to obey the logic of a contract.
The uses are concrete: group several operations into one transaction, or let a third party pay gas costs. Consumer wallets adopted the EIP-7702 delegation in the summer of 2025. But everyone knew the downside from the start. Indeed, if someone obtains authorization to a malicious contract, the entire account becomes theirs. And he doesn’t even need to “steal” the private key in the classic sense.
Three safeguards govern this authorization. First, the private key of the account signs it. Then it mentions the channel ID. Finally, it carries the account nonce, this counter which increases with each transaction sent. However, an authorization is only valid if its nonce corresponds exactly to the account counter. This check takes place when a block includes it. It is this detail that explains the number 50.
Hack Binance: the mechanics of 50 authorizations
Blockaid, the security company that detected the operation, has reconstructed the sequence. The attacker had the means to sign authorizations in the name of Binance 14. However, he did not know the current nonce of this wallet, which chained customer withdrawals. He therefore signed fifty authorizations, from nonce 18 914 775 to 18 914 824. Then he sent them in a single type 4 transaction, the format created by Pectra. The other forty-nine did not correspond to any valid counter. One fell right on the current counter. Blockaid summarizes on X: “only one out of 50 hit the mark”.
From there, Binance 14 executes the attacker’s contract code. According to Blockaid, the first transfer leaves 3 minutes and 24 seconds after delegation. He carries 167,464 ETH, 1.6 billion USDT and around sixty other tokens. The same ownership role was then used to extract $780 million worth of USDC from another smart wallet. Nothing in this chain exploited a bug in EIP-7702. The protocol did exactly what was asked of it, with a valid signature.
These fifty signatures ask a simple question. Indeed, to produce them, you need the private key of Binance 14 or access to the system that uses it. For Ido Ben-Natan, the boss of Blockaid, it is a “misuse of the key”, not a theft.
Laptop DevOps or signature infrastructure: the two versions of the Binance hack
Binance gave its reading in its progress update published overnight. According to the exchange, the hacker hacked the laptop of a DevOps engineer. This access allegedly allowed him to “access a service container and submit unauthorized withdrawal transactions.” Binance, however, says it has found “no evidence of a private key leak”. Translation: the hacker communicated with the service authorized to request signatures. This service then signed what was presented to it, without the key itself coming out. Including fifty 7702 authorizations that a customer withdrawal has no reason to contain.
TRM Labs formulates the same idea differently and concludes that there is “a compromise of the signature infrastructure of hot wallets”. The two versions agree on the essentials. The weak link is in an internal component that has signing rights, not in the Ethereum protocol. What should have blocked? Several safeguards exist. A rule can refuse any type 4 transaction issued by a hot withdrawal wallet. A whitelist can limit delegation contracts. Finally, a simulation can test each transaction before signing, precisely the product that Blockaid sells. Binance promises a detailed post-mortem once the investigation is complete. Until then, exchanges whose signatories accept EIP-7702 authorizations without filters should review their configuration before Monday.
