What is EIP-7702?
EIP-7702 is a core protocol proposal that changes what Ethereum accounts can do. EIP stands for Ethereum Improvement Proposal, and 7702 is the proposal number. It lets an externally owned account delegate its code execution to already deployed smart contract code while keeping its original address, balance and private-key control.
An externally owned account (EOA) is an Ethereum account controlled by a private key and commonly used by an individual wallet. A traditional EOA can sign and initiate transactions, but it cannot program batching, permission rules or recovery logic into the account itself as a smart contract account can. EIP-7702 creates a connection between the two account models: an EOA can run designated contract code in its own account context without moving assets to a new address.
The proposal has reached Final status and was activated on Ethereum mainnet on May 7, 2025 as part of the network upgrade called Pectra. It defines an underlying delegation mechanism, not a complete wallet product. Whether features such as batching, gas sponsorship, session permissions or account recovery are available depends on the wallet's chosen delegate contract and its implementation.
What problem does it solve?
A traditional EOA is simple: anyone able to use the corresponding private key can sign and control the account. But the account has no programmable logic. If a user wants to approve a token, swap an asset and deposit the result into another protocol, they generally need to confirm several transactions separately. Gas fees are also typically paid with ETH, Ethereum's native asset, held by the account.
A smart contract account can add more complex validation and execution rules. Creating a new contract account, however, can mean using a new address and handling asset migration, application compatibility and continuity of the account's history or identity.
EIP-7702 lets an existing EOA point to contract code. A wallet can therefore add code-based capabilities to the account without changing its address. The proposal does not remove the EOA's existing private-key control or upgrade every EOA automatically. Delegation is written to Ethereum state only after the account signs and submits a valid authorization.
How does an authorization take effect?
EIP-7702 introduces transaction type 0x04. This transaction can carry one or more authorizations, each showing that an EOA agrees to delegate code execution to a target address.
From a user's perspective, the process has five steps:
- The wallet selects the delegate contract code it intends to use and presents the authorization to the user.
- The EOA signs the authorization, confirming the target network, delegate address and the account's current transaction sequence number, or nonce.
- A type 4 transaction submits the authorization to the network. Its sender may be the EOA or another account paying the gas fee on its behalf.
- After validating the signature and nonce, network nodes write a delegation marker on the EOA that points to the target code.
- When another account or contract subsequently calls the EOA, the target contract's code handles the call while using the EOA's own address, balance and storage context.
Several authorization fields limit different risks:
| Field | Purpose |
|---|---|
chain_id |
Specifies the network where the authorization applies, reducing the risk that it is reused on another network. A value of 0 allows cross-chain use and requires particular caution. |
address |
Identifies the target address that provides the delegate code. |
nonce |
Binds the authorization to the account's transaction sequence number at that time, preventing the same authorization from being reused repeatedly. |
| Signature data | Proves that the corresponding private key agreed to this authorization. |
Delegation does not transfer assets to the target address. The target code executes in the authorizing EOA's context, so it reads and modifies that EOA's storage and uses its address and balance. This is also why delegate code can have broad control over the account.
What changes after authorization?
The account keeps the same address after delegation, its existing balance is not automatically transferred, and its private key can still sign transactions. What changes is that the account's code field stores a special marker pointing to the target contract code. Calls to the account are then handled according to the code referenced by that marker.
Delegation persists. It does not disappear automatically after one transaction. It remains in place until the account uses another valid authorization to point to different code or clears the delegation. A user should not assume that an authorization has ended merely because a particular batched operation is complete.
Setting the authorization and executing the subsequent call are also separate stages. Under EIP-7702's processing rules, a delegation that has already been processed is not automatically rolled back if later execution in the type 4 transaction fails. A wallet needs to present and verify “delegation was written” separately from “the intended action succeeded.”
Which account features can it support?
EIP-7702 gives wallets an underlying tool. Common designs may use delegate code to provide:
- a single signing flow for several operations, such as approval, swapping and depositing;
- submission and gas payment by another account or service;
- granular permissions, such as session keys, per-use limits or restricted targets;
- authentication methods other than a single private-key signature;
- recovery, pausing or spending controls;
- compatibility with smart account infrastructure based on the ERC-4337 account abstraction standard.
EIP-7702 does not guarantee any of these features. It specifies how to authorize, record a delegation and execute the referenced code. The delegate contract and wallet interface determine which features exist, how they validate an action and how recovery works if something goes wrong.
Gas sponsorship does not mean Ethereum stops charging gas. A type 4 transaction allows another account to act as the outer transaction sender, include the EOA's authorization and pay the transaction's gas fee. Whether a service will sponsor the fee, how costs are settled and who pays for subsequent calls are product decisions made by the wallet or service.
How does it differ from a smart account?
“Smart account” is a broad term for an account experience in which programmable code defines validation and execution rules. EIP-7702 is one protocol-level mechanism for enabling that experience, but it is not the same as every smart account design.
ERC-4337 is another account abstraction standard. It organizes actions through a UserOperation data object that describes user intent, bundlers that collect operations and an EntryPoint contract that validates and executes them. It does not require Ethereum's consensus layer to add a transaction rule for each account design. EIP-7702 instead lets an EOA set code delegation directly in protocol state. The two can work together: ERC-4337 defines how its user-operation flow can include an EIP-7702 authorization.
EIP-7702 also does not automatically turn an ordinary EOA into an account controlled exclusively by a true multisignature policy. Even if the delegate code requires several approvals, the original private key can still replace or clear the delegation and can bypass a long-term policy enforced only by the current delegate. If an application needs a control model that one original private key cannot override, it cannot conclude that such a model exists merely because EIP-7702 delegation has been set.
How can delegation be replaced or revoked?
The account can sign a new authorization pointing to another target address. To clear delegation, it can set the authorization target to the zero address. The new authorization must still pass network, signature and nonce checks and be written onchain through a type 4 transaction.
Clearing delegation removes the code pointer, but it does not automatically erase data that the previous delegate code wrote to the account's storage. If the account later uses different code, the new code might read the old data or interpret the same storage location differently. Delegate contract design must account for initialization, upgrades and storage compatibility. Before changing implementations, users also need to confirm whether their wallet provides an appropriate migration and recovery flow.
Revoking delegation is not a substitute for protecting the private key. If the key is compromised, an attacker may still sign a new authorization, replace the delegate or directly control the account. Delegate code can add operational rules, but the original key remains a critical control credential.
Main risks and checks
Malicious or defective delegate code
Delegate code runs in the EOA's own context and may call other contracts, transfer assets or modify storage. Malicious or vulnerable code can gain near-complete operational control of the account. A wallet should verify the target code and its upgrade permissions and should not ask users to sign for an unknown delegate address.
Authorization phishing
An EIP-7702 authorization can affect many future transactions and therefore has a broader scope than a single-transfer signature. If an interface only says “sign in” or “enable a feature” without clearly showing the target network, delegate code and persistence, a user may underestimate the authorization. Ethereum's official guidance recommends that wallets manage delegation interactions and vet target code rather than allowing an ordinary webpage to request arbitrary authorizations.
Cross-chain replay and address differences
The authorization's chain_id limits it to a network. Setting the value to 0 may allow the same authorization to be used on multiple chains, while the same address may not contain the same code on every network. Even when an address has identical text, its code and account state can differ. A wallet needs to verify the network, target address and actual code deployed on that network together.
Initialization and storage conflicts
New delegate code may first need to store an owner, permissions or other initial data. If another party can run initialization first, the account may be configured incorrectly. When delegation changes, implementations that reuse the same storage positions can also create permission or data conflicts.
Old application assumptions no longer hold
Some applications have treated “an account currently has no code” as evidence that it is an ordinary user account, or used tx.origin to infer the source of a call. EIP-7702 lets an EOA execute delegated code, so those assumptions are no longer reliable and may also create reentrancy risks. Applications need to validate permissions through the actual call and authorization model rather than relying on an account's former type characteristics.
Frequently asked questions
Does setting delegation change the wallet address?
No. The EOA keeps its address after delegation, and its balance and history remain at that address. The new element is a code delegation marker.
Does delegation last for only one transaction?
No. Once written, delegation persists until a new authorization replaces or clears it. Failure of an intended action does not necessarily revoke a delegation that has already been processed.
Is the private key still valid after delegation?
Yes. The original private key can still sign transactions, replace delegation or clear it. Delegate code does not remove the need to protect the key.
Does it automatically provide batching and gas sponsorship?
No. It provides the underlying delegation mechanism needed to implement those features. Delegate code implements batching, while gas sponsorship also requires an outside sender or service willing to submit the transaction and pay its fee.
Can an account delegate to any contract?
The protocol allows an authorization to point to a code address, but technical ability does not mean the code is suitable. Because the target code runs in the account's context, users should rely on a trusted wallet to verify the code's purpose, audit information, upgrade permissions and revocation method. They should not sign an authorization they cannot identify.
Related concepts
Continue with Ethereum, smart contracts and the Ethereum Virtual Machine, or return to the Crypto Glossary. This entry will not be linked from the A–Z glossary until all seven language versions are published.
Sources
- EIP-7702: Set Code for EOAs — transaction type, authorization fields, delegated execution, revocation and security considerations.
- Ethereum.org: EIP-7702 guidelines — wallet integration, account control, cross-chain authorization, delegation risks and user interaction guidance.
- Ethereum Foundation: Pectra mainnet announcement — mainnet activation date and the user-feature context for EIP-7702.
- ERC-4337: Account abstraction using alt mempool — how ERC-4337 supports EIP-7702 authorization.
Digital Assets subject to volatility and not insured. Not financial/investment advice. Not all products and services offered in all regions. Exclusions and T&Cs apply.
© 2026 OKX. This article may be reproduced or distributed in its entirety, or excerpts of 100 words or less of this article may be used, provided such use is non-commercial. Any reproduction or distribution of the entire article must also prominently state: “This article is © 2026 OKX and is used with permission.” Permitted excerpts must cite to the name of the article and include attribution, for example “Article Name, [author name if applicable], © 2026 OKX.” Some content may be generated or assisted by artificial intelligence (AI) tools. No derivative works or other uses of this article are permitted.
