EIP-7702 is an important protocol improvement in the development of Ethereum account abstraction. It allows traditional EOA wallets to delegate smart contract execution logic through authorization, enabling ordinary addresses to support batch transactions, gas sponsorship, and more flexible account management. Unlike creating an entirely new smart contract wallet, EIP-7702 preserves users' existing wallet addresses and assets while changing how the account executes transactions.
However, expanding account capabilities also changes the security boundary. In the past, users mainly focused on whether their private keys had been exposed, whether token Approve permissions were set too high, and whether transaction signatures contained abnormal transfers. EIP-7702 introduces another type of operation that users need to understand: through a single authorization, users may allow their address to execute specified contract code in subsequent transactions. If that code is malicious or the delegation is controlled by an attacker, asset risks may extend beyond a single transaction.
Therefore, understanding EIP-7702 requires more than focusing on the account abstraction experience it provides. It is also necessary to analyze how delegation authorization takes effect, what operations malicious code can perform, and how ordinary users can identify and remove dangerous delegations. This article discusses the technical principles, potential attack paths, and wallet security practices related to EIP-7702.
Key Points
-
EIP-7702 is an account feature introduced with Ethereum's Pectra upgrade. It allows traditional externally owned accounts (EOAs) to execute smart contract logic through delegation without requiring assets to be transferred to a new address.
-
EIP-7702 authorization differs from ordinary ERC-20 Approve. The former may change an account's execution logic, while the latter generally grants a specific spender permission to use a certain amount of tokens.
-
The risk of a malicious delegation does not necessarily result from private key exposure. Even if users retain their private keys, signing a dangerous delegation authorization may put their assets at risk.
-
An EIP-7702 delegation does not automatically expire after a single transaction is completed. Revoking or replacing a delegation requires a new valid authorization, and clearing a delegation cannot recover assets that have already been transferred.
-
Assessing EIP-7702 security requires more than checking the source of a signature. It also requires understanding the permissions, code behavior, and upgrade capabilities of the delegated contract.
What Is EIP-7702? Why Do Traditional EOA Wallets Need Delegated Execution?
Ethereum accounts are primarily divided into externally owned accounts (Externally Owned Accounts, or EOAs) and smart contract accounts. EOAs are controlled by private keys and can initiate transactions. Smart contract accounts execute operations according to deployed code and can support more complex permission controls and transaction logic.
Traditional EOAs offer a simple structure and broad compatibility, but their execution capabilities are limited. For example, users may need to sign multiple transactions separately to complete a set of on-chain operations, or hold ETH themselves to pay network gas fees. Smart contract wallets can improve these experiences, but they often involve deploying a new account, migrating assets, and meeting additional compatibility requirements.
EIP-7702 provides a different solution: it allows an EOA to delegate account code execution to smart contract logic at a specified address through authorization. Users can access some smart account features from their existing wallet address without changing it.
At the protocol level, EIP-7702 introduces a new transaction type and an authorization list. An eligible authorization can set an EOA's code field to a special delegation indicator pointing to a specified contract address. When another transaction calls that account, Ethereum executes the delegated code according to the relevant rules.
This design gives wallet products greater flexibility to support batch operations, flexible transaction validation, gas sponsorship, and contract-based permission management. However, EIP-7702 itself does not automatically provide all of these capabilities. The specific functionality still depends on how the delegated contract is implemented.
How Does EIP-7702 Work? What Is the Relationship Between the Authorization Signature and the Delegated Contract?
The core idea of EIP-7702 is to separate account ownership from code execution logic. Users continue to control their EOAs through their existing private keys, but can use a protocol-compliant authorization to specify which contract code the address should use.
Authorization data typically includes the chain ID, delegation target address, account nonce, and a signature generated by the account's private key. When the network processes a transaction containing an authorization list, it verifies the authorization and updates the delegation status of the corresponding account according to the protocol rules.
A typical EIP-7702 delegation process consists of four stages:
-
Select the delegation target: The wallet or application determines the smart contract implementation address it needs to use.
-
Generate the authorization signature: The user signs authorization data for the specified delegation target with the EOA's private key.
-
Process the authorization on-chain: The authorization is included in a transaction that supports EIP-7702. After verification, the network sets the account's delegation indicator.
-
Execute the delegated code: When the account is called subsequently, the code of the specified implementation contract is executed according to the EIP-7702 rules.
Two easily confused concepts need to be distinguished here: an authorization signature is not exactly the same as an ordinary transaction signature. An ordinary transfer signature is generally used to approve a specific transaction, while an EIP-7702 authorization sets the code implementation used by an account. It may affect the execution behavior of multiple subsequent transactions.
The delegation target address does not mean that the user has given their private key to that address, nor does it mean that the owner of that address automatically obtains permission to transfer assets. The actual risk depends on how the delegated code handles transaction validation, execution entry points, and access control. If the code allows an attacker to perform asset operations without further authorization from the account owner, a dangerous delegation could become an entry point for asset theft.
How Does EIP-7702 Differ from ERC-20 Approve?
In traditional DeFi transactions, users often use ERC-20 Approve to authorize a decentralized exchange or another smart contract to use a specific token. For example, a user may allow a contract to spend up to 100 USDC. This authorization is generally recorded by the token contract and controls how many tokens a specific spender can use.
EIP-7702 operates at a different authorization level. It does not simply approve a contract to spend a specific amount of tokens. Instead, it specifies which smart contract code the account executes. The delegated code may include transaction validation, asset transfers, batch calls, and other account management functions, so its potential scope of impact may be broader.
| Comparison Dimension |
ERC-20 Approve |
EIP-7702 Delegation |
| Primary function |
Authorizes a spender to use tokens |
Specifies the contract code executed by the account |
| Permission scope |
Specific token and allowance amount |
Depends on the implementation of the delegated code |
| Authorized party |
Spender address |
Delegated implementation contract address |
| Does it affect account execution logic? |
Usually no |
Yes |
| How is it revoked? |
Adjust or clear the token allowance |
Replace or clear the delegation through a valid authorization |
| Primary risk |
The token allowance may be misused |
Malicious code may affect the account's assets and operations |
An EIP-7702 delegation does not mean that wallet ownership is directly transferred to a contract. A secure delegation implementation can still require a valid signature from the account owner and impose transaction limits, time restrictions, and other protective measures.
However, if a user authorizes a malicious contract, its internal logic may allow an attacker to perform operations that the user did not intend to approve. Therefore, compared with ordinary Approve authorizations, EIP-7702 security checks need to focus more closely on the contract code itself, rather than only on the authorization amount.
How Can a Malicious EIP-7702 Authorization Lead to Wallet Asset Theft?
One of the primary security risks of EIP-7702 is that attackers may use signature phishing to trick users into approving malicious delegations. Attackers may present an authorization request as a wallet upgrade, account verification, reward claim, or transaction optimization, causing users to believe they are completing an ordinary signature.
Once a user signs a valid authorization pointing to a malicious contract, the attacker may submit it on-chain. It is important to note that the authorization signature itself does not necessarily change the account state immediately. The delegation takes effect on-chain only after the relevant authorization is included in a valid transaction and passes verification.
If the delegated code includes an asset transfer function that an attacker can call, the attacker may use that execution logic to transfer ETH or other tokens from the account.
A typical risk path can be summarized as follows:
-
Induce a signature: The attacker obtains the user's authorization for a malicious delegation target through a fake website or application interface.
-
Submit the authorization: The attacker or another transaction sender submits the valid authorization to a network that supports EIP-7702.
-
Set the delegation: After verifying the authorization, the network causes the affected account to execute the specified contract code.
-
Trigger malicious logic: The attacker calls an exploitable execution entry point in the malicious code.
-
Transfer assets: The malicious logic performs transfers, token operations, or other dangerous actions in the account's context.
The danger of this type of attack is that users may see only a single signature request without realizing that it can change how the account executes subsequent transactions.
On October 30, 2026, a major security incident occurred involving Binance-related hot wallets. TRM Labs' incident analysis concluded that attackers used EIP-7702 delegation on the Ethereum network to connect the relevant hot wallets to malicious execution code. It also observed abnormal fund transfers on other blockchains. Different security analyses still contain details about the scale of the attack, how signatures were obtained, and the initial intrusion path that require further verification.
This incident shows that EIP-7702 can serve as infrastructure for normal wallet automation, but may also amplify the consequences of a loss of control over authorization or signature systems. However, it does not establish that the EIP-7702 protocol itself contains a vulnerability that allows arbitrary attackers to bypass signature verification.
Why Can Attackers Transfer Assets Even When the User's Private Key Has Not Been Exposed?
Traditional wallet security education typically emphasizes protecting seed phrases and private keys because an attacker who obtains a private key can forge a valid signature from the account owner. However, in smart contract interaction scenarios, the absence of private key exposure does not guarantee that assets are safe.
The reason is that users may voluntarily sign authorizations with dangerous consequences. For EIP-7702, an attacker does not necessarily need to obtain the private key directly. If the attacker can induce the user to sign a valid malicious delegation authorization and satisfy the conditions for on-chain execution, they may be able to influence the account's subsequent behavior.
This risk is similar to traditional signature phishing, but the target has expanded from a single transaction or a specific token allowance to the account's execution logic.
Attackers may also target the signing systems, permission approval processes, or operating terminals of enterprise wallets. If a signing system is tricked into generating a valid authorization that does not match the intended business purpose, serious consequences may result even if the underlying private key has not been directly exposed.
Therefore, wallet security cannot rely solely on private key protection. The signing process itself must also be protected. Users need to know whether they are signing an ordinary transfer, a token authorization, or a code delegation that may affect account behavior over an extended period.
For institutional wallets, signing policies, contract allowlists, multi-party approvals, and transaction simulation also need to cover EIP-7702 authorizations rather than relying only on traditional transfer amount checks.
Does an EIP-7702 Delegation Expire Automatically? How Can Risky Authorizations Be Checked and Revoked?
One important characteristic of EIP-7702 is that the delegation state is not automatically cleared when the transaction that sets it is completed.
Once an account successfully sets a delegation, the relevant code indicator generally remains in place until a new valid authorization replaces or clears it. This means that the delegation may remain active even after the user closes the website, disconnects the wallet, or completes the original transaction.
At the protocol level, users can use a new valid authorization to set the delegation target to the zero address, thereby clearing the EIP-7702 delegation indicator. Users can also reauthorize a trusted implementation contract when appropriate.
The following steps can be used to check and manage a delegation:
-
Query the account's code status: Use a trusted block explorer or wallet security tool to confirm whether the address has an EIP-7702 delegation.
-
Verify the target contract: Check whether the delegation points to the same implementation contract published by the wallet product being used.
-
Assess contract risk: Check whether the code has been audited, whether it has administrator privileges, whether it can be upgraded, and whether it allows third parties to perform asset operations.
-
Clear an abnormal delegation: After confirming the process and network conditions, use a trusted tool to submit a new valid authorization to clear or replace the dangerous delegation.
-
Check related risks: Also check ERC-20 allowances, abnormal transaction records, and the account's status on other chains.
When querying the code of an account with an EIP-7702 delegation, users may see a special indicator beginning with 0xef0100, followed by the delegation target address. This is one protocol-level identification method. However, ordinary users do not need to parse raw hexadecimal data themselves. They can use a trusted tool that correctly displays EIP-7702 status.
It is important to note that revoking a delegation does not restore assets or guarantee that the account is completely secure. If the private key, signing device, or operating environment has already been compromised, clearing the delegation alone may not be sufficient. For a suspected compromised account, consider stopping use of the relevant signing environment and, after ensuring that it is safe to do so, moving the remaining assets.
How Does the EIP-7702 Security Model Differ from ERC-4337 Smart Accounts?
EIP-7702 and ERC-4337 are both related to Ethereum account abstraction, but they address the problem in different ways.
ERC-4337 uses components such as UserOperation, Bundler, and EntryPoint to provide a transaction execution framework for smart contract accounts without relying on traditional EOAs to directly initiate every operation. The account's validation and execution rules are implemented by smart contracts.
EIP-7702 primarily addresses how traditional EOAs can obtain smart contract execution capabilities. It allows existing addresses to delegate contract code execution, lowering the barrier for users who want to adopt smart account functionality.
| Comparison Dimension |
EIP-7702 |
ERC-4337 |
| Primary goal |
Add code execution capabilities to existing EOAs |
Provide an operational framework for smart contract accounts |
| Account form |
Retains the existing EOA address |
Typically uses a smart contract account |
| Core mechanism |
Protocol-level delegation authorization |
UserOperation and EntryPoint |
| Security focus |
Delegation target and authorization signature |
Account validation logic and execution permissions |
| Relationship between the two |
Can be used together |
Can integrate with EIP-7702 |
The two are not complete substitutes for each other. Some wallet architectures can use EIP-7702 to provide code execution capabilities to existing EOAs and then combine it with ERC-4337 infrastructure to deliver a richer smart account experience.
From a security perspective, EIP-7702 requires a focus on malicious delegations and signature deception. ERC-4337 requires attention to account contract validation logic, execution modules, upgrade permissions, and related infrastructure risks. Actual security depends on the specific implementation rather than simply on which standard is adopted.
How Can Ordinary Users Protect Against EIP-7702 Signature Phishing?
For ordinary users, the key to managing EIP-7702 risks is not to avoid smart account functionality entirely, but to recognize the permission changes represented by different signatures.
-
Users should distinguish between transaction signatures, message signatures, token authorizations, and account delegations. If the wallet interface displays EIP-7702, Delegation, Set Code, or a similar prompt, confirm that the operation truly needs to change the account's execution logic.
-
Pay particular attention to the delegation target address. A normal wallet feature upgrade may require setting a verified smart account implementation contract, but users should remain cautious when an unfamiliar website asks them to delegate to an unknown address. Even if a contract's source code is publicly available, that does not necessarily mean its permission design is secure.
-
Do not judge the credibility of an authorization request solely by the website name, interface design, or social media link. Attackers may use fake wallet update pages, search advertisements, or compromised frontend pages to trick users into signing.
-
Use wallet tools that clearly display authorization content and provide transaction simulation and risk alerts whenever possible. If a signing device can display only raw data that the user cannot understand, avoid blindly signing before verifying the content.
-
Consider account segregation based on asset size and usage scenarios. Keeping long-term holdings separate from wallets used for frequent DeFi interactions, airdrops, or new applications can reduce the potential impact of a single malicious authorization to some extent.
It is important to note that hardware wallets can improve private key protection, but they cannot automatically determine whether a delegation that the user actively approves is safe. Secure signing still requires reliable information display and informed user judgment.
What Does EIP-7702 Mean for the Future of Wallet Security and Account Abstraction?
EIP-7702 moves Ethereum accounts from the relatively fixed execution model of EOAs toward more flexible programmable accounts. For wallet developers, this means they can provide batch transactions, gas sponsorship, permission management, and automated execution while retaining existing addresses.
However, the stronger the account's programmability, the more precise security checks need to be. In the past, wallet risk alerts focused mainly on transfer destinations, transaction amounts, and token allowance amounts. In the future, they will also need to accurately display delegation targets, contract validation rules, execution permissions, and potential long-term effects.
From a product design perspective, EIP-7702 security practices may develop in three directions.
-
Authorization transparency. Wallets need to help users understand what a delegation will change, rather than simply displaying a contract address.
-
Least privilege. Delegated contracts can reduce potential losses through strict access controls, limits, expiration periods, and multiple verification mechanisms. However, these restrictions must be reliably enforced by the actual code rather than relying only on frontend displays.
-
Continuous risk monitoring. Because delegations may remain in place for an extended period, wallet security tools need to support the detection of abnormal delegations, changes in contract code, and suspicious account operations instead of checking only at the time of the initial signature.
The significance of EIP-7702 lies not only in improving the wallet experience, but also in expanding account security beyond traditional private key protection to the integrated management of signing intent, code execution, and ongoing permissions.
Summary
EIP-7702 introduces smart contract delegation capabilities to traditional Ethereum EOAs, allowing users to access more flexible account execution functions while retaining their existing wallet addresses. This mechanism provides a new technical foundation for account abstraction, but it also changes the security boundary of traditional wallets.
Unlike ERC-20 Approve, which primarily controls token spending allowances, EIP-7702 authorization can change the contract code executed by an account. If a user signs a malicious delegation, an attacker may use unsafe execution logic to transfer assets without necessarily obtaining the user's private key directly.
Therefore, assessing whether EIP-7702 is safe requires more than checking whether the authorization was signed by the user. It also requires checking the delegation target, contract permissions, signature source, and subsequent execution behavior. As smart account functionality becomes more widely adopted, understanding code delegation and permission management will become an important part of wallet security education.
FAQ
What Is EIP-7702?
EIP-7702 is an Ethereum protocol improvement that allows traditional EOAs to delegate smart contract code execution through authorization, providing some smart account functionality.
Can EIP-7702 Automatically Drain a Wallet?
No. EIP-7702 itself is not a feature that automatically steals assets. The primary risks come from malicious authorizations, unsafe delegated code, or compromised signing systems.
Is EIP-7702 Authorization the Same as ERC-20 Approve?
No. ERC-20 Approve generally grants a specific address an allowance to use tokens, while EIP-7702 authorization specifies the contract code executed by an account. The permission levels are different.
Can an EIP-7702 Delegation Be Revoked?
Yes. The account owner can use a new valid authorization to clear or replace the delegation. However, if the private key or signing environment has been compromised, revoking the delegation alone cannot guarantee security.
Can a Hardware Wallet Prevent EIP-7702 Phishing?
Not completely. A hardware wallet helps protect the private key, but users may still face asset risks if they confirm a malicious authorization on the device.
How Can I Tell Whether a Wallet Has an EIP-7702 Delegation?
You can use a block explorer or security tool that supports EIP-7702 to query the account code and delegation target. If you find an unfamiliar delegation address, verify its source and permissions.
