# EIP-7702

> EIP-7702 is an Ethereum improvement proposal that lets externally owned accounts delegate code execution to existing smart contracts, adding smart-account features such as transaction batching and fee sponsorship.

- Canonical URL: https://iq.wiki/wiki/eip-7702
- Categories: Projects & Protocols
- Tags: Ethereum, Infrastructure
- Created: 2026-10-30T13:04:34.908Z
- Last updated: 2026-10-30T13:04:34.908Z
- Source: IQ.wiki — the world's largest blockchain and crypto encyclopedia (https://iq.wiki)

---

**EIP-7702** is an [Ethereum](https://iq.wiki/wiki/ethereum) Improvement Proposal that lets an externally owned account (EOA) delegate code execution to an existing [smart contract](https://iq.wiki/wiki/smart-contract) while retaining its address and private key. Created by [Vitalik Buterin](https://iq.wiki/wiki/vitalik-buterin), Sam Wilson, [Ansgar Dietrichs](https://iq.wiki/wiki/ansgar-dietrichs), and lightclient, it was activated on May 7, 2025, as part of Ethereum’s Pectra upgrade.[\[1\]](#cite-id-onl799izdk)​[\[2\]](#cite-id-3unuqb31zy)​

The delegation persists until it is replaced or cleared. It allows an EOA to use features implemented by delegated code, such as batching and sponsored transactions, without moving its assets or changing its address.[\[1\]](#cite-id-onl799izdk)​[\[3\]](#cite-id-z2pee5blik)​

## History and Design

Published as EIP-7702, “Set Code for EOAs,” on May 7, 2024, the proposal was designed to bring account-level user-experience features to EOAs. Its stated priorities included batching operations, transaction sponsorship, and restricting the privileges of sub-keys.[\[1\]](#cite-id-onl799izdk)​

EIP-7702 is described as a successor to EIP-3074, developed to address limitations and security concerns raised about that earlier proposal.[\[2\]](#cite-id-3unuqb31zy) The proposal’s authors favored persistent delegation over an earlier design that would have cleared code at the end of each transaction. They argued that repeated, easy authorizations could encourage EOA scripts as a separate user-experience model rather than promote convergence with smart-contract wallets.[\[1\]](#cite-id-onl799izdk)​

EIP-7702 points an EOA to code already deployed at another address rather than placing arbitrary bytecode in the authorization. The authors estimated that a minimal proxy would require about 50 bytes, compared with 20 bytes for an address pointer, without adding useful functionality to the delegation mechanism.[\[1\]](#cite-id-onl799izdk) The proposal does not run initialization code as part of delegation; setup must happen in a subsequent call, avoiding a new execution mode but making setup non-atomic.[\[1\]](#cite-id-onl799izdk)​

The design was intended to work with future [account abstraction](https://iq.wiki/wiki/account-abstraction). Delegated code can point to existing [ERC-4337](https://iq.wiki/wiki/erc-4337) wallet code, allowing an EOA to participate in ERC-4337 bundles through the existing EntryPoint. EIP-7702 does not add opcodes or incorporate detailed [ERC-4337](https://iq.wiki/wiki/erc-4337) or RIP-7560 mechanisms into the protocol itself.[\[1\]](#cite-id-onl799izdk)​

## Transaction and Delegation Mechanism

EIP-7702 introduces transaction type `0x04`, called a set-code transaction. It contains the usual transaction fields, an access list, and a nonempty authorization list; the transaction type excludes contract creation and blob transactions, and a null destination is invalid.[\[1\]](#cite-id-onl799izdk) Each authorization is a tuple of chain ID, delegation address, account nonce, and signature values: `[chain_id, address, nonce, y_parity, r, s]`.[\[1\]](#cite-id-onl799izdk)​

The authority signs a hash of the authorization parameters, `keccak(0x05 || rlp([chain_id, address, nonce]))`. A chain ID of zero allows the authorization to apply across chains; a chain-specific ID restricts it to that chain. The nonce binds the authorization to the account’s current state and helps prevent replay.[\[1\]](#cite-id-onl799izdk)​[\[3\]](#cite-id-z2pee5blik)​

During processing, the chain checks that the authorization’s chain ID is zero or matches the current chain, that its signature is valid, and that the authority’s nonce matches the signed nonce. The authority must have no code or already be delegated. A valid authorization sets the authority’s code to a 23-byte delegation indicator consisting of the prefix `0xef0100` and the target address, then increments its nonce.[\[1\]](#cite-id-onl799izdk) An authorization to the zero address clears the indicator. Invalid authorizations are skipped while processing continues, and if multiple valid authorizations concern the same authority, the last one determines its code.[\[1\]](#cite-id-onl799izdk)​[\[3\]](#cite-id-z2pee5blik)​

The indicator marks delegated accounts using the `0xef` byte, which EIP-3541 prohibits in ordinary code. When a code-executing operation reaches a delegated account, [Ethereum](https://iq.wiki/wiki/ethereum) loads code from the target but executes it in the authority’s account context. Resolution follows only one delegation pointer, preventing chains of delegations; if the target is another delegated account, resolution stops, and a target that is a precompile resolves to empty code.[\[1\]](#cite-id-onl799izdk)​

Delegation does not cause code-inspection operations to treat the authority as if it had the target’s code. 

For example, `EXTCODESIZE` and `EXTCODECOPY` on the authority observe the 23-byte indicator, while `CODESIZE` and `CODECOPY` refer to the code currently executing.[\[1\]](#cite-id-onl799izdk) Delegation indicators also remain in place if execution of the outer transaction later fails.[\[1\]](#cite-id-onl799izdk)​

The base authorization cost is 12,500 [gas](https://iq.wiki/wiki/gas) per authorization, with a further maximum charge of 25,000 gas for an authorization involving an empty account; processing refunds 12,500 gas when the authority is already nonempty. Resolving delegated code from a cold account adds the 2,600-gas cold-account-read cost, or 100 gas for a warm read.[\[1\]](#cite-id-onl799izdk)​

## Account Capabilities and Integrations

Delegated code can enable several wallet features. EIP-7702 supports batching multiple operations atomically in one transaction, such as combining an approval and a token swap. It can also support third-party payment of transaction fees, alternative authentication such as passkeys, spending limits, and account recovery without moving to a new address.[\[2\]](#cite-id-3unuqb31zy)​[\[1\]](#cite-id-onl799izdk)​

The authorization itself does not impose fine-grained permissions: the EIP warns that delegated code has unrestricted access to the account. Restrictions such as session keys or spending limits must be implemented by the delegated wallet code or its modules.[\[1\]](#cite-id-onl799izdk)​[\[3\]](#cite-id-z2pee5blik) The EOA’s private key retains full control after delegation, so delegating to a multisignature wallet contract does not by itself turn the EOA into a multisignature account; the key can still bypass that contract’s signing policies.[\[3\]](#cite-id-z2pee5blik)​

Ethereum.org recommends that delegation contracts align with account-abstraction standards and ideally support [ERC-4337](https://iq.wiki/wiki/erc-4337). It also recommends avoiding dependence on a single relayer, whose failure could prevent the account from using relayer-dependent features. EOAs can perform batching themselves, while features such as [gas](https://iq.wiki/wiki/gas) abstraction and privacy-preserving withdrawals require a relayer.[\[3\]](#cite-id-z2pee5blik) The guidance recommends ERC-4337 bundlers using EntryPoint 0.8 or later, citing standardized relaying interfaces, built-in paymasters, and compatibility with future development.[\[3\]](#cite-id-z2pee5blik)​

For [dApp](https://iq.wiki/wiki/decentralized-application) requests, Ethereum.org points to ERC-5792’s `wallet_sendCalls` interface for batched calls, including batching with gas abstraction, and ERC-6900 for modular wallet features such as session keys and recovery. It recommends standardized wallet interfaces because wallets are expected to allowlist delegation contracts and there is no standardized direct method for dApps to request EIP-7702 authorization signatures.[\[3\]](#cite-id-z2pee5blik)​

Alchemy’s Wallet APIs support EIP-7702 delegation by default. Its Transaction APIs can prepare an authorization, request the required signatures, and submit delegation together with the intended calls; initial delegation requires both an authorization signature and a transaction signature, while subsequent transactions require a transaction signature.[\[4\]](#cite-id-2bvhlanl1h) Alchemy’s default delegate for new accounts created through those APIs is Modular Account v2 v1.1.0; existing accounts keep their recorded delegate unless a different supported version is requested, and delegation remains until replaced or cleared.[\[4\]](#cite-id-2bvhlanl1h) Alchemy also supports separate smart-contract-account options that do not use EIP-7702.[\[4\]](#cite-id-2bvhlanl1h)​

## Security Considerations

EIP-7702 changes assumptions about EOAs. 

A delegated EOA can initiate transactions, receive calls, and execute multiple calls in one transaction; its balance can also be changed by a transaction originating from another account. The proposal therefore modifies EIP-3607, which previously restricted EOAs with code from originating transactions.[\[1\]](#cite-id-onl799izdk)​[\[3\]](#cite-id-z2pee5blik)​

Because delegated execution can make `msg.sender` equal `tx.origin` in call contexts beyond a transaction’s topmost frame, contracts cannot safely rely on that equality as a reentrancy safeguard. Ethereum.org recommends explicit protections such as audited `nonReentrant` modifiers or transient-storage variables.[\[1\]](#cite-id-onl799izdk)​[\[3\]](#cite-id-z2pee5blik) The EIP authors characterize reliance on `tx.origin` for these protections as bad practice.[\[1\]](#cite-id-onl799izdk)​

Delegated code can exercise broad control over an account’s assets, so both the proposal and Ethereum.org advise careful review of the target before signing. A vulnerable initialization flow can also be front-run: if initialization is coupled to delegation, someone who obtains the authorization may call initialization first with altered parameters. Suggested mitigations include requiring a signature over initialization parameters or restricting initialization to the [ERC-4337](https://iq.wiki/wiki/erc-4337) EntryPoint.[\[1\]](#cite-id-onl799izdk)​[\[3\]](#cite-id-z2pee5blik)​

Delegation does not clear existing EOA storage. If new code assigns a different meaning to a slot used by earlier code, retained data can cause unintended behavior; the EIP discusses namespaced storage, such as ERC-7201, as one way to reduce storage collisions during upgrades.[\[1\]](#cite-id-onl799izdk)​[\[3\]](#cite-id-z2pee5blik) Ethereum.org also warns that an unprotected proxy initializer can allow an account takeover and recommends minimal, auditable delegation logic and secured constructors and initializers.[\[3\]](#cite-id-z2pee5blik)​

A universal authorization using chain ID zero can apply across Ethereum Virtual Machine chains. Ethereum.org therefore recommends using immutable targets rather than proxies for such delegations, and cautions against contracts whose code could differ at the same address across chains.[\[3\]](#cite-id-z2pee5blik) It also recommends that wallets clearly display the delegation target during signing; [hardware wallets](https://iq.wiki/wiki/hardware-wallet) may instead limit delegation to trusted-contract allowlists.[\[3\]](#cite-id-z2pee5blik)​

Sponsored transactions create additional risks. A relayer may spend [gas](https://iq.wiki/wiki/gas) without reimbursement if the account invalidates an authorization by advancing its nonce or transfers the funds intended for repayment; the EIP suggests that relayers consider bonds or reputation systems.[\[1\]](#cite-id-onl799izdk) Delegated code may also alter balances or nonces in ways that make other pending transactions stale. The proposal recommends that clients accept no more than one pending transaction for an EOA with a nonzero delegation indicator.[\[1\]](#cite-id-onl799izdk)​

## Phishing and Wallet Risks

Within weeks of activation, a specialized phishing method emerged in which a significant number of EIP-7702 delegations on [Ethereum](https://iq.wiki/wiki/ethereum) [mainnet](https://iq.wiki/wiki/mainnet) were found pointing to malicious contracts designed to drain wallet funds.[\[2\]](#cite-id-3unuqb31zy) 

​[Binance Academy](https://iq.wiki/wiki/binance-academy) reported that wallet providers such as [MetaMask](https://iq.wiki/wiki/metamask) flag suspicious authorizations and advised users to treat delegation targets with the same caution as sharing a [seed phrase](https://iq.wiki/wiki/seed-phrase).[\[2\]](#cite-id-3unuqb31zy)​

Ethereum.org cautions that relayer use can expose users’ IP addresses, while public [mempools](https://iq.wiki/wiki/mempool) can make it harder to determine whether a transaction or UserOperation originated from the IP address that propagated it or was forwarded through the peer-to-peer network.[\[3\]](#cite-id-z2pee5blik) It recommends privacy-conscious designs such as [gas](https://iq.wiki/wiki/gas) payment in [ERC-20](https://iq.wiki/wiki/erc-20) tokens, one-time session keys, and off-chain delegation of approvals whose signatures are verified on-chain.[\[3\]](#cite-id-z2pee5blik)​

Wallet support varies. [Alchemy](https://iq.wiki/wiki/alchemy) reports that MetaMask permits delegation to its own contract through its interface but does not support signing arbitrary EIP-7702 authorization payloads; applications using MetaMask may instead need wallet-native features such as ERC-5792 batching.[\[4\]](#cite-id-2bvhlanl1h) On [Monad](https://iq.wiki/wiki/monad), Alchemy’s EIP-7702 support is allowlisted, and delegated accounts must maintain a minimum balance of 10 MON under the documented conditions.[\[4\]](#cite-id-2bvhlanl1h)​