EIP-7702 is a new Ethereum transaction type that lets an externally owned account (EOA) temporarily point to smart contract code for the duration of a transaction. Included in the Pectra hardfork in 2025, it was co-authored by Vitalik Buterin, Ansgar Dietrichs, and Matt Garnett. The EOA keeps its address and private key but can execute logic — batch calls, gas sponsorship, session keys — that previously required migrating to a contract wallet.
​

Before EIP-7702, Ethereum had two account types with a hard boundary between them: EOAs controlled by a private key, and smart contracts that hold executable code. If you wanted your wallet to do anything beyond sign a single transaction, you had two options — move to a contract wallet like a ERC-4337 account, or rely on the app itself to bundle operations. Most users never made that jump. EIP-7702 removes the need to choose.
​

The EIP is specified on eips.ethereum.org and was originally proposed as a simpler alternative to EIP-3074, which would have given contracts authority to act on behalf of EOAs in a way that raised irreversibility concerns.
​

EIP-7702 introduces a new transaction type called SET_CODE. The EOA owner signs an authorization tuple that points their account's code storage to an existing smart contract address. When the transaction executes, the EVM treats the EOA as if it were that contract for the duration of the call. After the transaction, the delegation pointer can be revoked or changed with another SET_CODE transaction.
​

The technical mechanism is precise. When an EOA opts in, the EVM writes a delegation designator into the account's code field. That designator starts with the prefix 0xef0100 followed by the 20-byte address of the contract being delegated to. Any call to the EOA then resolves through that pointer, loading the contract's bytecode and running it in the context of the EOA's address and storage.
​

Several details matter for understanding how this differs from a full contract deployment:

Vitalik's original writeup on the design rationale is at vitalik.eth.limo, where he frames EIP-7702 as part of a broader effort to close the UX gap between EOAs and contract wallets without requiring a full account migration.
​

Understanding what an EOA is and why the private key remains in control matters here. If you need a primer, see What Is a Private Key and What Is a Smart Contract.
​

Three capabilities become available to EOA wallets immediately after EIP-7702 activates: batch transactions, gas sponsorship, and session keys. Each solves a friction point that has blocked mainstream crypto UX for years. None of them require the user to migrate to a new wallet type or contract address.
​

Today, approving a token and then swapping it requires two separate transactions, two separate confirmations, and two separate gas payments. With EIP-7702, a delegated EOA can execute an execute() function that bundles multiple calls into a single transaction. The user signs once. The contract logic handles the sequence — approve, swap, deposit — atomically.
​

This matters most in DeFi. A user depositing into a yield strategy that requires approving three tokens, entering a vault, and staking an LP receipt currently faces five to six transactions. EIP-7702 collapses that to one.
​

Gas sponsorship (also called a paymaster model) lets a third party pay the gas for a user's transaction. With a delegated EOA, the contract code can include paymaster logic that checks whether a relayer has pre-authorized gas payment. The user signs the intended action; the relayer broadcasts it and covers the fee.
​

This unlocks onboarding flows where new users interact with an app before they hold any ETH. An app can sponsor the first ten transactions for every new wallet, then shift to user-paid after that threshold.
​

Session keys are scoped authorizations that let an application execute a defined set of actions on the user's behalf without asking for a signature each time. A game wallet, for example, might grant a session key that can call specific game contracts, spend up to 0.01 ETH per day, and expire after 24 hours.
​

The contract code delegated via EIP-7702 defines the permission rules. The session key signs individual operations within those rules. The user's main private key is never exposed to the app. EIP-7702 gives the EOA the execution context needed to enforce those rules onchain.
​

Session key permissions are formalized in ERC-7715, which defines a standard interface for wallets to express and validate session grants. EIP-7702 and ERC-7715 are designed to work together.
​

EIP-7702 and ERC-4337 both move Ethereum wallets toward smart account capabilities, but they approach the problem from opposite ends. ERC-4337 replaces the EOA entirely with a contract wallet deployed at a new address. EIP-7702 keeps the EOA and temporarily layers smart contract logic on top of it. They are complementary, not competing — many wallets will use both, with EIP-7702 handling EOA users today and ERC-4337 serving as the long-term contract wallet standard.
​

See What Is ERC-4337 for a full breakdown of the contract account model and how the bundler mempool works.
​

EIP-7702 introduces new attack surfaces that wallet developers and users need to understand. The core risks are not theoretical — they follow directly from the mechanics of delegating an EOA's execution context to arbitrary contract code. Three categories matter most: signature replay, malicious delegation targets, and key exposure patterns.
​

An EIP-7702 authorization is a signed message. If that signature is intercepted or reused, an attacker could submit it to set the user's code pointer to a contract they control. The EIP includes a nonce field in the authorization tuple specifically to prevent replay. Wallets must increment the nonce on each authorization, and users should only sign authorizations from applications they trust.
​

Cross-chain replay is a separate concern. An authorization signed for Ethereum mainnet could theoretically be replayed on a chain with the same chain ID if that chain activates EIP-7702. The chain_id field in the authorization is the mitigation. Wallets should always include it and never allow authorizations with a zero chain ID unless they explicitly intend multi-chain validity.
​

