EIP-7702: giving your EOA superpowers, in place
Account abstraction (4337) made smart accounts — but you had to move to a new address to use them. EIP-7702 upgrades your existing EOA where it sits: sign a delegation, your account points at a contract, and a call runs that contract's code as you — same address, same key.
- EOAs vs contracts
- account abstraction (4337)
EIP-4337 gave Ethereum smart accounts — programmable validation, batching, sponsored gas — but with a catch: a smart account is a contract, at a new address. To use one you have to migrate: move your funds, re-establish your identity, and abandon the address (and key) everyone knows you by. The hundreds of millions of plain EOAs that almost everyone actually uses were left out. EIP-7702 (shipped in Pectra, 2025) fixes that by letting an EOA temporarily become a smart account while keeping its address and key. The trick is one small idea; let’s derive it.
The problem: 4337 leaves your EOA behind
A 4337 smart account is a contract deployed at its own address. So to get its powers, you move: send your assets to the new account, switch every integration, and live behind a different address. Your EOA Externally-owned account — the plain account derived from a private key. It can start transactions, but its rules are fixed: one ECDSA signature, ETH-only gas, one action. , with all its history and the key people recognize, is left behind — and still rigid.
That migration is friction almost no one wants. And notice the one and only difference between your EOA and a smart account: a smart account has code, and an EOA doesn’t. So the question writes itself.
→ Step 2: point the EOA at a contract.
Sign a delegation; the code becomes a pointer
Add a new transaction type, 0x04, that carries an authorization list: signed tuples of (chainId, delegate_address, nonce). The EOA’s own key signs one — “set my code to delegate to this contract” — and when it’s applied, the account’s code field is set to a tiny delegation designator The 23-byte value 0xef0100 ++ address that EIP-7702 writes into an EOA's code field. It isn't the contract's bytecode — it's a pointer telling the EVM to run that contract's code in this account's context. : 0xef0100 ++ delegate_address. Crucially this is a redirect, not a copy — the EOA doesn’t store the contract’s bytecode, just a 23-byte pointer to it.
→ Step 3: run the code it points to.
Run the delegate’s code — in the EOA’s own context
Here’s the payoff. Whenever the account is called (or acts as the transaction’s sender), the EVM sees the 0xef0100 designator, follows it, loads the delegate contract’s code, and executes it — but in the EOA’s context: the EOA’s storage, the EOA’s balance, the EOA’s address. Inside that code, address(this) is 0xYou. It’s as if your account borrowed the contract’s behaviour while remaining entirely itself.
So a single contract implementation can serve any number of EOAs that delegate to it, and each one runs that logic over its own state. The account is now programmable without ever having moved.
→ Step 4: the powers, and the catch.
What you get — on the address you already have
Your existing account can now do the smart-account things, without abandoning your key: batch an approve and a swap into one atomic call; be sponsored, so a relayer sends the type-0x04 transaction and pays the gas (even your account’s very first transaction); use session keys and scoped permissions; and plug straight into the 4337 ecosystem by delegating to a 4337-style account implementation.