EIP-7702 Delegation Phishing Scam: Why “Just Revoke It” Was My Wrong Reflex

The first time I read about an EIP-7702 delegation phishing scam, my reaction was smug. “Fine,” I thought. “If something ever attaches to my wallet, I’ll just revoke it, like I revoke a token approval.” That reflex felt like wallet hygiene. It was actually the mistake at the center of this post.

I’m going to walk you through why “just revoke it” is the wrong first move for a 7702 delegation, how to check your own address tonight, and the one rule that actually prevents a repeat. I’m a Korean office worker, not a Solidity developer, so I’ll keep the mechanism in plain English. No price talk. No token picks. Just the mechanism and what to do with it.

The short version, because I wish someone had told me on day one: an approval phish rents out one door. A delegation phish hands over the whole house — and once you’ve handed over the deed, changing the locks isn’t the fix.

The reflex that fails: treating a delegation like an approval

Here is the assumption I got wrong, stated plainly so you can catch yourself making it.

For years, the standard wallet-safety advice has been “audit your approvals.” You sign an approval that lets a contract move specific tokens, a scammer abuses it, and you go to a tool, hit revoke, and the door closes. I wrote a whole post on that exact fix. If that’s the model in your head, an approval phish only rents out specific tokens, and revoking cancels the lease — that revoke-the-approval fix is real, and I still stand by it.

The trap is assuming a 7702 delegation is the same shape of problem. It isn’t. With a token approval — the shape behind an approval-style signature phish — you granted permission to move an asset. With an EIP-7702 delegation, you didn’t approve a token at all. You pointed your account’s own behavior at someone else’s code.

To see why that breaks the reflex, you need two plain-English words: EOA and delegation.

An EOA — externally owned account — is just a normal wallet. It’s the address you control with a private key or seed phrase. MetaMask, your Ledger’s Ethereum account, the thing you paste when someone sends you ETH. Historically, an EOA had no code of its own. It could hold funds and sign transactions, nothing more.

A delegation points that plain wallet at a smart contract’s code, temporarily, so the wallet can behave like a smart account. EIP-7702 shipped with the Pectra upgrade on May 7, 2025, and it’s genuinely useful — it’s how a normal wallet can batch actions or let someone else pay gas. The official Pectra guidelines frame it as an on-ramp to smart-account features without abandoning your existing address.

But read that sentence again. Delegation makes your wallet run someone else’s code. If that someone is an attacker, the attacker’s code now acts as your account. That’s not a rented door. That’s the deed.

Why the whole house gets swept, not one room

Once I understood what delegation actually does, the “just revoke it” instinct fell apart on its own.

When your wallet is delegated to a malicious contract, funds don’t sit safely until the attacker comes for them. The malicious code is your account now. So the attacker deploys what’s called a sweeper — code that watches your address and moves anything that lands in it the instant it arrives. You get a small ETH refund? Swept. A friend sends you gas money? Swept before you notice.

This isn’t hypothetical or rare. Wintermute analyzed in-the-wild 7702 delegations and found that 97%+ of them pointed to identical sweeper code — copy-pasted at industrial scale and tagged “CrimeEnjoyor.” The number that stuck with me: 97%+ isn’t a spread of clever custom attacks. It’s one drain, mass-produced, wearing the same face over and over.

That mass-production is the whole story. Drainer crews like Inferno Drainer and PinkDrainer turned wallet theft into a service years ago, and 7702 gave them a cleaner tool. If you want the fuller picture of how drainer crews industrialize a sweeper into a repeatable pipeline, I mapped that separately. The point here: reported losses already include a $1.54 million single-phish incident dressed up as a Uniswap swap, and a separate ~$146K case. The mechanism works.

So how do you actually get delegated? You sign it. Almost always through a fake popup.

The flow looks boring, which is the danger. You land on a site that mimics a real dApp — a swap, an airdrop claim, a “verify wallet” prompt. It asks you to sign what looks like a routine transaction. What you’re really signing is a type 0x04 “set code” transaction — the authorization that points your account at their contract. You approve it. The sweeper is live. Nothing on your screen said “you are handing over your account,” because the popup was designed so it wouldn’t.

The one table that reframed it for me

