EIP-7702 lets an externally owned account (EOA) temporarily delegate execution to a smart contract by attaching code to its address for the duration of a transaction. Activated on May 7, 2025 with the Pectra hard fork, it brings smart-account features — batched transactions, gas sponsorship, session keys, transaction-level signing rules — to the same private keys that already secure the majority of Ethereum's user accounts.
​

The proposal was authored by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and Matt Garnett. It replaced an earlier ERC-3074 design that had been on the roadmap for two years and was ultimately rejected because it gave one specific contract (the "invoker") too much trust. EIP-7702 distributes that trust by letting users sign delegations to any contract they choose.
​

EIP-7702 is a Core Standards Track EIP, published as EIP-7702 on eips.ethereum.org. It introduces a new transaction type, Type 4, that carries an authorization list. Each authorization is a signature from an EOA pointing to a contract address. When the transaction executes, the EOA's address temporarily inherits the bytecode of the named contract.
​

The temporary nature is critical. Outside the transaction, the EOA still behaves like a normal account. There is no permanent migration. Users can revoke delegation by signing a new authorization pointing to the zero address.
​

The change touches one of Ethereum's foundational distinctions. Since launch, accounts came in two types: EOAs (controlled by a private key, no code) and contracts (code, no key). EIP-7702 blurs this by giving EOAs the ability to temporarily run code without losing their key-based control.
​

The transaction format extends EIP-2930 access lists with an authorization list. Each authorization includes the chain ID, the contract address being delegated to, a nonce, and a signature from the EOA's private key. When validators process the transaction, each authorization stamps the corresponding EOA with the contract's code for the rest of the transaction's execution.
​

The signed authorization can be reused across many transactions. Once signed, the delegation persists until either explicitly revoked or replaced by a new authorization. This separates the act of delegating (a one-time signature) from the act of executing (any number of subsequent transactions).
​

A typical flow:

The features enabled by EIP-7702 mirror those of dedicated smart accounts but apply to existing EOAs. The most-cited capabilities:

These features were already available to ERC-4337 smart accounts, but ERC-4337 required users to deploy a new contract account and migrate their funds. EIP-7702 lets users keep their existing address and still gain the same features.
​

EIP-7702 emerged from a multi-year debate about how to bring account abstraction to existing users. The three main proposals each took different positions:

ERC-4337 and EIP-7702 are complementary, not competing. ERC-4337 supplies the wallet contract architecture, paymaster pattern, and bundler infrastructure. EIP-7702 lets EOAs opt into that architecture without redeploying. Many production smart-wallet stacks — Safe, Biconomy, ZeroDev, Alchemy — already support both paths.
​

An EIP-7702 authorization is a tuple of (chain_id, contract_address, nonce, signature). The signature is over the keccak hash of the magic byte 0x05 concatenated with the chain ID, contract address, and nonce. The chain ID can be set to zero to make the authorization valid on any chain, although wallet UIs typically default to the user's current chain to prevent cross-chain replay surprises.
​

The nonce is bound to the EOA's account nonce at the time of authorization. Once the nonce moves forward, an old authorization becomes invalid. This prevents replay of an authorization across many transactions if the user wants single-use delegation, although in practice most authorizations are reused across many subsequent transactions.
​

The contract address is the destination of the delegation. Setting it to the zero address (0x000...0) clears any existing delegation, which is the canonical revocation pattern. Wallet UIs typically expose this as a "Disconnect" or "Revoke" button.
​

The Type 4 transaction itself contains a list of authorizations, allowing one transaction to delegate multiple EOAs at once. This is rarely used for individual users but matters for batch onboarding flows where a sponsor wants to delegate many EOAs in a single transaction.
​

The same flexibility that makes EIP-7702 useful also expands the attack surface. Three concerns recur in security audits of early implementations:

The Ethereum security community has been documenting these issues since Pectra activation. OpenZeppelin's analysis and eth-infinitism's account-abstraction repository are the closest things to canonical references for safe integration patterns.
​

Adoption in the months after Pectra has tracked the readiness of wallet vendors. By mid-2025, MetaMask, Rabby, and Coinbase Wallet had shipped EIP-7702 support behind feature flags, with full rollout staged. Dune dashboards tracking Type 4 transactions show steady week-over-week growth, with batched transactions and gas-sponsored onboarding as the most-used patterns.
​

The largest production user base running EIP-7702 today is gas-sponsored onboarding flows. New users who arrive without ETH can have their first transactions paid for by an app's paymaster, with the user signing an authorization once. This pattern was previously possible only via ERC-4337 contract accounts.
​

For stablecoin payments, EIP-7702 unlocks two patterns that previously required either ERC-4337 contract accounts or off-chain custodians. The first is gas-sponsored stablecoin transfers, where the recipient or a third party pays the network fee in fiat or USDC and the sender holds only stablecoins. The second is policy-driven sending, where a treasury sets onchain rules — daily limits, allowlisted destinations, time-of-day windows — that a session key enforces.
​

Cross-chain stablecoin orchestration platforms can now route transfers from EOAs that behave like smart accounts. A user signing an intent for a USDC transfer from Ethereum to Arbitrum can pay gas in USDC, batch the approval and the intent submission, and revoke session keys without migrating to a new wallet. Stablecoin swap aggregators and deposit-automation tools are early adopters of these flows.
​

Eco's intent-based routing layer integrates EIP-7702 authorizations as one of several signature schemes for cross-chain transfers, alongside EIP-712 and ERC-4337's UserOperation format. The choice of scheme depends on the user's wallet and the destination chain's support.
​

EIP-7702 activated on May 7, 2025 with the Pectra hard fork (Prague execution layer + Electra consensus layer). Pectra also included EIP-7251 (raise the validator effective balance to 2,048 ETH), EIP-7691 (raise blob target to six per block), and several other proposals.
​

No. EIP-7702 explicitly avoids requiring migration. The same EOA address can opt into smart-wallet features by signing a delegation, and revoke it later. The private key continues to control the account; the contract code is layered on temporarily.
​

ERC-4337 is a contract-account standard with its own mempool and bundler infrastructure. EIP-7702 is a protocol change that lets EOAs delegate to a contract without becoming a contract account. Most production stacks support both: ERC-4337 for users who want a fresh smart-account address, EIP-7702 for users staying with their existing EOA.
​

Yes. Signing a new authorization pointing to the zero address (0x000...0) clears the existing delegation. Some wallet UIs surface this as a "revoke" button. Until revoked, the delegation persists across transactions, which is what makes the feature useful for repeated batching.
​

It depends on each L2's client roadmap. EVM-equivalent rollups generally support new transaction types after their host chain integrates them. Arbitrum, Optimism, and Base have ongoing work to support EIP-7702; consult each rollup's release notes for the exact activation block.
​