On 7 May 2025, the Pectra hard fork shipped EIP-7702 to Ethereum mainnet. The headline shift is small in bytes and large in consequence: a single signature can now hand a contract full code-execution rights against the signer's externally owned account. Same address, same balance, same nonce — new code. That capability is genuinely useful for batching, gas sponsorship, and account recovery. It is also the cleanest phishing primitive Ethereum has ever produced.
This is Part 3 of the Smart Accounts series. Part 2 covered the ERC-4337 account abstraction architecture — the bundler-and-EntryPoint design that requires a new contract account. EIP-7702 is the parallel track: instead of forcing every user to migrate to a fresh contract address, it upgrades the address you already have. Understanding the EIP-7702 delegation phishing surface starts with understanding what the upgrade actually does.
What EIP-7702 Actually Does
For most of Ethereum's history, an address was either an EOA (a key-controlled account with no code) or a contract (code, but no signing key). EIP-7702 collapses that wall for EOAs. After a 7702 transaction, your EOA still owns its key, history, ENS, and balance — but its code slot now points at a delegate contract. Calls to your address execute that contract's bytecode in your storage context.
The spec replaced the abandoned EIP-3074 design (AUTH/AUTHCALL), which gave a single "invoker" contract latent power to act on behalf of any EOA that had ever signed for it. EIP-7702 is narrower: each authorization is bound to one signer, one delegate, one nonce. The goal is practical — bring batched transactions, gas sponsorship, session keys, and social recovery to the hundreds of millions of existing EOAs without forcing anyone to move funds.
The trade-off is that the upgrade path runs through the user's signature. And the signature, in many wallets, still looks like a generic typed-data prompt.
How the SET_CODE Transaction Works
EIP-7702 introduces a new transaction type, SET_CODE_TX_TYPE = 0x04. The wire format is mostly familiar — gas, nonce, value, calldata — but it carries one extra field: authorization_list, an array of authorization tuples.
Each tuple has six elements:
(chain_id, address, nonce, y_parity, r, s)
The address is the delegate — the contract whose bytecode the EOA wants to borrow. The chain_id, nonce, and signature components prove the EOA holder consented to that specific delegation. Critically, the transaction sender and the signer of an authorization tuple do not have to be the same party. A relayer or sponsor can submit the transaction and pay the gas; the authorizations inside it carry independent signatures from the EOAs being upgraded.
When the transaction is included, the EVM writes a 23-byte value into each authorizing EOA's code slot:
0xef0100 || target_address
The 0xef0100 prefix is the delegation designator. The EVM treats any account whose code starts with those three bytes as: "do not execute this code; instead, fetch the bytecode at target_address and run it in my storage context." Storage, balance, and nonce stay with the EOA. Only execution is borrowed.
One footgun is hard-coded into the spec: an authorization with chain_id = 0 is valid on every EVM chain. It is allowed deliberately, so a single signature can install the same delegate on Ethereum, Base, Arbitrum, and Optimism at once. It is also a cross-chain replay vector. A legitimate front-end would never need it for a single chain. A drainer absolutely would.
The Delegation Lifecycle: Set, Override, Revoke
Three states matter, and the difference between the signature and the on-chain effect is where users get hurt.
Set. The first 7702 transaction installs the delegate. Your address now has code.
Override. A later 7702 transaction with a higher nonce replaces the delegate. This is how you upgrade from one smart-account implementation to another, or how an attacker who already owns your delegation slot can rotate to a freshly-funded drainer contract.
Revoke. Signing a 7702 authorization with target = 0x0000000000000000000000000000000000000000 clears the code slot. Your address goes back to being a vanilla EOA.
The mental-model error users consistently make is treating the signature as ephemeral. It is not. Authorizations are bound to a nonce, so each tuple is one-shot — but the resulting delegation persists until explicitly overridden or revoked. There is no automatic expiry. If you sign once and walk away, the contract you signed to retains code-execution rights against your address until you actively undo it. Future deposits land in a wallet that already has its drain function pre-installed.
Adoption Since Pectra: The Numbers
The rollout was quick. The first week post-Pectra recorded roughly 11,000 authorizations on mainnet, dominated by MetaMask's smart-account opt-in flow and a handful of batched-swap aggregators. MetaMask shipped the EIP-7702 Smart Account flow within days of the fork. Trust Wallet rolled out 7702 paths through Q3 2025, Coinbase Smart Wallet exposed 7702 onboarding for existing EOAs, and Ledger added clear-signing for 0x04 transactions in late 2025 — meaning the device finally showed users the delegate address rather than a hex blob.
Hardware-wallet clear-signing matters. Without it, signing a 7702 authorization on a Ledger or Trezor was indistinguishable from signing arbitrary structured data — a ceremony users had been trained to perform reflexively. With it, the device names the operation and shows the contract that is about to take over your account.
Legitimate use through 2025-2026 is mostly batching, sponsored gas ("transact without holding ETH"), and passkey-based recovery flows. The long tail, predictably, is drainers.
The New Phishing Class: One Signature, Full Code Rights
A traditional drainer needs work. It collects an ERC-20 approve per token, a setApprovalForAll per NFT collection, or a Permit2 signature per allowance — and any one of those can be revoked piecemeal, as covered in our guide to auditing and revoking token approvals.
EIP-7702 collapses that whole funnel into one signature. Sign a single authorization, and the attacker's contract becomes your address's executable code. It can drain every token, every NFT, and every wei of ETH in one transaction — and, because the delegation is sticky, it can do it again on every future deposit. There is no per-asset approval to revoke. The drainer is your wallet's logic until you explicitly clear the code slot.
Three lure flavours have been documented by SlowMist, PeckShield, and CertiK incident reports through 2025-2026:
- Fake gas sponsorship and "free claim" UIs. The page advertises free gas or a token claim and asks for a 7702 signature "to enable smart-account features." The delegate is a drainer.
- Wallet-upgrade impersonation. A page mimics MetaMask's smart-account flow pixel-for-pixel, complete with the correct copy and icons. The signature it requests is structurally identical to the real one — only the delegate address differs.
- Last-second swaps in malicious dApp connectors. The user expects an EIP-712 typed-data prompt for an order or vote. The connector substitutes a
0x04authorization at the moment of signing. In wallets that render both surfaces with the same UI, the difference is one or two pixels of text.
Phishing kits adapted fast. Inferno Drainer, Pink Drainer, and the Angel kit all shipped 7702-flavoured modules through 2025-2026. The economics are obvious: one successful signature replaces what used to be dozens. The deeper problem is the UX overlap with the legitimate flows users have just been told are safe — a pattern we explore in dangerous signature types in Web3 and the broader anatomy of crypto drainer kits.
Mitigations and the Tooling Gap
The defensive stack has three layers, each with a real gap as of early 2026.
Wallet UX. A 7702 prompt should never look like a normal message signature. It should name the operation ("Install delegate code at your address"), show the delegate contract with a verified label or stark warning, decode the function exposure that delegate grants, and refuse chain_id = 0 by default unless the user opts in with a separate confirmation. A non-trivial fraction of wallets still render 7702 prompts as generic signature requests with no clear delegate context. That is the gap.
Delegation-aware tooling. revoke.cash and Wallet Guard rolled out delegation-aware views in late 2025 that surface the current code prefix on any address and offer a one-click revoke. Users should now check delegation status the same way they check approvals — periodically, and after any signature they are unsure about.
Operational hygiene. Treat any 7702 prompt with the suspicion previously reserved for setApprovalForAll. Default-revoke-on-spend and session-bound delegations are emerging wallet patterns — useful, but not yet universal. Until they are, the cleanest defence is the same as for approvals: keep custody and signing on a hardware device with clear-signing, route trades through audited aggregators, and audit your address state regularly. Our guide to DeFi security: approvals and multisig hygiene covers the underlying playbook.
Looking Ahead: Smart Accounts Without the Cliff
EIP-7702 is the right design. It unlocks batching, sponsorship, and recovery for hundreds of millions of existing EOAs without forcing migration to a new address — which would have been a non-starter for the long tail of users with on-chain history, ENS names, and protocol positions tied to a specific public key.
The security model now demands every EOA holder think a little more like a smart-contract user. Read the delegate. Audit the code slot. Revoke aggressively when in doubt. The signature surface is no longer just a way to authorise transactions — in 23 bytes, it can rewrite what your address is.
Part 4 of this series will compare passkey and social-recovery wallets — the user-facing layer most 7702 and 4337 deployments are converging on. Part 5 closes the loop with an operational hygiene capstone for anyone running smart-account flows in 2026.