I kept confusing these two attacks until I forced them into a grid. Here’s the version I’d tape to my monitor.

	Approval / permit2 phish	EIP-7702 delegation phish
What you signed	Permission to move specific tokens	Authorization pointing your account at attacker code
What the attacker gets	A key to one door (that token, that spender)	The whole house — your account runs their code
How the drain happens	Attacker calls transferFrom on the approved token	A sweeper auto-drains anything that arrives
Does revoking fix it?	Usually yes — cancel the approval, door closes	Not reliably — if you signed with your real key, assume the key is burned
Right response	Revoke the approval	Migrate to a fresh wallet, then stop signing blind

The row that changed my behavior is the fourth one. With an approval, revoking is the fix. With a delegation you didn’t recognize, revoking treats a symptom while the disease — a compromised key — stays. That gap is exactly what I want to sit with in the next section, because it’s where my original plan would have failed.

Check your own address tonight (a non-coder walkthrough)

You don’t need to code to answer one question: is my wallet delegated? Here’s how I check mine, no terminal required.

1. Look for the 0xef0100 fingerprint. A delegated account isn’t invisible. It gets a 23-byte piece of code that starts with 0xef0100, followed by the address it’s delegated to. That prefix is the on-chain fingerprint. The EIP-7702 specification defines this delegation designator — if you see 0xef0100... in your account’s code field, your wallet is currently delegated.

2. Open a block explorer. Paste your address into Etherscan. A normal EOA shows no contract code. A delegated one exposes an “Authorizations (EIP-7702)” view or a code field with that 0xef0100 marker plus the target contract. If it’s there, note the target address — you’ll need to know whether you put it there.

3. Use a checker tool if the explorer feels dense. Tools like revoke.cash and eip7702.app read the same on-chain data and present it in plainer language. The revoke.cash team wrote a solid plain-English explainer on what an EIP-7702 delegation is and how to spot one, which doubles as a checker. I ran my own address through it the night I understood the risk. It was clean. My relief was real, and slightly embarrassing, given how confident I’d been.

4. Decide: known or unknown. This is the fork that matters. If the delegation is one you set up on purpose — a smart-account feature from a wallet you trust — fine. If you don’t recognize it, do not exhale yet. An unknown delegation is not a to-do item. It’s a warning light.

Here’s a 40-second self-check you can run right now:

• Paste your address into a block explorer.
• Look at the code field. Empty? You’re not delegated.
• See 0xef0100...? You’re delegated. Read the target address.
• Do you recognize that target? If not, treat the key as compromised.
• Move fast, but read the next section before you “just revoke.”

Where I was wrong: revoke isn’t enough — migrate

This is the part I’d get tattooed if I could. It’s also the exact spot where my original plan — “I’ll just revoke it” — would have left me exposed.

Yes, a delegation can technically be cleared. Revoking means signing a new 0x04 transaction that sets your account’s code back to the zero address (0x000...000), which the spec supports as a special case. On paper, you’re un-delegated. Clean code field. Problem solved.

Except think about how the delegation got there. If it’s unknown, someone got you to sign a 0x04 authorization from your real key. That means your signing device produced a valid signature for an attacker’s payload. The delegation is the symptom. The disease is that your key is now signing things you didn’t intend — and security firms are blunt about this: an unknown delegation usually means the private key itself is already compromised.

So you revoke. You feel better. Then, an hour later, the same attacker signs another 0x04 transaction — because they can still get your signature, or worse, they’ve already extracted enough to keep going. You’re playing whack-a-mole with a key that no longer belongs only to you.

That’s why the real rule is migrate, not toggle. If the delegation was unknown, move your remaining assets to a fresh wallet with a brand-new seed phrase, and retire the old one. This is the same revoke-versus-migrate line I drew for approvals — when the compromise is the key and not just one permission, revoking is treating a symptom. For a delegation, that line is even sharper.

One honest caveat, because I won’t oversell the tooling: wallet support for clearing arbitrary delegations is inconsistent. Recent MetaMask desktop versions expose a per-chain toggle to disable smart-account behavior, and some wallets are catching up. But don’t assume every wallet can cleanly revoke every delegation today. That inconsistency is one more reason migration is the safer default when the delegation is one you didn’t create.

My reflex — revoke and move on — was built for a world of approvals. Delegation isn’t that world.

