EIP-7702 is an account functionality improvement introduced in Ethereum's Pectra upgrade. It allows Externally Owned Accounts (EOAs) to execute smart contract code through a delegation mechanism while retaining their existing addresses and private-key control. This enables traditional wallets to access certain smart account features, such as batching transactions, having a third party pay Gas, and managing permissions more precisely through specific contracts.
However, expanding an account's execution capabilities also changes the wallet's security boundary. In the past, users typically focused on private-key leaks, malicious token approvals, and phishing transfers. In an EIP-7702 environment, a single unsafe delegation signature could change how the wallet executes subsequent transactions. Even if users do not initiate ordinary transfers themselves, attackers may still use malicious delegation contracts to transfer assets automatically. This article explains EIP-7702's technical mechanism, the attack paths associated with malicious delegations, and how to investigate and respond after a wallet experiences unauthorized transfers.
Key Takeaways
-
EIP-7702 allows ordinary wallets to delegate execution logic to smart contracts. Users can access features such as batched transactions, Gas sponsorship, and permission management without changing their existing wallet addresses, but this also introduces new smart contract security risks.
-
Malicious delegation differs from ordinary token approval. Attackers may use phishing signatures to make a wallet address execute malicious contract logic and transfer ETH, ERC-20 tokens, or other assets.
-
Automatic transfers do not necessarily mean that the private key has been compromised. A malicious delegation may give attackers execution permissions, but a private-key leak may also occur at the same time. These possibilities must be investigated separately.
-
Revoking a malicious delegation and revoking an ERC-20 approval are two different operations. An EIP-7702 delegation can be cleared through a new valid authorization, but ordinary token approval management tools may not support this operation.
-
The key to wallet recovery is identifying the source of control. If only a malicious delegation exists and the private key remains secure, clearing the delegation may prevent further exploitation. If the private key or seed phrase has been compromised, assets should be moved to a completely new wallet as a priority.
What Is EIP-7702? Why Can Ordinary Wallets Execute Smart Contracts?
Ethereum accounts mainly include Externally Owned Accounts (EOAs) and smart contract accounts. Traditional EOAs are controlled by private keys and typically initiate transactions through signatures, while smart contract accounts can execute more complex logic based on prewritten programs. Each account type has its own characteristics: EOAs are simple to use but lack native support for complex permission management, while smart contract accounts are flexible but usually require additional deployment and management.
EIP-7702 introduces a new transaction type and authorization mechanism that allows an EOA to point to already deployed smart contract code. Once the delegation takes effect, relevant operations executed for that account can use the target contract's logic, while the account itself retains its original address and private key. This means users can access smart account features without moving all their assets to a new address.
Normal uses of this design include completing multiple operations at once, reducing the complexity of managing Gas, and providing a more flexible transaction experience through restricted sub-permissions. However, the delegation contract participates in the account's execution process. If its code contains vulnerabilities, its permission design is inappropriate, or the user delegates directly to a malicious contract, the wallet may face risks beyond the scope of ordinary token approvals.
How Can a Malicious Delegation Automatically Transfer Assets From a Wallet?
The core risk of EIP-7702 is that a user may sign authorization for an account to use a smart contract's execution logic rather than signing only a specific transaction. Attackers may use fake wallet upgrade pages, airdrop claim portals, or security verification prompts to trick users into signing delegation authorizations. Once the authorization is submitted and takes effect on-chain, the wallet address may operate according to the rules defined by the malicious contract.
For example, a user may intend only to claim a reward but delegate their wallet to a contract controlled by an attacker during the signing process. The malicious contract may contain asset transfer, permission bypass, or automatic sweeping logic. When the attacker later triggers the relevant call, the contract may use the account's execution permissions to transfer assets. In some designs, the attacker may even wait for the wallet to receive new ETH and then transfer it through a subsequent transaction, causing the victim to believe that the wallet contains an automatic deduction mechanism that cannot be removed.
It is important to note that EIP-7702 does not write arbitrary code directly into a wallet, nor does every delegation automatically transfer assets. The protocol records a delegation indicator that points to a target contract. Whether funds can be transferred depends on the target contract's code, initialization state, execution permissions, and trigger conditions. Malicious delegations are dangerous because they may give an untrusted program control over the account's actual execution capabilities, while users may not be able to understand this change from an ordinary signing interface.
How Does an EIP-7702 Malicious Delegation Differ From an ERC-20 Unlimited Approval?
A traditional ERC-20 approval generally allows a specified address or contract to use a certain token up to a specified amount. For example, when trading on a decentralized exchange, a user may authorize a router contract to spend some USDT. If the approval amount is too large and the approved contract is compromised, the user's corresponding tokens may be transferred. However, this type of approval generally concerns a specific token contract and approval amount.
An EIP-7702 delegation applies to an account's execution logic. It does not merely allow a contract to spend one type of token. It may change how the account handles calls, verifies permissions, and executes multiple operations. If a malicious contract lacks appropriate permission controls, it may affect ETH, tokens, and other on-chain assets. Therefore, an EIP-7702 malicious delegation should not be treated simply as another type of unlimited approval.
| Comparison Dimension |
ERC-20 Token Approval |
EIP-7702 Delegation |
| Primary function |
Allows a specified address to use tokens |
Allows an EOA to use a specified contract's execution logic |
| Main scope of impact |
Specific tokens and the approval amount |
Depends on the delegation contract and may involve the entire account |
| Common risk |
A malicious contract calls token transfers |
Malicious code gains account execution capabilities |
| How to handle it |
Adjust or revoke the token approval |
Clear or replace the account delegation |
| Does the private key still control the account? |
Yes |
Yes, but the delegated code may also execute operations |
The two may also exist at the same time. A wallet may retain dangerous ERC-20 approvals while also being affected by an EIP-7702 malicious delegation. Therefore, after an unauthorized transfer, users should not check only token approval records. They must also confirm whether the wallet address currently has delegated code.
Why Can ETH Be Transferred Automatically Soon After It Reaches a Wallet?
A rapid transfer after a wallet receives ETH does not necessarily mean that an attacker is manually operating the wallet in real time. A malicious delegation contract can work with an automated monitoring program, allowing the attacker to submit a subsequent transaction as soon as funds are detected at the target address. For a wallet that already has malicious execution permissions, the attacker can automate monitoring, triggering, and transfers, creating an ongoing asset-sweeping process.
This attack resembles a traditional private-key-leak Sweeper, but the control path is not exactly the same. A traditional Sweeper generally relies on a leaked private key to sign transactions, while an EIP-7702 malicious delegation may transfer assets through already active contract execution permissions. Both situations may appear as funds being transferred shortly after they arrive. Therefore, transaction speed alone cannot determine whether the attacker possesses the private key.
Some malicious delegations may also involve multiple EVM-compatible chains. EIP-7702 authorizations include a chain ID, which is generally used to limit the scope of an authorization. However, an authorization with a chain ID of 0 may apply across chains. This means that an unsafe authorization signed on one network may create risks on other eligible networks. After detecting an unauthorized transfer, users should check the delegation status of the relevant address on other EVM networks instead of checking only the chain where the initial loss occurred.
How Can You Determine Whether a Wallet Has an EIP-7702 Malicious Delegation?
To determine whether a wallet is affected by a malicious delegation, first distinguish ordinary transfers, token approvals, and account delegations. EIP-7702 introduces Type 4 transactions, which may contain an authorization list. Users can use a block explorer or wallet security tool that supports EIP-7702 to check the authorization information in relevant transactions and whether the account currently points to a delegation contract.
If an EIP-7702 delegation has been set for a wallet address, its account code will generally contain a specific delegation indicator pointing to the target contract address. However, this does not mean that the delegation is necessarily malicious, because legitimate smart wallet features may also use EIP-7702. For further assessment, users should check whether the target contract is an implementation recognized by the wallet provider, whether its code has been verified, whether it contains unusual asset transfer logic, and whether the delegation occurred around the same time as a suspicious signature or asset loss.
Users can also examine how the unauthorized transactions were triggered. Did assets leave the wallet without any action from the user? Did an unfamiliar address repeatedly call the wallet? Did funds continue to flow to the same receiving address? If any of these conditions apply, save the transaction hashes, authorization records, target contract addresses, and fund flow information. However, a single unauthorized transaction is not enough to conclusively determine that the attack came from EIP-7702. Private-key leaks, malicious token approvals, and other smart contract risks must also be investigated.
How Should You Revoke a Malicious Wallet Delegation?
After discovering a suspicious delegation, first stop using the wallet for new high-risk operations. Do not transfer additional assets into it, and do not continue signing transactions from unfamiliar websites. Then use a trusted wallet client or security tool to check the current delegation status and confirm whether an unfamiliar target contract exists. If the wallet you use does not yet provide a way to clear an EIP-7702 delegation, do not casually visit unfamiliar websites offering a supposed "one-click fix." These services may themselves trick you into signing another malicious authorization.
Under the protocol mechanism, EIP-7702 allows an account to set the delegation target to the zero address through a new valid authorization, thereby clearing the current delegation indicator. Users can also replace the delegation with another implementation through a valid authorization. However, for an ordinary wallet that has already been attacked, restoring a clear and trusted account execution state is generally easier for assessing risk. Note that revoking an ERC-20 approval does not revoke an EIP-7702 delegation. These operations must be handled separately.
Whether the operation succeeds also depends on whether the user still securely controls the private key and whether the transaction that clears the delegation can be successfully included on-chain. If the attacker also has the private key, they may sign another malicious delegation or transfer assets directly. For wallets affected by an automated Sweeper, an ordinary revocation transaction may also face transaction competition and the risk of having its Gas funds transferred away. In this situation, do not repeatedly fund the compromised address and attempt additional transactions. Instead, consider seeking trusted professional security support and take appropriate protective measures after fully assessing the risks.
Is a Wallet Safe After a Malicious Delegation Is Revoked?
Clearing a malicious delegation can remove the account's current delegated execution path, but it does not mean that all wallet security risks have disappeared. If the attacker obtained only a delegation authorization through phishing while the user's private key and seed phrase remain secure, clearing the delegation may prevent the malicious contract from continuing to execute operations through the original path. However, users must still check for other token approvals, malicious signatures, unresolved permission settings, or compromised account information.
If the attacker has obtained the private key or seed phrase, the original wallet should not be considered safe even if the user successfully clears the delegation. The attacker may still use the private key to initiate ordinary transfers or sign a new EIP-7702 authorization. In this situation, the more reliable approach is to create a wallet controlled by a completely new seed phrase and move any remaining assets when it is safe to do so. Simply changing wallet applications, deleting browser extensions, or importing the original seed phrase again will not resolve an existing private-key compromise.
In addition, clearing a delegation generally cannot reverse completed on-chain transactions or automatically recover stolen assets. Asset recovery may still require on-chain tracing, cooperation from exchanges, proof of ownership, and legal procedures. Users should treat preventing further losses and recovering historical losses as two separate goals. They should not assume that funds already transferred out will automatically return after the wallet appears to be functioning normally again.
How Can Ordinary Users Reduce the Risk of EIP-7702 Malicious Delegations?
The security risks of EIP-7702 do not mean that users must completely avoid smart account features. A properly designed delegation mechanism can improve the wallet experience by reducing repeated signatures, supporting batched transactions, and enabling restricted transaction permissions. The key considerations are whether users can identify the authorization target, understand the scope of its permissions, and confirm that the delegation contract is trustworthy.
For everyday use, prioritize enabling smart account features through the wallet client itself. Do not casually sign an unfamiliar delegation authorization because of an airdrop, points claim, or supposed account upgrade. When a prompt involves EIP-7702, Set Code, Delegate, or similar permission changes, check the target contract address, applicable network, and authorization content. If you cannot verify the source of a contract, do not treat it as risk-free even if the page says that the transaction does not require Gas.
Users who hold significant assets may also adopt a layered fund management approach by separating long-term holdings from frequently used trading wallets. A daily-use wallet can be used for DeFi, application testing, and trying new protocols, while long-term assets should preferably be stored in an environment with simpler permissions and lower usage frequency. Regularly checking account delegations, token approvals, and unauthorized transaction records can also help identify the source of a security issue more quickly.
What New Wallet Security Issues Does EIP-7702 Expose?
EIP-7702 changes the traditional assumption that "private-key signatures control transactions" in wallets. Users still hold the private key, but the account can execute external contract code through a delegation. As a result, wallet security now extends beyond protecting the private key to protecting the delegation target, execution logic, and permission configuration. For ordinary users, the consequences of signing an authorization can no longer be assessed solely by whether it transfers funds or approves a particular token.
Security research in 2026 identified multiple malicious delegation patterns related to EIP-7702, including obtaining authorizations through phishing, continuously transferring assets through malicious Sweeper contracts, and expanding the attack scope through cross-chain authorizations. Related research also found that some affected accounts did not clear malicious delegations promptly, indicating that the resulting risk may continue after the initial asset loss. However, the number of malicious delegations identified in research, the number of affected accounts, and the actual financial losses should not be treated as equivalent. These figures must be understood separately.
In the future, wallet providers will need to display delegation contracts and their permission scopes more clearly and prevent untrusted websites from directly inducing users to make high-risk delegations. Block explorers, security detection tools, and smart account infrastructure will also need to improve their ability to identify EIP-7702 activity. For users, the most important change is to treat a delegation signature as a high-risk operation that may affect the execution permissions of the entire wallet, rather than as an ordinary website connection request.
Summary
EIP-7702 gives traditional Ethereum wallets more flexible smart contract execution capabilities, making batched transactions, Gas sponsorship, and fine-grained permission management possible. However, the same mechanism may also be exploited by attackers to change a wallet's execution logic through a malicious delegation, resulting in automatic transfers, ongoing asset sweeping, and cross-chain security risks.
When a wallet experiences unauthorized transfers, users should check its EIP-7702 delegations, ERC-20 approvals, and private-key security status. If a malicious delegation is confirmed, use a trusted tool to clear or replace it and assess whether assets should be moved to a completely new wallet. Revoking a delegation may help prevent a specific execution path from being exploited further, but it cannot guarantee that the private key is secure or automatically recover assets that have already been transferred.
FAQ
Does an EIP-7702 Malicious Delegation Mean That the Wallet's Private Key Has Been Stolen?
Not necessarily. Attackers may use phishing to trick users into signing a delegation authorization and then use a malicious contract to execute transactions without directly obtaining the private key. However, if the private key has been compromised, attackers may also use EIP-7702 to expand their attack capabilities. These possibilities must be investigated separately.
Why Can Assets Be Transferred Even When the Wallet Did Not Initiate a Transfer?
A malicious delegation may cause the account to execute operations according to contract logic controlled by the attacker. The attacker can trigger transfers through subsequent calls, so assets may be lost even when the user did not initiate an ordinary transfer.
How Can an EIP-7702 Delegation Be Canceled?
EIP-7702 supports setting the delegation target to the zero address through a new valid authorization, thereby clearing the delegation. The operation should be completed through a trusted wallet or security tool that supports this feature. Do not submit your private key or seed phrase to an unfamiliar website.
Not necessarily. Ordinary Revoke tools are generally used to manage ERC-20 and other token approvals, while an EIP-7702 delegation concerns account execution permissions. Unless the tool explicitly supports EIP-7702 delegation management, revoking token approvals cannot replace clearing the malicious delegation.
Is It Necessary to Change Wallets After Clearing a Malicious Delegation?
It depends on the source of the risk. If the private key remains secure and the malicious delegation has been effectively cleared, the original wallet may return to a normal execution state. However, if the private key or seed phrase has been compromised, use a newly generated wallet and transfer the remaining assets when it is safe to do so.
Can an EIP-7702 Delegation Affect Other EVM Networks?
It can. The chain ID in an authorization can restrict the applicable networks, but an authorization with a chain ID of 0 may be used across multiple compatible networks. After discovering a malicious delegation, check the status of the relevant address on other EVM networks.
