Account Abstraction (AA) is an important direction for the long-term exploration of the Ethereum ecosystem, aiming to break the boundaries between external accounts (EOA) and contract accounts, making wallets more programmable, secure, and upgradable. As the most mainstream AA implementation solution, EIP-4337 has been widely used in a number of smart contract wallets based on EntryPoint (such as Safe, Stacks, Argent). However, EIP-4337 still has certain limitations in terms of on-chain nativeness, operational complexity, and ecological compatibility because it introduces an independent transaction pool and entry contract mechanism.
In order to further lower the threshold for using account abstraction and enhance its native support, Vitalik proposed EIP-7702 in 2024 and included the proposal in the Pectra upgrade. The core idea of EIP-7702 is to allow an original EOA to execute the contract code (contract_code) of the specified address when initiating a transaction, and use this code to define the execution logic of the transaction.
EIP-7702 introduces a new mechanism of transaction-level code injection, which allows user accounts to dynamically specify execution logic in each transaction instead of relying on pre-deployed contract code. This breaks the traditional permission model based on static code, brings greater flexibility, and also introduces new security challenges : contracts that originally rely on judgment logic such as isContract and extcodehash may become invalid, and some systems that assume that the caller is a pure EOA may also be bypassed. For auditors, it is necessary not only to verify the security of the injected code itself , but also to evaluate its potential impact on other contract systems in a dynamic context.
In this article, the Beosin security team will focus on the design principles and key features of EIP-7702, systematically sort out the security risks that the AA wallet built based on it may face during the audit, and propose audit processes and suggestions from a practical perspective to help security researchers better cope with the technical challenges under this new paradigm.
1. Introduction to EIP-7702
1. EIP-7702 Technical Overview
EIP-7702 introduces a new transaction type 0x 04 (SetCode), which allows EOA to authorize the contract code to be executed through this transaction. The transaction structure is as follows:
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit,
destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])
The authorization_list contains multiple authorization lists, and can also contain authorization behaviors of non-transaction initiators. The internal structure is:
authorization_list = [[chain_id, address, nonce, y_parity, r, s]]
Among them, chain_id indicates the chain where the user authorization is effective, and its value must be equal to the chain ID of the execution chain or 0. When chain_id is 0, it means that the authorization is effective for all EVM chains that support EIP-7702, but the premise is that other parameters (such as nonce) must match. Address indicates the target contract address authorized by the user.
After the authorization is completed, the system will modify the authorized users code field to 0x ef 0100 || address, where address is the authorized contract address. If you want to cancel the authorization, just initiate a SetCode transaction to set address to 0 address.
2. Advantages of EIP 7702
(1) Flexibility and customization
Abstract accounts can flexibly customize functions according to needs by writing account logic into smart contracts. For example, users can configure multi-signature, social recovery, limit control, etc. to meet the needs of different scenarios for individuals or enterprises. This design greatly improves the functional scalability of accounts and breaks through the limitations of traditional external accounts (EOA).
(2) Enhanced security
Abstract accounts provide multi-layer security mechanisms , including multi-factor authentication, transaction limits, and social recovery. Even if a user loses their private key, they can restore their account through trusted contacts or multi-factor authentication, thus avoiding permanent asset loss caused by loss of private keys in traditional accounts. At the same time, functions such as limit control can also prevent large amounts of funds from being maliciously stolen.
(3) Gas optimization
Abstract accounts support a flexible Gas abstraction mechanism, allowing users to pay Gas through a third party or even directly use other tokens to pay transaction fees. This mechanism not only reduces the users operating costs, but also further simplifies the use process of the blockchain, especially for novice users or complex multi-step transaction scenarios.
(4) Promote the popularization of Web3
By optimizing the experience and security, abstract accounts hide the complexity of blockchain from users, providing convenient operations closer to Web2. This design reduces the learning cost for ordinary users , allowing more people to participate in Web3 applications without barriers, and promoting the popularization of decentralized technology.
2. Analysis of security risks in EIP-7702 practice
Although EIP-7702 has injected new impetus into the Ethereum ecosystem and expanded its application scenarios, it has also inevitably introduced some new security risks:
1. Authorization replay attack
Under the EIP-7702 model, if the user sets the chain_id field in the authorization to 0, it means that the authorization is valid on multiple chains. Although this cross-chain universal authorization design improves flexibility in some scenarios, it also introduces obvious security risks.
It is important to note that even if the account IDs of the same address on different chains are the same, the underlying contract implementations may be completely different. This means that an attacker may deploy a malicious version of the contract on another chain and use the authorization behavior of the same address on the chain to perform unexpected operations, thereby posing risks to user assets.
Therefore, for wallet service providers or front-end interactive platforms, when users perform such authorization operations, they should clearly verify whether the chainId declared in the user authorization is consistent with the currently connected network; if it is detected that the user sets the chainId to 0, a clear risk warning should be given to remind the user that the authorization will take effect on all EVM-compatible chains and may be abused by malicious contracts.
In addition, the service provider should also evaluate whether to restrict or prohibit authorization with chainId 0 by default at the UI layer to reduce the risk of misoperation or phishing attacks.
2. Contract compatibility issues
(1) Contract callback compatibility
When transferring funds to the contract address, the existing ERC-721, ERC-777, ERC 1155 and other token contracts will call the standard callback interface (such as onERC 721 Received, tokensReceived) to complete the transfer operation. If the receiving address does not implement the corresponding interface, the transfer will fail or even cause the asset to be locked.
In EIP-7702, a user address can be assigned a contract code through the set_code operation, thereby becoming a contract account. At this time:
User addresses are considered contracts;
If the contract does not implement the necessary callback interface, the token transfer will fail;
Users may not be able to receive mainstream tokens without knowing it.
Therefore, developers should ensure that the target contract delegated by the user implements the relevant callback interface to ensure compatibility with mainstream tokens.
(2) tx.origin verification failure
In traditional contracts, tx.origin is often used to determine whether a transaction is directly initiated by the user, and is used to prevent security controls such as contract calls.
But in the EIP-7702 scenario:
The user signs the authorization transaction, which is actually broadcasted by the relayer or bundler. When the transaction is executed, tx.origin is the relayer address, not the user address.
msg.sender is the wallet contract representing the user identity.
Therefore, permission verification based on tx.origin == msg.sender will result in the rejection of legitimate user operations and lose reliability. Similarly, restrictions on contract calls such as tx.origin == user will also fail. It is recommended to abandon tx.origin as a basis for security judgment and use signature verification or authorization mechanisms instead.
(3) isContract misjudgment
Many contracts use isContract(address) (checking the address code length) to prevent the contract account from participating in certain operations, such as airdrops, snap-ups, etc.:
require(!isContract(msg.sender), Contracts not allowed)
Under the EIP-7702 mechanism, the user address can be changed to a contract account through the set_code transaction, and isContract returns true. The contract will mistakenly identify the legitimate user as a contract account and refuse to allow the user to participate in the operation, causing the user to be unable to use certain services and having a hindered experience.
As contract wallets become more popular, the design of relying on isContract to determine whether it is a human user is no longer safe. It is recommended to use more accurate user identification methods such as signature verification.
3. Phishing Attacks
After the implementation of the EIP-7702 delegation mechanism , the assets in the users account will be completely controlled by the delegated smart contract. Once the user authorizes a malicious contract, the attacker may use it to gain full control over the account assets, causing the funds to be quickly transferred or stolen, which poses a very high security risk.
Therefore, it is crucial for wallet service providers to support EIP-7702 type transaction parsing and risk identification mechanisms as soon as possible . When users sign a delegated transaction, the front end should clearly and prominently display the target contract address, and combine auxiliary information such as the contract source and deployment information to help users identify potential phishing or fraudulent behavior, thereby reducing the risk of missigning. Furthermore, wallet services should integrate automated security analysis capabilities for target contracts, such as contract code open source status checks, permission model analysis, and potential dangerous operation identification, to assist users in making safer judgments before authorization.
It is particularly important to note that the delegated signature format introduced by EIP-7702 is not compatible with the existing EIP-191 and EIP-712 signature standards. Its signature can easily bypass the original signature warnings and interactive prompts of the wallet, further increasing the risk of users being deceived into signing malicious operations. Therefore, introducing the recognition and processing mechanism of this signature structure in the wallet implementation will be a key link in ensuring user security.
4. Wallet contract risks
(1) Wallet contract permission management
Many EIP-7702 wallet contracts use a proxy architecture (or built-in management permissions) to support logic upgrades. However, this also brings higher permission management risks. If the upgrade permissions are not strictly restricted, attackers may replace the implementation contract and inject malicious code, resulting in user accounts being tampered with or funds being stolen.
Safety Tips:
Use multi-signature, multi-factor authentication or time lock mechanism to control upgrade permissions.
Code and permission changes must undergo strict auditing and security verification.
The upgrade process is open and transparent to ensure users’ right to know and participate.
(2) Storage conflict risk and data isolation
Wallet contract versions or different wallet service providers may reuse the same storage slot. If the user changes the wallet service provider or upgrades the wallet logic, reusing the storage slot will lead to state variable conflicts , data overwriting, reading anomalies and other problems. This may not only destroy the normal function of the wallet, but also cause fund loss or permission anomalies.
Safety Tips:
Use a dedicated storage isolation solution (such as the EIP-1967 standard) or utilize unique namespaces to manage storage slots.
When upgrading contracts, ensure that the storage layout is compatible to avoid variable overlap.
Strictly test the rationality of storage status during the upgrade process.
(3) Nonce management within the wallet
Wallet contracts usually set nonce internally and manage it themselves to ensure the execution order of user operations and prevent replay attacks. If nonce is used improperly, user operations will not be executed normally.
Safety Tips:
Nonce must be strictly checked for equality (or incrementing) and cannot be skipped.
Functions are prohibited from directly modifying nonce. Nonce will only be updated synchronously when user operations are performed.
Design fault tolerance and recovery mechanisms for nonce anomalies to avoid nonce deadlock.
(4) Function caller permission check
To ensure security, the wallet contract must ensure that the caller of key functions is the owner account of the wallet. Two common methods include:
Off-chain signature authorization
The user signs a set of operations with a private key, and the wallet contract verifies on the chain whether the signature is legal, expired, and satisfies the corresponding nonce. This method is suitable for the relay transaction mode advocated by EIP-7702 (user offline signature + relay agent transaction).
Call constraint (msg.sender == address(this))
User operation functions are only allowed to be triggered by the contract itself, which is essentially a call path control mechanism to ensure that the external initiator must be the account itself. This is actually equivalent to requiring the caller to be the original EOA, because the contract address at this time is the EOA address.
3. Outlook: EIP-7702 and the future AA wallet standard
The introduction of EIP-7702 is not only an innovation of the traditional account model, but also a major boost to the Account Abstraction ecosystem. The ability of users to load contract code introduced by it brings a broad space for exploration of future wallet design and contract systems, and also puts forward new requirements for security audit standards.
1. Co-evolution with EIP-4337: towards dual-mode compatibility
Although EIP-7702 and EIP-4337 have different design goals, the former reconstructs the account code loading mechanism, while the latter builds a complete transaction entry and packaging ecosystem. However, the two are not in conflict, but are highly complementary:
● EIP-4337 provides a “universal transaction channel” and an “abstract account execution interface”;
● EIP-7702 allows user accounts to dynamically grant contract logic capabilities without changing the address;
Therefore, wallets may adopt a dual-mode support architecture in the future: using EIP-7702 as a lightweight alternative on chains that do not support EIP-4337, and continuing to rely on the complete protocol stack of EIP-4337 in scenarios that require off-chain packaging and multi-user aggregation.
This dual-mode mechanism will also enable the wallet to support more flexible account permission models, downgrade mechanisms and rollback solutions at the kernel layer.
2. Support and inspiration for new wallet logic such as MPC and ZK
The account contract mechanism advocated by EIP-7702 has natural integration potential with the current popular new architectures such as MPC wallets, ZK wallets, and modular wallets:
● In MPC mode, signing behavior no longer relies on a single private key, but rather on collaborative decision-making by multiple parties. The signature generated by the fusion of EIP-7702 and MPC can control the dynamically loaded contract logic, thereby achieving a more flexible execution strategy.
● ZK wallet verifies user identity or authorization through zero-knowledge proof without exposing private key information. Combined with EIP-7702, ZK wallet can temporarily inject specific logic contracts after verification is completed, thereby realizing personalized behavior deployment after privacy calculation, such as automatically executing a certain logic only after certain privacy conditions are met.
● Modular wallets can use EIP-7702 to break down account logic into multiple modules and load them dynamically when needed.
Therefore, EIP-7702 provides a more native execution container for the above-mentioned advanced wallets: different contract logics can be injected while keeping the user address unchanged, avoiding address dependency issues in the traditional contract deployment process and eliminating the need for pre-deployment, greatly improving the flexibility and combination capabilities of account behavior.
3. Implications for contract developers and auditors
EIP-7702 will promote a profound change in the development paradigm. Contract developers no longer simply regard the caller as a traditional EOA or a fixed contract account, but must adapt to a new mechanism: the caller identity can be dynamically switched between EOA and contract status during the transaction process, and the account behavior logic is no longer statically fixed, but can be flexibly changed according to demand. This requires developers and auditors to have:
Introduced stricter caller verification and permission judgment logic;
Check whether the call path is affected by dynamic contract logic;
Identify potential vulnerabilities that rely on behaviors such as msg.sender.code.length == 0, isContract(), etc.
Clarify the context dependency of contract logic, such as boundary control of static calls and delegatecalls;
Supports simulation and restoration analysis of setCode scenarios at the toolchain level.
In other words, code security is no longer just a pre-deployment issue but has become a dynamic process that must be verified during calls and transactions.
IV. Conclusion
EIP-7702 introduces a lighter, native and flexible implementation for account abstraction (AA), allowing ordinary EOA to carry and execute contract logic in a single transaction. This mechanism breaks the traditional static assumption of account behavior. Developers can no longer simply rely on the code status of the account address to determine its behavior model, but need to reconstruct the understanding of the callers identity and permission boundaries.
What follows is a paradigm shift in security analysis. The focus of the audit is no longer limited to whether a certain address has permission, but shifts to what the contract logic carried in the transaction can do in the current context. Each transaction may carry an independent behavior definition, which gives the account stronger functions and also puts higher requirements on security audits.
