EIP-7702 is an Ethereum upgrade that lets an externally owned account (EOA) authorize its address to use code from a deployed smart contract. The change arrived with the Pectra network upgrade, activated on Ethereum mainnet on May 7, 2025. An authorization sets a delegation pointer on the EOA; the pointer remains in the account’s state after the transaction until a later authorization changes or clears it. EIP-7702 can let an existing address use smart-account features, but the features and risks depend on the delegated code and the wallet or application using it.
What EIP-7702 changes
Before EIP-7702, an EOA was controlled by a private key and had no smart-contract code of its own. EIP-7702 adds a “set-code” transaction with an authorization list. The account owner signs an authorization that identifies a chain, a contract address whose code will be delegated to, and a nonce. The EVM records a special delegation indicator at the EOA. When code is executed through that account, the EVM follows the pointer and runs the delegated contract’s code in the EOA’s account context.
The EOA keeps its address and signing key. Its ETH and tokens are not moved into the delegated contract simply because the authorization is set. However, delegated code can act with the EOA’s authority and interact with assets in the account, so choosing the delegate is security-critical.
What it can enable
EIP-7702 creates a way for an existing EOA to use custom account logic without moving to a different address. Depending on the delegate contract and wallet support, that logic may provide features such as batched calls, spending controls, recovery modules, or a sponsored transaction flow.
Those features are not automatic protocol benefits. For example, EIP-7702 does not by itself let a user pay Ethereum gas in USDC. A wallet may arrange for a relayer or paymaster to submit or sponsor a transaction, and the delegated code must be designed to support that arrangement. The transaction sender still pays the network fee, even when another service later covers or reimburses it.
The delegation persists
Despite descriptions of EOAs “temporarily becoming smart accounts,” EIP-7702 does not automatically remove the delegation when the first transaction ends. The pointer normally remains until the account signs a new authorization to replace it or clear it. Clearing the pointer also does not reverse actions already taken by the delegated code, such as token transfers or changes to account storage.
How it relates to ERC-4337
EIP-7702 and ERC-4337 both support account-abstraction features, but they work differently. ERC-4337 uses smart-contract accounts, UserOperations, bundlers, and an EntryPoint contract. EIP-7702 adds a protocol-level authorization that lets an existing EOA delegate its code while keeping the same address. The approaches can be complementary; EIP-7702 is not a replacement for every ERC-4337 design, nor does it make all EOAs identical to full-featured smart accounts.
Security considerations
A delegation can be powerful because code runs with the EOA’s account context. A malicious or flawed delegate can expose assets or account permissions, and the persistent pointer can affect later calls to the address. Do not sign an authorization unless the wallet clearly identifies the delegate and you understand what it can do. Treat a delegation as an ongoing account setting, not as a one-transaction permission. Review how the wallet lets you inspect, replace, or clear it.
The EIP also discusses implementation risks such as unsafe initialization, storage collisions when changing delegate contracts, replay protection, and relayer behavior. EIP-7702 provides a mechanism; it does not certify a wallet, delegate contract, or sponsored-transaction service as safe.
Social Media Sentiment
In a May 2026 r/ethereum discussion, one commenter described using EIP-7702 to batch several approval revocations as convenient, while also saying the resulting transaction was harder to inspect and that they were not yet comfortable using it with a hardware wallet. Replies discussed uneven wallet support. This is a small, anecdotal sample; it does not establish broad user sentiment or current adoption.
Last updated: 2026-10
Related Terms
See Also
- Why Calling It a “Wallet” May Have Been Crypto’s Biggest Mistake
- Why Smart Contract Audits Fail: What Post-Mortems Reveal About Security Reviews
- What Is MEV—and Why Every Ethereum Transaction Is a Game
- Swap crypto with ChangeNOW
Sources
- EIP-7702: Set Code for EOAs — The proposal’s transaction and authorization rules, persistence behavior, and security considerations.
- Ethereum.org: Pectra network upgrade — Confirms the mainnet activation date and describes the EOA account-code feature.
- ERC-4337: Account Abstraction Using Alt Mempool — Defines the UserOperation, bundler, EntryPoint, and smart-contract-account model for comparison.