EIP-7702 lets a regular Ethereum address delegate its execution behavior to smart-contract code without moving assets to a new wallet address. Activated with the Pectra upgrade in May 2026, it can support batched actions, sponsored gas, session permissions, and recovery-oriented wallet designs. The same power makes an unfamiliar delegation signature exceptionally dangerous.
Quick answer: EIP-7702 adds a new transaction type through which an externally owned account (EOA) authorizes a pointer to deployed code. The address and private key remain, but calls to the account can follow the delegated logic. Only use wallet-managed implementations you have verified; malicious delegated code may control every asset at the address.
EOAs and smart-contract accounts
Historically, most Ethereum users operated an EOA controlled by one private key. Its validation rules were fixed by the protocol: a valid transaction required the key’s signature, a nonce, and ETH for gas. Smart-contract accounts can implement richer rules, but they usually require deployment and a different address.
EIP-7702 creates a hybrid path. An EOA signs an authorization that points the account to code already deployed on-chain. Ethereum then treats the account as having a small code designator that delegates execution to that implementation.
The private key does not disappear. Ethereum.org specifically notes that the key retains full control after delegation. Delegating to multisig-style code therefore does not, by itself, eliminate the original single-key authority.
How an EIP-7702 authorization works
The new type-4 transaction contains an authorization list. At a high level, an authorization includes:
- a chain ID;
- the address of deployed delegation code;
- an account nonce to prevent replay; and
- a signature from the EOA being authorized.
The chain ID can bind an authorization to one chain. A value of zero can make it valid across chain IDs, which deserves extra caution. The account owner can reset a delegation by delegating to the null address, but removal is not automatic simply because one dApp session ends.
Users should not need to understand raw authorization tuples in normal use. A secure wallet should clearly explain the delegation target and requested capability.
What EIP-7702 can enable
Transaction batching
A wallet can combine related actions, such as approving a token and using it, into one user flow. Atomic batching can prevent a half-completed sequence in which the approval succeeds but the intended action does not.
Sponsored gas and alternative fee payment
Relayers and paymasters can sponsor a transaction or accept a fee arrangement involving another token. This can reduce the need for a new user to acquire a small amount of ETH before interacting. Sponsorship still has a cost and introduces infrastructure and policy dependencies.
Session keys and limited permissions
Delegated account logic can authorize a temporary key for a limited action, amount, app, or time. That can improve games and repeated interactions by avoiding a primary-key signature for every click. Security depends on the implementation correctly enforcing those limits.
Recovery and modular validation
Wallet software can build recovery or alternative-signature modules around delegated code. However, because the EOA’s original private key retains protocol-level control, users must understand whether a feature is true protection against key loss, an application-layer convenience, or both.
EIP-7702 and ERC-4337
EIP-7702 is a protocol feature for attaching delegated behavior to an EOA. ERC-4337 is an account-abstraction system built around UserOperation objects, bundlers, an EntryPoint contract, and optional paymasters. They can work together.
Ethereum’s implementation guidance recommends compatibility with ERC-4337 infrastructure where appropriate. A wallet might use EIP-7702 to make an existing address programmable and use ERC-4337 bundlers to relay operations or sponsor gas.
The main security risks
Malicious delegation
Delegation code effectively becomes an extension of the account. If it contains malicious logic, an attacker may be able to transfer tokens and NFTs. Treat a delegation authorization as a high-impact security decision, not as a routine login signature.
Upgradeable implementation risk
If the delegated target or its dependencies can be upgraded, the behavior users reviewed today may change later. Proxy patterns can provide maintenance and modularity but add trust in upgrade administrators. Immutable code reduces that form of change risk but cannot be patched if a flaw is found. Wallets must make the trade-off explicit.
Initialization attacks
Delegated account logic may require initial settings. If initialization is not bound to the user’s signed parameters, another party could try to initialize the account first or alter critical configuration. The official guidance discusses signature-bound initialization and restricted EntryPoint calls as mitigations for developers.
Storage collisions
Changing delegated implementations does not automatically erase account storage. New code may interpret an old storage slot differently, producing unexpected behavior. This is a design and upgrade risk that users cannot easily inspect from a wallet prompt.
Cross-chain replay and address assumptions
A broadly scoped authorization can create risk on multiple EVM chains, especially if code at the same address differs. Smart-contract developers must also stop assuming that tx.origin always represents a code-free EOA, because an EOA can now execute delegated code.
A user safety checklist
- Keep wallet software current. Old interfaces may display new authorization types poorly.
- Let the wallet manage delegation. Ethereum.org notes that dApps should use standardized wallet interfaces rather than asking users for arbitrary raw EIP-7702 authorizations.
- Verify the target contract. Compare the exact address with the wallet vendor’s official documentation.
- Check chain scope. Understand whether authorization is limited to one chain.
- Read every capability. Batching, spending, session, recovery, and upgrade permissions are not equivalent.
- Reject urgency. Airdrop or support messages that demand immediate delegation are common phishing patterns.
- Use hardware-wallet safeguards. Official guidance recommends that hardware wallets avoid exposing arbitrary delegation and carefully review supported contracts.
- Know how to remove delegation. Follow the wallet’s official process and verify the account code on-chain afterward.
For a general introduction to the network, read our Ethereum guide. EIP-7702 does not replace basic allowance hygiene; continue to review token approvals after dApp use.
Frequently asked questions
Does EIP-7702 change my Ethereum address?
No. The existing address delegates behavior to code. Assets can remain at the same address.
Does delegation remove control from the private key?
No. The EOA key retains control at the protocol level. Wallet-specific logic can add policies, but users should not assume it converts the address into a pure multisig.
Is an EIP-7702 delegation permanent?
It persists until changed or reset; it is not removed by disconnecting a website. The account can delegate again, including to the null address to reset the pointer.
Is EIP-7702 the same as ERC-4337?
No. They are different mechanisms that can be combined. EIP-7702 is a protocol-level delegation feature; ERC-4337 defines higher-layer account-abstraction infrastructure.
This article reflects public Ethereum documentation reviewed on 31 July 2026. Wallet implementations differ, and smart-account code can contain critical risks.