The hardware-wallet comfort that isn’t

I want to hit the belief I held hardest, because you might hold it too: “I use a Ledger, so this doesn’t apply to me.”

Cold storage is excellent at one job. It keeps your private key off an internet-connected computer so malware can’t lift it. If the threat is key theft, a hardware wallet is a strong wall. I’m not knocking it — I keep a hardware-wallet self-custody setup as my own baseline.

But a 7702 delegation phish doesn’t steal your key. It gets you to sign with it. And a hardware wallet will happily sign a malicious 0x04 authorization if you approve the prompt. The device confirms you pressed the button. It doesn’t judge whether the transaction is a good idea. If you tap “approve” on a screen you didn’t fully read — a small display, an unclear message, a rushed moment — the cold wallet does exactly what a hot wallet would.

Say it with me: cold storage protects the key, not the decision. The whole 7702 attack lives on the decision side. It doesn’t need your key file. It needs your approval, and your approval is something you give from behind any wallet, hardware or not.

This is why “am I on a Ledger?” is the wrong question. The right question is “did I read what I signed?”

FAQ

What is an EIP-7702 delegation phishing scam in simple terms? It’s a phish that tricks you into signing a 0x04 “set code” transaction. Instead of approving a token, you point your own wallet at an attacker’s contract. Their code then acts as your account, and a sweeper drains funds the moment they arrive.

Can EIP-7702 drain my wallet by itself? No. The feature isn’t flawed, and Wintermute made that clear. The danger is the phishing signature. Your wallet only becomes delegated if you sign a malicious authorization. Left unsigned, EIP-7702 is a normal, useful smart-account feature.

How do I know if my address is already delegated? Paste your address into a block explorer like Etherscan and look at the code field. A delegated EOA shows a 23-byte code starting with 0xef0100, followed by the target contract. Tools like revoke.cash and eip7702.app read the same data in plainer language.

How do I revoke a 7702 delegation? You sign a new 0x04 transaction that sets your account’s code back to the zero address (0x000...000), clearing the delegation. Some wallets, like recent MetaMask desktop versions, expose a per-chain toggle. But support for revoking arbitrary delegations is inconsistent across wallets.

Is my hardware wallet safe from EIP-7702? Your key stays protected from theft. But a hardware wallet does not stop you from signing a malicious authorization if you approve a blind or unclear prompt. Cold storage protects the key, not the decision. Read every 0x04 prompt before you confirm.

What is the CrimeEnjoyor contract? It’s the dominant sweeper payload behind these attacks. Wintermute found that 97%+ of in-the-wild 7702 delegations pointed to identical sweeper code, tagged “CrimeEnjoyor,” which auto-drains incoming funds. It’s not one clever hacker — it’s the same drain, copy-pasted at scale.

If I found an unknown delegation, is revoking enough? No. An unknown delegation usually means your private key is already compromised. Revoking clears the symptom, but the attacker can re-delegate. Move your assets to a fresh wallet with a new seed phrase and retire the old one. Migrate, don’t just toggle.

What this changes about how you sign

I started this thinking 7702 gave me a new thing to revoke. I was wrong. It gave me a new reason to slow down before I sign anything at all.

Here’s the reframe that replaced my bad reflex. A token approval is a permission you can take back. A delegation is an identity you lend out — and you can’t reliably un-lend an identity once an attacker holds the same key. So the safety move isn’t a faster revoke button. It’s refusing to sign a 0x04 transaction you don’t understand, and knowing that if one slips through, you migrate rather than patch. The old advice — “keep your keys safe” — quietly stopped being enough the day your signature could rewrite your account.

EIP-7702 delegation is a real upgrade, not a bug. The scam is a social one wearing a technical mask. Check your address tonight, and treat every set-code prompt like the deed to your house, because that’s what it is.

Next in the Crypto Safety series: I’m going to trace a real 7702 delegation on a block explorer, step by step — reading the 0xef0100 marker, following it to the sweeper, and watching where a test transaction goes. If you’ve ever wanted to see one of these with your own eyes instead of taking my word for it, that’s the one to wait for.

---

seonjae — Korean office worker documenting his transition into AI systems, agents, and vibe coding — without a CS background. Shipping in public.