The One-Click Wallet Upgrade: What an EIP-7702 Delegation Signature Actually Hands Over

A real upgrade and a total takeover ask for the same thing

The advice that would be easiest to give here is wrong, so it is worth disposing of first: never sign a delegation is not usable guidance, because legitimate wallets now ask you to.

The reason they ask is genuine. Ethereum's own roadmap documentation is blunt about the ordinary account type most people use, noting that if you lose your keys they cannot be recovered, that stolen keys give thieves instant access to all the funds in an account, and that seed phrase phishing is one of the most common scams while securing seed phrases is awkward even for expert users. Smart-account features are the intended answer — recovering your account if you lose the keys, sharing account security across trusted devices or individuals, and requiring multiple signatures for high-value transactions. EIP-7702, now final in the specification, is what lets an ordinary account reach those features without moving to a new address. That is why your wallet's upgrade prompt is probably exactly what it says it is.

The problem is structural rather than anyone's carelessness. The same signature that enables recovery and batching points your account at someone else's code, and a phishing site can request it in the same shape — Relay describes the packaging plainly: scammers trick users into signing malicious delegations, often on fake sites disguised as free mints or giveaways.

So the question is never whether to sign a delegation. It is which contract you are delegating to, and whether the thing asking has any business asking.

What you are actually signing

Precision matters here, because the mechanism is genuinely different from every other prompt you have been trained to read.

A token approval grants a contract permission to move one token, up to some limit. A permit signature authorises a specific transfer off-chain. An EIP-7702 authorisation does neither. The specification describes a tuple of chain id, address, nonce and signature components, and the effect of submitting it is that the delegation indicator 0xef0100 followed by that address is written to the authorising account's code. Your ordinary address stops being codeless, and from that point code execution against your account follows the pointer.

Read what that means without softening it. The contract at the other end is not permitted to do a thing; it becomes the behaviour of your account. There is no per-token limit to exceed, no amount to cap and no expiry to wait out. The specification's own Security Considerations section states the consequence directly: a poorly implemented delegate can allow a malicious actor to take near complete control over a signer's EOA. That is written about a merely sloppy delegate; a deliberately hostile one is the same mechanism pointed on purpose.

Relay describes what the hostile version does in practice, and the detail worth sitting with is that it does not require the attacker to keep working. The malicious contract can auto-drain tokens as soon as they arrive and instantly forward out any new balance, so the drain happens without the attacker submitting a transaction at all. This is also why the delegation outlives the balance — an emptied address with a hostile delegate is not a spent problem but a permanent one, which is the mechanism behind money vanishing the moment a compromised wallet is refilled.

The one piece of good news is that the pointer is clearable. If the address in a later authorisation is the zero address, the spec instructs that the delegation indicator is not written and the account's code is cleared by resetting its code hash to the empty code hash. Whether that helps you depends on the sections that follow.

How the signature gets triggered, and why chain id zero should stop you

The academic treatment separates what a user controls from what they do not. The analysis by Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu and Shiping Chen states the core claim without hedging: instead of deceiving users into signing individual transactions, an attacker can induce a victim to sign a single authorisation tuple that grants unconditional and persistent execution control over the account.

Through controlled experiments they identify three reliable trigger pathways — user-driven, attacker-driven and protocol-triggered — and note that each can lead to full account takeover and complete asset drainage. The reason to know the list is that only the first involves you doing something. The paper also describes an extended surface in which ERC-4337's EntryPoint pipeline enables remote and repeated activation of the delegated code without further victim involvement. The window of regret people imagine they have, between signing and consequence, is not reliably there.

Then the detail most user-facing writing omits. The tuple's first field is a chain id, and its purpose is to confine the authorisation to one network. The specification documents the escape hatch: when universal deployment is preferred, simply set chain ID to 0. That is a legitimate convenience for deploying the same smart account everywhere. It also means one signature can be valid on every EVM network at once, which the paper characterises as a chain-agnostic authorisation mode permitting replay-like compromises across independent networks.

So a chain id of zero is not a neutral footnote — it is the difference between granting control of one account on one chain and granting it everywhere your key exists. If your wallet shows that field, read it. If a request asks for universal scope and cannot explain why, that is the answer.

The 97 percent figure does not mean what the headlines said

If you searched this topic in the last year you met a startling number, reported in a way that made the wrong thing frightening.

Wintermute's research team found that over 97 percent of all EIP-7702 delegations were authorised to multiple contracts using the same exact code. They nicknamed the reused bytecode CrimeEnjoyor and described its function precisely: these are sweepers, used to automatically drain incoming ETH from compromised addresses. The operators spent approximately 2.88 ETH to authorise around 79,000 addresses, one address accounting for over half.

