- EIP-7702, live on Ethereum since the Pectra upgrade of May 2025, lets a wallet with a private key sign an authorization that sets its address's code to 0xef0100 plus a contract address, so the address runs that contract's code when called.
- An authorization names no amount, recipient or expiry, and the delegate code acts as the address for anyone it accepts until a new authorization replaces or clears it, which is how 823 million USDC left a smart account owned by Binance's hot wallet on 29 October 2026.
- Revoking token approvals does not remove a delegation; check an address's code for the 0xef0100 prefix on each chain you use, clear an unwanted one with a zero-address authorization, and move funds to a fresh wallet if you never signed it.
One signature behind the 29 October Binance hack moved nothing. It was an EIP-7702 authorization in the name of the hot wallet Etherscan labels Binance 14, and when it landed at 20:20:59 UTC the wallet's balance didn't change. What changed was the address. From that block on, it ran an attacker's contract, and a little over three minutes later tokens started leaving.
EIP-7702, live on Ethereum since the Pectra upgrade of May 2025, is the rule that made that possible. It lets an ordinary wallet sign an authorization that points its address at a smart contract's code. The address keeps its key, its balance and its history, and it also gains whatever the contract does, for anyone the contract lets in, until another authorization replaces or clears it.
Nina met the same rule that week as a button. The phone wallet she set up for her first coins had started offering to turn her account into a smart account, with transactions bundled and fees paid for her. It didn't say what one tap would sign. So she took it to Lilith, who after several breaches stopped asking who stole a key, and asks instead what an attacker could do once inside. Together they take the Binance wallet apart block by block, from what its signature granted to why the attacker needed fifty. After that, they check Nina's address.
Lilith asks a public Ethereum node for the hot wallet's code. Two characters come back, `0x`: no code, an ordinary account again. "On the night of the 29th it ran somebody else's program for nearly four hours," she says.
What is EIP-7702?
"What is it for, though?" Nina asks. On her screen the upgrade looks like a settings change.
"It is one, of a sort," Lilith says. Until May 2025 an Ethereum address came in two kinds. An account with a key could sign transactions but ran no code, while a contract ran code but had no key to sign with. EIP-7702 lets the first kind borrow the second kind's behavior. The key's owner signs an authorization naming a contract, and from then on the address runs that contract's code whenever something calls it.
Everything the upgrade advertises comes out of that borrowing. A delegated address can bundle an approval and a swap. It can let a sponsor pay its fees, or give an app a limited key that may spend a set amount and no more. The original key keeps working, and the address never changes. Nina's wallet would point her address at its developers' own contract. "What would I be agreeing to?" she asks.
"To let their code act as you, for whoever it accepts, until you sign something else," Lilith says.
Three fields and a signature
Behind the button, Nina expected a page of terms, so Lilith shows her the format instead, straight from the EIP. An authorization holds three values and a signature. The values are a chain ID, a contract address and a nonce, the counter Ethereum keeps for each account so that no transaction can run twice. There is no amount, no token, no recipient and no expiry.
When a transaction delivers one, the chain checks it in order. The chain ID must be zero or match the chain. The signer is recovered from the signature, and that account's nonce must equal the one it signed. If everything holds, the account's code becomes `0xef0100` followed by the contract's address, a marker the specification calls a delegation indicator, and the account's nonce rises by one.
From then on, calling the address runs the contract's code. The specification's security notes warn that such code "can be called by anyone at any point in a transaction". A badly written one, they add, can "allow a malicious actor to take near complete control over a signer's EOA". EOA is the EIP's word for an account with a key. Whether "anyone" achieves anything depends on the contract. A wallet's contract demands instructions signed by its owner, while an attacker's contract takes them from the attacker.
"So it isn't a payment. It's who my address listens to," Nina says.
"And it keeps listening," Lilith says. The EIP's summary says the code is set "permanently". Permanent means until the owner signs another authorization, pointing somewhere new or naming the zero address, which the specification treats as an order to wipe the code.
An authorization carries no terms of its own, so the contract's author writes all of them, and one signature accepts the lot.
How the Binance hack used EIP-7702
On 29 October the author of those terms was the attacker. Lilith follows the attacker's wallet through a block explorer: just before four that afternoon, UTC, it deployed a contract. Blockscout lists its code as verified under the name "Target". Its source opens by warning that it is AI-reconstructed, not original. Taken with that caveat, it is a sweeper, built to move tokens and ether out of whatever address runs it, and only one hard-coded caller may drive it: the wallet that deployed it.
Binance dates the breach to shortly after eight that evening. About sixteen minutes later, the attacker's wallet sent Binance 14 a transaction with no payment and no instructions in it, only a list of fifty authorizations. All fifty named the sweeper and were valid on Ethereum alone, and each carried the hot wallet's own signature. One of them matched. At 20:24:23 the attacker called the hot wallet. One transaction sent out 63 token transfers, 1.62 billion USDT among them.
"One call did that?" Nina asks.
"The first of four," Lilith says. By twenty to eleven that night, those four calls had pulled 184 different tokens out of the wallet, about 1.82 billion USDT among them. The figures cover one wallet on one chain. Binance's first notice puts the whole incident at "around $6.3B".
Why would anyone sign fifty authorizations?
"Why fifty, if one signature hands over a wallet?" Nina asks.
An authorization applies only if the nonce inside it equals the account's nonce when the transaction is processed. In the minutes before the attack, the hot wallet was sending about ten transactions a minute, and each one moved its nonce up by one.
"So a single signature goes stale in seconds. You'd sign a run and let the wallet land on one," Nina says.
The fifty did exactly that, covering nonces 18,914,775 to 18,914,824, roughly five minutes of the wallet's traffic at that pace (computed). Earlier in that block, the wallet had sent a transaction. That left its next nonce at 18,914,809. Fifteen of the fifty were for numbers it hadn't reached, thirty-four for numbers it had already used, and one fit.
"They're also listed backwards," Lilith says. With the highest nonce first, nothing below the match could apply once the counter had moved. Listed upward, each match would have pushed the counter onto the next signature, and any transaction the wallet had already signed for those numbers would have failed.
Instead, its next transaction left twelve seconds later as if nothing had happened. Its sequence shows one gap, the nonce the authorization used.
Every check in the protocol passed, and none of them asks whether the signer meant it.
If no key leaked, who signed?
Binance's first notice reports "no evidence of any wallet private key leak". "Each of the fifty still carries the hot wallet's signature," Nina says.
"Both can be true," Lilith says. The specification recovers the signer from the signature itself, so no other key can authorize anything for that address. Something with access to its key produced fifty signatures. Binance's notice says the incident "may involve a compromised DevOps engineer's laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions". Its second update, a day after the hack, said the investigation had "uncovered additional points of breach" and still found "no evidence that wallet private keys were leaked".
"A hot wallet's key doesn't sit in a drawer," Lilith says. Other machines ask a signing service for signatures all day long, and an attacker inside one of them can leave the key where it is. Decrypt reports that Binance's wallets on nine other chains "sent funds to the attacker through ordinary signed transfers". In TRM Labs' view, that "points to a compromise of Binance's hot wallet signing infrastructure rather than a flaw in Ethereum itself". No flaw in EIP-7702 has been reported.
Keeping a hot wallet's key from leaking was never the whole job. The rest is everything allowed to ask that key for a signature, and on 29 October something asked it for fifty.
Exactly what asked is for Binance to explain, and it has promised "a detailed technical post-mortem". As of 9 November its feed holds nine updates and no post-mortem. Binance says its SAFU fund and treasury will carry the losses, not its users. For a customer, that turns the hack into a question of what an exchange's protection fund covers after a hack.
Everything that trusts the address
"At least the damage stops at whatever was sitting in that wallet," Nina says.
"At whatever trusts it," Lilith says. Two of the attacker's calls left the wallet's balance alone. They went through a smart account the hot wallet has owned since July 2025, built on Circle's single-owner account code, which pays out when its owner tells it to. The owner was using it that night. Twelve seconds after the delegation landed, one of the hot wallet's own transactions ordered the account to send USDC out. Twenty-six such orders went out before the delegation was cleared.
When the sweeper, running as the same address, gave two orders of its own, the account saw its owner and obeyed. The first took 780 million USDC and the second 43 million. Both landed at the address the sweeps were already filling.
A delegation reaches as far as the address does: any contract that names it owner, any role it holds, any allowance granted to it. The sweeper didn't need any of those permissions handed over. To each contract it called, it was Binance 14.
The owner never stopped signing either. After the delegation, the hot wallet sent ninety-three transactions of its own. At 00:10:35 UTC on 30 October it sent one more, addressed to itself and carrying a single authorization that named the zero address, and the code was gone. Binance's first notice, published about two hours later, says it "revoked the affected address authorisation".
"They could have cleared it within a minute," Nina says.
"Once they'd noticed. The delegation never locked them out. It gave the address a second controller, and the first one had to catch it," Lilith says.
There is a warning in that for Nina too. The key in her phone can always clear a delegation, but only while nobody else can sign with it.
Is an EIP-7702 delegation the same as a token approval?
Nina thought she had approvals covered, because she ran an approval checker last month and revoked everything it found. "Wouldn't that have caught a delegation?" she asks.
"It looks somewhere else," Lilith says. A token approval lives inside one token's contract, as a number: how much of that token one named spender may still move. Revoking it sets the number to zero, token by token. A delegation isn't stored in any token. It's code on the address itself, so a tool combing token contracts for allowances never meets it.
| Token approval | EIP-7702 delegation | |
|---|---|---|
| Where it lives | Inside one token's contract | On your address, as its code |
| What it covers | One token, one spender, up to the amount approved | Everything the address can do, including contracts that trust it |
| Who can use it | The spender you approved | Anyone the delegate contract accepts |
| How long it lasts | Until spent or set back to zero | Until another authorization replaces or clears it |
| How you end it | Revoke it, token by token | Sign an authorization naming the zero address, on each chain |
| What an approval sweep does to it | Clears it | Nothing |
Nina's checker had answered a question about her tokens, while a delegation asks one about the address that holds them.
Does your wallet have an EIP-7702 delegation?
Nina's address gets the same request, and two characters come back again, `0x`: nothing delegated. A block explorer shows that too, with nothing to type but the address. A delegated address returns code that starts with `0xef0100`, and the forty characters after that prefix spell out the delegate contract's address. Compare it with whatever the wallet says it installed.
Clearing a delegation works the way the hot wallet did it, with an authorization naming the zero address, signed by the wallet's own key. Where a delegation counts depends on the chain ID. Binance's fifty carried Ethereum's ID, so none of them could apply anywhere else. One signed with chain ID zero passes the chain check on every network that has adopted EIP-7702, and applies on any of them where the nonce matches. Check each chain where the wallet holds anything.
"And if I find one I don't remember signing?" Nina asks.
"Clearing it won't be enough," Lilith says. Whoever got one signature can get another, and a cleared address accepts it as readily as the first. The fix is a fresh wallet, with everything moved into it.
The specification expects a delegation request to come from the wallet's own upgrade screen. A request arriving through a website, an airdrop claim or a "verify your wallet" page is something else. A compromised front end can serve one through a site you have used for years. Decrypt cites a Wintermute finding that, in the weeks after Pectra went live, more than 80% of EIP-7702 delegations pointed to copies of the same malicious sweeper contract.
The EIP's authors saw that request coming. Applications "must not expect that they can suggest the user sign an authorization", which leaves the duty with the wallet. In the authors' words, there is "no safe way to provide this interface". Of all the apps on Nina's phone, the wallet alone was ever meant to ask for this signature.
Nina hasn't answered the upgrade prompt yet. It was not asking how she wanted to pay, but who else her address should obey.
Place a Stop Loss under a coin you own and a Limit buy below the market, and stay away for a day. Trade History will show what both did without another click from you, because a resting order, like a delegation, keeps acting after you stop watching. Whatever is still pending, cancel unless you'd place it again today: with no wallet to delegate, that button is as close as a paper account comes to signing the zero address.
