EIP-7702

EIP-7702 introduces a new transaction type — SET_CODE_TX_TYPE = 0x04 — that lets an externally owned account (EOA) point its execution to smart contract code without ever giving up its address or its private key. The upgrade shipped to Ethereum mainnet in the Pectra hard fork on May 7, 2025, and is the bridge between traditional EOA wallets and the account abstraction world of ERC-4337.

How EIP-7702 works

An EIP-7702 transaction carries an authorization_list of tuples, each shaped [chain_id, address, nonce, y_parity, r, s]. Every tuple is a signature over keccak256(MAGIC || rlp([chain_id, address, nonce])), where MAGIC = 0x05 is a domain separator. The signer of the tuple — the authority — is the EOA whose code will be set. When the tuple is processed, the EVM writes a 23-byte sequence to the authority's account code:

10xef0100 || address

This sequence is called the delegation designator. The 0xef prefix reuses the opcode that EIP-3541 banned as a regular contract-code prefix, which is what marks the account as a 7702-delegated EOA rather than a normal contract.

From that point on, any call to the EOA — whether a regular CALL, a STATICCALL, or even an ERC-4337 handleOps invocation — follows the pointer and executes the implementation contract's code in the EOA's own storage context.

How delegated EOAs differ from regular contracts

The asymmetry between execution and code-introspection opcodes is critical for auditors:

The spec made this trade-off deliberately so that contracts cannot temporarily masquerade as another codehash. The practical consequence is that msg.sender == tx.origin and "is this an EOA" checks based on EXTCODESIZE are no longer reliable for protocols that accept user calls.

Why EIP-7702 matters for security

EIP-7702 changed the wallet attack surface overnight. With a single signature, a user can replace their account's execution logic. There is no separate deployment step — the signature is the deployment. This compresses several historical multi-step exploit paths into a one-shot phishing event and creates new audit categories:

• Authorization phishing: a phishing site that captures a 7702 authorization signature can delegate the victim's EOA to a sweeper contract, often bundled with batch token approvals in the same transaction.
• Insecure delegate contracts: a delegate that does not authenticate every call with a signature committing to nonce, value, gas, target, and calldata becomes a public power of attorney over the EOA.
• Cross-chain replay: tuples signed with chain_id = 0 can be replayed across every EVM chain where the same delegate address exists.
• ERC-4337 composition: a delegated EOA is a valid target for ERC-4337 bundlers, so a malicious delegate can be activated by any party that routes a UserOperation through the EOA's address.

For audit teams, EIP-7702 means that wallet-side code, delegate contracts, and protocol-side EOA assumptions all sit on the same threat surface for the first time. A complete review of any post-Pectra protocol that interacts with EOAs needs to cover all four.