When a user delegates their EOA to a contract address, they are granting that contract full execution rights over their account — including the ability to move ETH and ERC-20 tokens held at the EOA address. A maliciously crafted delegation contract could drain the account in a single transaction.
​

Users should only delegate to audited, well-known contract implementations. Wallet interfaces should display the contract address and, where possible, verify it against a registry of known-safe implementations before prompting the user to sign. The Ethereum Foundation's security team has published guidance on this at ethereum.org.
​

EIP-7702 does not change how private keys work. The EOA owner still needs their private key to sign authorizations and transactions. Losing the private key still means losing the account. A delegation can be revoked, but only by someone who holds the key.
​

This is a feature, not a limitation. It means EIP-7702 is compatible with every existing key management approach: hardware wallets, seed phrases, cloud-backed keys. See What Is a Non-Custodial Wallet for context on self-custody tradeoffs that apply here.
​

Wallet teams began integrating EIP-7702 in the months leading up to Pectra. MetaMask, Coinbase Wallet, and Safe have each published roadmaps for how they plan to expose the new capabilities. The integration approaches differ in how much of the complexity they surface to users.
​

MetaMask's approach, documented in their developer preview, treats EIP-7702 as an upgrade layer for existing accounts. When a user wants to do a batch transaction or enable gas sponsorship for a dapp session, the wallet prompts them to sign a SET_CODE authorization pointing to a MetaMask-audited delegation contract. The user sees a single "enable smart features" step, not the underlying mechanics.
​

Coinbase Wallet has taken a similar approach, tying their EIP-7702 integration to their Smart Wallet product. Accounts created through Smart Wallet can operate as either a contract account (ERC-4337) or a delegated EOA (EIP-7702) depending on which mode the dapp supports. This dual-mode design lets one address work across the full spectrum of Ethereum applications, whether or not they have been updated to handle ERC-4337 UserOperations.
​

Safe, which has historically served as the reference implementation for multisig contract wallets, has proposed a path for existing Safe deployments to register as valid delegation targets for EIP-7702. This would allow individual EOA signers on a Safe to grant temporary elevated permissions without creating a new address, which simplifies workflows for treasury management and DAO operations.
​

For end users, the visible changes will be gradual. Dapps that adopt EIP-7702 patterns will start offering single-click flows for actions that previously required multiple transactions. Gas sponsorship will appear as fee-free onboarding within specific apps. The SET_CODE machinery will be invisible unless the user digs into transaction details. The EIP-7702 specification on GitHub gives the full technical detail for developers building integrations.
​

EIP-7702 provides the execution mechanism for smart wallet features on an EOA. ERC-7715 provides the permission language that makes those features safe to grant to third-party applications. Together they form the foundation for a session key standard that works across wallets and dapps without requiring any particular account type.
​

ERC-7715 defines how a wallet expresses a permission grant: which contract addresses the session key can call, which functions it can invoke, spending limits, time-to-live, and revocation conditions. The permission object is structured, machine-readable, and intended to be displayed to users in plain language before they approve it.
​

When a user opens a game, a DeFi protocol, or a trading terminal and chooses to "approve for this session," the wallet flow looks like this:

This architecture keeps the user's primary key offline and unexposed for the entire session. The session key only has authority within the bounds the user approved. If the dapp tries to exceed those bounds, the delegated contract rejects the call onchain.
​

For a full breakdown of how ERC-7715 defines and enforces permissions, see What Is ERC-7715.
​

The combination of EIP-7702 and ERC-7715 is the closest Ethereum has come to a native session key standard that works for both EOA and contract wallet users. Wallet teams including MetaMask, Coinbase Wallet, and Biconomy have indicated intent to implement both. The ERC-7715 working group maintains a reference implementation and compatibility tracker.
​

No. EIP-7702 and ERC-4337 solve different problems and will coexist. ERC-4337 is the long-term standard for fully programmable contract wallets. EIP-7702 gives existing EOA users access to smart wallet features today without migrating. Most major wallet teams plan to support both, routing users to the appropriate model based on their account type.
​

Yes, if you delegate to a malicious or buggy contract. The delegated code runs with full access to your account balance and approved tokens. Only delegate to contracts audited by trusted teams. Your wallet should display the contract address before you sign any SET_CODE authorization. If it does not, treat the request as suspicious and do not proceed.
​

No. EIP-7702 delegation does not change your EOA address. The same address you use today continues to receive funds, hold tokens, and interact with contracts after you enable a delegation. This is one of the key practical advantages over migrating to an ERC-4337 contract wallet, which requires updating every approval and informing senders of your new address.
​

Yes. EIP-7702 activated as part of the Pectra upgrade in 2025. Any Ethereum EOA can now submit SET_CODE transactions. Whether your specific wallet exposes this capability depends on whether the wallet team has shipped a user interface for it. Check your wallet's release notes or developer documentation for current status.
​

Sending ETH does not clear the delegation. The delegation persists until you explicitly revoke it with a SET_CODE transaction that sets an empty address. Your account can send, receive, and hold ETH normally while a delegation is active. The delegation only affects what happens when the account is called as a contract — it does not interfere with standard EOA transaction signing.
​

Article by the Eco team. Last updated April 2025.
​