Read the word compromised, because it carries the whole distinction. A sweeper delegation is set by someone who already has the key. It is not how the wallet was lost; it is automation applied afterwards to catch anything arriving later — which is why mass-authorising 79,000 addresses for under three ETH is cheap, and why CoinDesk noted the attackers were making very little from it.

Wintermute itself then pushed back on the resulting headlines, saying some had misrepresented the core message and stating the position plainly: EIP-7702 is not flawed, and it is safe to use in retail wallets. Keep that qualifier, because it carries the reasoning — a trusted wallet delegates to its own audited contracts, so its users are not the ones authorising CrimeEnjoyor. The 97 percent measures already-compromised wallets, not the odds that signing a prompt in a real wallet will ruin you.

The risk that is genuinely about your judgement is the quieter one: being persuaded to sign the tuple yourself, with your key never leaving your possession. Scam Sniffer's 2025 review describes that category as emerging shortly after the Pectra upgrade, with attackers leveraging account abstraction to bundle multiple malicious operations into single signatures, and attributes 2.54 million dollars of losses to two major EIP-7702 batch-signature incidents in one month. Keep it in proportion: the same review puts total phishing losses for the year at 83.85 million dollars across 106,106 victims, down 83 percent, with the largest single theft coming from a permit signature rather than a delegation. A real and growing vector, not the end of wallet safety.

Two reputable sources disagree here, and the disagreement is instructive

Read around this subject and you will hit a genuine conflict between careful sources, worth surfacing rather than smoothing over. Revoke.cash argues the draining fear is overblown, in strong terms: while it is true that EIP-7702 can be used to facilitate this, it is only possible if your seed phrase is compromised — and if your seed phrase is compromised, then your entire wallet is already lost, so EIP-7702 is not the cause of the loss in the first place. Relay points the other way, describing users tricked into signing malicious delegations on fake sites.

Both are true of different populations. Revoke.cash's claim holds for the sweeper case, the bulk of delegations by count, where the key theft came first and the delegation is only automation bolted on afterwards. It does not hold as a general statement, because the research documents the other route: signing the tuple yourself, with the key never leaving your possession — what Scam Sniffer's batch-signature incidents describe. So most malicious delegations follow a compromise rather than cause one, and a minority are the compromise.

They also disagree on revocation, where the honest answer is that it varies: Revoke.cash says you revoke inside your wallet application, Relay says most trusted wallets do not allow it through their interface. Check your own wallet's settings rather than assuming either.

Before you sign, and the question that decides what to do after

One tempting shortcut has to be discarded first: a delegation prompt appearing while you use a dapp is not itself suspicious. Revoke.cash is explicit that wallets will prompt you automatically to enable EIP-7702 when you use a dapp that supports batch transactions, giving its own batch-revoke feature as the example. Treating every dapp-triggered prompt as an attack would teach you to distrust the ordinary path.

What distinguishes the two is narrower. Did you initiate the action the prompt belongs to — a batch you asked for, an upgrade you opened — or did the request simply appear? Is the delegate address a vendor's published, widely-used implementation you can look up, rather than a contract with no history? And what is the chain id: one network, or all of them?

Then the check that costs nothing: a free mint, a giveaway or an eligibility check has no reason to alter what your account is. Batching a transaction you requested is a function; changing your wallet's nature to collect a reward is the bait.

Now the part that matters most, because it is where good instincts lead people wrong. If you discover a delegation you do not recognise, the intuitive move is to revoke it. But Relay names the trap directly: attempting to revoke may create a false sense of security, and unknown delegations usually mean your keys or seed phrase have already been compromised — so the recommendation is to stop using that wallet and move to a new one.

The question that decides your response is simply: do you remember signing it? If you knowingly signed one and later want it gone, clearing it is legitimate housekeeping, and you can check your address on a block explorer's delegations view or in your wallet's smart-account settings. If you do not remember signing it, revocation treats the symptom — something set that pointer using your key, and an address whose key is in someone else's hands is not repaired by tidying its code. Move to a wallet created on a device you trust, transfer the most valuable assets first and the gas token last, and remember that token approvals granted from the old address persist independently of all of this.

Authority sources used

Outbound links are included for verification and entity authority, not decoration.

• EIP-7702: Set Code for EOAsEthereum Improvement Proposals
• EIP-7702 Phishing Attack (Qi, Wang, Li, Zhu, Chen)arXiv preprint 2512.12174
• Post-Pectra, Malicious Ethereum Contracts Are Trying to Drain Wallets, Wintermute SaysCoinDesk
• Clarification on reporting around our EIP-7702 findingsWintermute Research
• Malicious EIP-7702 Delegations and How to Stay SafeRelay Support Center
• What Is EIP7702?Revoke.cash
• Scam Sniffer 2025: Crypto Phishing Losses Fall 83% to $84 MillionScam Sniffer
• Account abstractionEthereum.org

FAQ