How EIP-7702 delegation works, where it fits next to ERC-4337, and the security issues wallet teams need to close before shipping smart account features to existing EOA users.
Pectra shipped EIP-7702 to Ethereum mainnet in May 2025. The short version: an ordinary wallet address can now run smart contract code without moving to a new address and without giving up its private key.
That sounds like a small protocol tweak. For wallet teams it's a big deal, because the old trade-off between keeping users on EOAs and giving them modern features no longer has to be made. The details live in the EIP-7702 specification, and they matter more than the headline.
Most of the value on Ethereum sits in EOAs, and an EOA can do exactly one thing: sign a transaction and pay for it in ETH. No batching. No one else paying the gas. No recovery if the seed phrase is gone. Anything smarter needs code, and an EOA has nowhere to put it.
ERC-4337 smart wallets fixed the feature gap but created a different problem. To use one, a user has to move to a new contract address and leave the old one behind, along with its ENS name, token approvals and history. Few users bother. So most wallets kept serving plain EOAs and treated smart contract wallets as a separate product for power users.
EIP-7702 adds transaction type 0x04, which writes a pointer into an EOA's code field. From then on, the EOA behaves as if it had the code of another contract that's already deployed. No migration, no asset transfer.
Each authorization carries three values and a signature: chain_id, the delegate contract address and the EOA's nonce, signed as (y_parity, r, s) with the account's own key. The nonce keeps an old authorization from being replayed later. The chain_id pins it to one network, so a mainnet authorization can't be reused on Arbitrum. Set chain_id to 0, though, and the authorization is valid on every chain that supports 7702. Keep that in mind; it comes back in the security section.
The EVM stores a delegation designator in the account: 0xef0100 followed by the delegate's address. Any call to the EOA then runs the delegate's code against the EOA's own balance and storage.
A common misconception is that this is temporary. It isn't. The delegation stays until the owner signs a new authorization, either to another delegate or to the zero address, which clears it. The private key keeps working the whole time and can still send ordinary transactions.
ERC-4337 is still the most complete option. It brings UserOperations, bundlers, paymasters, its own mempool and accounts that don't need a private key at all. The price is a new address.
EIP-3074 tried to solve the same problem with two new opcodes, AUTH and AUTHCALL, that let an invoker contract act with the EOA's signing authority. It was pulled from Pectra in favor of 7702. The invoker model opened a wide phishing surface and didn't fit the ERC-4337 roadmap.
EIP-7702 sits in between. It keeps the address and the key and borrows the code. And because the delegate can itself be an ERC-4337 account, the two standards stack rather than compete.
| ERC-4337 smart account | EIP-7702 delegated EOA | |
|---|---|---|
| Address | New contract address | Same EOA address |
| Private key | Optional | Always keeps full control |
| Onboarding | Deploy or counterfactual account | One authorization signature |
| Bundlers and paymasters | Native | Available if the delegate supports 4337 |
| Fits best | New wallet products | Existing EOA user bases |
Starting a new wallet from scratch? Pure ERC-4337 is the cleaner choice. Sitting on an existing user base that can't change addresses? 7702 is the only realistic path. Plenty of teams end up supporting both.
The obvious win is batching. Approve and swap become one atomic call with one confirmation, and if either step fails, nothing goes through. Gas sponsorship follows naturally, since an ERC-4337 paymaster can now cover fees for a delegated EOA that holds no ETH at all.
Session keys are the feature games and trading apps have wanted for years. The delegate registers a secondary key limited by time, contract or spend, and the app works inside those limits without a popup for every click.
Recovery is where expectations need managing. Guardian logic can live in the delegate, and it helps if a user loses their key. It does nothing if the key is stolen, because the original key still overrides every rule in the delegate. For the same reason, delegating to a multisig contract doesn't make the account a real multisig. Wallets that market 7702 recovery as theft protection are setting themselves up for some very unhappy support tickets.
One signature to a malicious delegate hands over the account and everything in it. Phishing kits targeting 7702 authorizations appeared within weeks of Pectra. The defense is mostly product work: show the delegate address clearly, allow only audited delegates from an allowlist, and never let a dApp request a raw authorization. The smart contract security guide covers the testing side.
Switching delegates doesn't wipe storage. If a user moves from delegate A to delegate B and B reads slot 0 expecting a different layout, it inherits whatever A left there. Namespaced storage (ERC-7201) avoids most of this.
Initialization is the quieter trap. If anyone can call the delegate's init function right after delegation, a frontrunner will get there first. initWithSig, or an init that only the ERC-4337 EntryPoint can call, closes that gap.
Then there's tx.origin. A delegated EOA can originate a transaction and also receive calls, so msg.sender == tx.origin no longer proves the caller is an EOA. Contracts that leaned on that check as reentrancy protection need a real guard.
A chain_id 0 authorization works on every 7702 chain. If the delegate address holds different code somewhere else, or nothing yet, the account is exposed there. Wallets should sign chain-specific authorizations by default and allow chain_id 0 only for immutable delegates deployed at the same address everywhere. Delegating to an upgradeable proxy with chain_id 0 is simply a bad idea.
Revocation means signing an authorization to the zero address. Put it one tap away in the security settings. Burying it three menus deep is a support problem waiting to happen.
Don't write a delegate from scratch. Audited options exist, including Alchemy's Modular Account, ZeroDev's Kernel, Safe's 7702 proxy and the Ethereum Foundation's Simple7702Account. Pick one that supports ERC-4337 and keep its surface small.
The contract is rarely where these projects slip. Anyone who has integrated custody or wallet infrastructure knows the pattern: the SDK call works in a day, and the signing screens, edge cases and support runbooks take the rest of the sprint. The authorization prompt has to read like what it is, a lasting grant of control: "You are granting [Contract X] the ability to act on your account." Budget as much time for that screen as for the contract work.
Test delegation, execution, revocation and nonce edge cases on Sepolia and Hoodi. Ship it as an opt-in beta first. Keep a kill switch, but be clear about what it does: it stops the wallet offering new delegations. Existing ones stay live until each user revokes them, so the revoke flow has to work on day one.
eth_getCode on a delegated EOA no longer returns empty. It returns the 0xef0100 designator. Frontends that treat any code as "this is a contract" will misread these users, and indexers that assumed EOAs never emit events should check for gaps.
For batching, dApps shouldn't sniff code at all. ERC-5792 lets the app ask the wallet what it supports with wallet_getCapabilities, then send approve and action together through wallet_sendCalls. The wallet decides how to execute it. That keeps the dApp out of the delegation business entirely, which is where it belongs.
Build or integrate is the first call. An SDK from ZeroDev, Alchemy or Safe gets a team live fast, at the cost of following someone else's release schedule. A custom delegate gives full control, and every version of it needs its own audit.
The second is versioning. Moving users to a new immutable delegate means asking for a fresh signature each time. A proxy avoids that but asks users to trust whoever holds the upgrade key. Neither is free, and the trade-offs look a lot like smart contract upgradeability in general. Whatever the choice, track which delegate version every user is on.
EIP-7702 gives existing EOAs batching, sponsored gas and session keys without a new address. The delegation persists until revoked, the original key never loses control, and chain_id 0, storage collisions and open initializers are the things to close before launch. Teams planning this upgrade can work with DESH on crypto wallet development.
It's a regular EOA that points to a deployed smart contract and runs its code. Same address, same key, but it can batch calls, use sponsored gas and session keys. The delegation stays until the owner revokes it.
Not better, different. ERC-4337 suits new products that can give users a new address. EIP-7702 suits existing EOA users. A delegate that supports 4337 uses the same bundlers and paymasters, so many wallets run both.
With the Pectra hard fork on May 7, 2025. Nodes and RPC providers need a Pectra-compatible client to handle type 0x04 transactions.
