One signature, every asset: the EIP-7702 delegation trap

EIP-7702 arrived with Ethereum's Pectra upgrade in May 2025. It lets an externally owned account, the ordinary kind with one private key, delegate its execution to a smart contract. Done well, that brings batching, gas sponsorship, spending limits and recovery to the hundreds of millions of accounts that will never migrate to a new address.

Done badly, it is the most powerful phishing primitive Ethereum has had.

The problem: delegation is total and persistent

A 7702 authorization says: from now on, when this account is called, run that contract's code. It is not a one-off approval for one token. Every subsequent call is routed to the delegate until the user replaces it. A malicious delegate can move every asset the account holds, now and later.

The evidence arrived quickly:

• Sweepers dominated early use. Wintermute's analysis weeks after Pectra found that over 80 percent of new delegations pointed to copy-pasted sweeper contracts, used to drain accounts whose keys had already leaked. Later analyses put the share even higher.
• Phishing followed. SlowMist recorded drainer kits disguising delegations as routine operations, including a loss of about $146,000 in May 2025 attributed to the Inferno Drainer group.
• Researchers formalised it. An academic study of 7702 phishing describes how one authorization gives persistent control and why existing wallet warnings miss it.

Why existing warnings miss it

Wallets learned to warn about approve and setApprovalForAll. A delegation looks different: it is signed as an authorization tuple, possibly bundled inside an innocent-looking batch, and its danger depends entirely on code at another address. A wallet that shows "Sign authorization for 0x7a3…" has told the user nothing.

The proposal: five defences, in the wallet and the app

1. 01Allowlist delegates. Wallets should only let users delegate to audited, well-known smart-account implementations, and refuse anything else by default. There are few legitimate targets; that is a feature.
2. 02Name the target in plain language. "Upgrade this account to Safe smart account v1.4, audited by…" or a hard stop. Never a bare address.
3. 03Simulate the effect. Before signing any batch, simulate it and show balance changes and any change to the account's delegate. A delegation hidden in a batch should be the headline, not a footnote.
4. 04Scope power with session keys. Most apps do not need total control. Session permissions, as in ERC-7715, let a game or an agent spend a fixed budget on specific contracts until a deadline, and nothing more.
5. 05Make revocation easy. One visible setting showing the current delegate, with a one-tap reset, and alerts when it changes.

For apps, the corresponding rule is simple: never ask for a delegation to your own contract unless you are a wallet, and request scoped permissions instead.

What to measure

• Delegation targets. Every delegation your wallet signs, grouped by target; anything outside the allowlist should be zero.
• Blocked attempts. How often the wallet refuses or warns on a delegation, and how many users proceed anyway.
• Permission scope. For apps, the average spend limit and lifetime of session permissions requested, against what the feature needs.
• Time to revoke. How long a user who wants to remove a delegate takes to find and complete it.

How we would start

If you ship a wallet, audit how your signing screen renders authorization tuples and batches today; that is usually where the gap is. If you ship a dApp, replace broad approvals with scoped session permissions. Both are part of our wallets and account abstraction and dApp work, and we review signing flows in every security audit.