Beosin: EIP-7702 and Next-Generation AA Wallet Security Audit Analysis

Written by: Beosin

Account Abstraction (AA) is an important direction for long-term exploration in the Ethereum ecosystem, aimed at breaking the boundaries between External Owned Accounts (EOA) and Contract Accounts, enabling wallets to possess stronger programmability, security, and upgradability. EIP-4337, as the most mainstream AA implementation scheme, has been widely applied in a batch of EntryPoint-based smart contract wallets (such as Safe, Stacks, Argent). However, EIP-4337 still has certain limitations in terms of on-chain native properties, operational complexity, and ecological compatibility due to its introduction of independent transaction pools and entry contract mechanisms.

To further lower the usage threshold of account abstraction and enhance its native support, Vitalik proposed EIP-7702 in 2024, incorporating this 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 a specified address when initiating a transaction, thus defining the execution logic of that transaction.

EIP-7702 introduces a new mechanism of "transaction-level code injection," allowing user accounts to dynamically specify execution logic for each transaction, rather than relying on pre-deployed contract code. This breaks the traditional permission model based on static code, bringing greater flexibility while also introducing new security challenges: contracts that originally relied on judgment logic such as isContract and extcodehash may become ineffective, and some assumptions that the caller is a pure EOA may also be bypassed. For auditors, it is not only necessary to verify the security of the injected code itself, but also to assess its potential impact on other contract systems in a dynamic context.

This article by the Beosin security team will systematically outline the security risks that AA wallets built on the design principles and key features of EIP-7702 may face during audits. It will also provide practical insights and suggestions for the auditing process, helping security researchers better address the technical challenges posed by this new paradigm.

1. Introduction to EIP-7702

2. EIP-7702 Technical Overview

EIP-7702 introduces a new transaction type 0x04 (SetCode), which allows EOA to authorize the contract code that needs to be executed through this transaction. Its transaction structure is as follows:

The authorization_list contains multiple authorization lists and may also include authorization actions from non-trading initiators. The internal structure is:

Among them, chain_id represents the chain on which the user's authorization is effective, and its value must equal the chain ID of the executing chain or be 0. When chain_id is 0, it indicates that the authorization is effective for all EVM chains that support EIP-7702, provided that other parameters (such as nonce) match. address represents the target contract address for which the user has authorized.

After the authorization is complete, the system will modify the code field of the authorized user to 0xef0100 || address, where address is the authorized contract address. If you want to revoke the authorization, simply initiate a SetCode transaction and set the address to 0.

2. Advantages of EIP7702

(1) Flexibility and Customization

Abstract accounts can flexibly customize functions based on demand by embedding account logic into smart contracts. For example, users can configure multi-signature, social recovery, limit control, etc., to meet the different scenario needs of individuals or enterprises. This design greatly enhances the functional extensibility of accounts, breaking through the limitations of traditional externally owned accounts (EOA).

(2) Enhance Security

Abstract accounts provide multiple layers of security mechanisms, including multi-factor authentication, transaction limits, and social recovery. Even if a user loses their private key, they can recover their account through trusted contacts or multi-factor verification, avoiding the permanent loss of assets that traditional accounts face due to private key loss. Additionally, features like limit controls can 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 third parties or even directly use other tokens to cover transaction fees. This mechanism not only reduces the operational costs for users but also further simplifies the blockchain usage process, making it especially suitable for beginners or complex multi-step transaction scenarios.

( Boosting the Popularization of Web3

By optimizing experience and security, abstract accounts hide the complexity of blockchain in places invisible to users, providing a more convenient operation closer to Web2. This design reduces the learning cost for ordinary users, enabling more people to participate in Web3 applications without barriers, promoting the popularization of decentralized technology.

2. Analysis of Security Risks in Practice of EIP-7702

Although EIP-7702 has injected new momentum into the Ethereum ecosystem and expanded a rich array of application scenarios, it has also inevitably introduced some new security risks:

1. Authorization Replay Attack

Under the EIP-7702 model, if a user sets the chain_id field in the authorization to 0, it indicates that the authorization is valid across multiple chains. This design of "cross-chain universal authorization" enhances flexibility in certain scenarios, but also introduces significant security risks.

It is important to note that even if the account identifiers are the same across different chains, the underlying contract implementations may be completely different. This means that an attacker could deploy a malicious version of the contract on another chain, exploiting the authorization actions of the same address on-chain to execute unintended operations, thereby posing a risk to user assets.

Therefore, for wallet service providers or front-end interaction platforms, when users perform such authorization operations, it is necessary to clearly verify whether the chainId declared in the user authorization is consistent with the currently connected network; if it detects that the user has set the chainId to 0, a clear risk warning should be given to remind the user that this authorization will take effect on all EVM-compatible chains and may be abused by malicious contracts.

In addition, the service provider should assess whether to default restrict or prohibit the authorization of chainId 0 at the UI level to reduce the risk of misoperation or phishing attacks.

2. Contract Compatibility Issues

)1( Contract Callback Compatibility

Currently, token contracts such as ERC-721, ERC-777, and ERC-1155 will call standard callback interfaces (such as onERC721Received, tokensReceived) when transferring to a contract address to complete the transfer operation. If the receiving address does not implement the corresponding interface, the transfer will fail and may even result in asset locking.

In EIP-7702, user addresses can be assigned contract code through the "set_code" operation, thus transforming into contract accounts. At this point:

User addresses will be regarded as contracts;

If the contract does not implement the necessary callback interface, it will result in the token transfer failure;

Users may be unable to receive mainstream tokens without their knowledge.

Therefore, developers should ensure that the target contract delegated by the user implements the relevant callback interfaces to ensure compatibility with mainstream tokens.

)2( "tx.origin" validation failure

In traditional contracts, "tx.origin" is often used to determine whether a transaction was initiated directly by the user, serving as a security control to prevent contract calls and other related issues. But in the context of EIP-7702:

Users sign an authorization transaction, which is actually broadcasted by a relayer or bundler; when the transaction is executed, "tx.origin" is the address of the relayer, not the user address.

"msg.sender" is the wallet contract that represents the user's identity.

Therefore, the permission check based on "tx.origin == msg.sender" will lead to legitimate user operations being denied, resulting in a loss of reliability. Similarly, using restrictions like "tx.origin == user" to limit contract calls will also become ineffective. It is recommended to deprecate the use of "tx.origin" as a basis for security judgment and instead use signature verification or authorization mechanisms.

)3( "isContract" misjudgment

Many contracts prevent contract accounts from participating in certain operations, such as airdrops and token sales, by using "isContract )address(" (to check the address code length):

Under the EIP-7702 mechanism, user addresses can become contract accounts through the "set_code" transaction, and "isContract" returns true. The contract will mistakenly classify legitimate users as contract accounts, rejecting their participation in operations, which results in users being unable to use certain services and experiencing obstacles. With the gradual popularization of contract wallets, the design that relies on "isContract" to determine "whether it is a human user" is no longer safe. It is recommended to adopt more precise user identification methods such as signature verification.

3. Phishing Attack

After the implementation of EIP-7702's delegation mechanism, the assets in the user's account will be fully controlled by the delegated smart contract. Once the user authorizes the malicious contract, the attacker may gain full control over the account assets, resulting in the rapid transfer or theft of funds, which is extremely risky.

Therefore, it is important for wallet service providers to support EIP-7702 transaction resolution and risk identification mechanisms as soon as possible. When a user signs an entrustment transaction, the front-end should clearly and prominently display the target contract address, and combine supporting information such as contract source and deployment information to help users identify potential phishing or fraudulent behaviors, thereby reducing the risk of mis-signing. Further, the wallet service should integrate automated security analysis capabilities for the target contract, such as contract code open source status check, permission model analysis, and potentially dangerous operation identification, to help users make more secure 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 signatures can easily bypass the wallet's original signature warnings and interaction prompts, further increasing the risk of users being deceived into signing malicious actions. Therefore, introducing recognition and handling mechanisms for this signature structure in wallet implementations will be a key aspect of ensuring user safety.

4. Wallet Contract Risks

)1( Wallet Contract Permission Management

Many EIP-7702 wallet contracts adopt a proxy architecture ) or built-in management permissions ( to support logical upgrades. However, this also brings higher risks in permission management. If upgrade permissions are not strictly restricted, attackers may replace the implementation contract and inject malicious code, leading to user accounts being tampered with or funds being stolen.

Security Recommendations:

Use multi-signature, multi-factor authentication, or time-lock mechanisms to control upgrade permissions.

Code and permission changes must undergo strict auditing and security verification.

Open and transparent upgrade process to ensure users' right to know and participate.

) Storage conflict risk and data isolation

Wallet contract versions or different wallet service providers may reuse the same storage slot. If users change wallet service providers or upgrade wallet logic, reusing storage slots can lead to state variable conflicts, resulting in issues such as data overwrites and reading anomalies. This may not only disrupt the normal functionality of the wallet but also potentially lead to loss of funds or abnormal permissions.

Safety Advice:

Use dedicated storage isolation solutions (such as the EIP-1967 standard) or leverage unique namespaces to manage storage slots.

When upgrading contracts, ensure storage layout compatibility to avoid variable overlap.

Strictly test the rationality of the stored state in the upgrade process.

( Management of nonce inside the wallet

Wallet contracts usually have a nonce set internally and manage it themselves to ensure the execution order of user operations and to prevent replay attacks. Improper use of the nonce can result in the failure of user operations to execute normally.

Safety Recommendations:

The nonce must be strongly checked for equivalence (or incremented) and cannot be skipped.

Functions are not allowed to directly modify the nonce; it must be updated synchronously only when the user performs an operation.

Design fault tolerance and recovery mechanisms for nonce exceptions to avoid nonce deadlock.

) 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. The two common methods include:

Off-chain signature authorization

Users sign a set of operations with their private key, and the wallet contract verifies on-chain whether the signature is valid, whether it has expired, and whether it meets the corresponding nonce. This method is suitable for the relay transaction model advocated by EIP-7702 (user offline signing + relayer submitting transactions).

Call constraint (msg.sender == address (this))

User operation functions can only be triggered by calls from the contract itself, essentially serving as a control mechanism for the call path to ensure that the external initiator must be the account itself. This is effectively equivalent to requiring the caller to be the original EOA, as the contract address at this point is the EOA address.

3. Outlook: EIP-7702 and Future AA Wallet Standards

The proposal of EIP-7702 is not only an innovation of the traditional account model but also a significant boost to the account abstraction ecosystem. The ability it introduces for users to load contract code brings vast exploration opportunities for future wallet designs and contract systems, and also raises new requirements for security audit standards.

1. The Co-evolution with EIP-4337: Towards Dual Mode Compatibility

Although EIP-7702 and EIP-4337 have different design goals, the former reconstructs the code loading mechanism of accounts, while the latter builds a complete transaction entry and packaging ecosystem. However, the two are not in conflict; on the contrary, they have strong complementarity.

EIP-4337 provides the "Universal Transaction Channel" and the "Abstract Account Execution Interface";

EIP-7702 allows user accounts to dynamically assign contract logic capabilities without changing the address.

Therefore, future wallets may adopt a "dual-mode support architecture": using EIP-7702 as a lightweight alternative on chains that do not support EIP-4337, while continuing to rely on the complete protocol stack of EIP-4337 in scenarios that require off-chain bundling and multi-user aggregation.

This dual-mode mechanism will also encourage wallets to support a more flexible account permission model, downgrade mechanisms, and rollback solutions at the kernel level.

2. Support and Inspiration for New Wallet Logics such as MPC and ZK

The account abstraction mechanism advocated by EIP-7702 has a natural integration potential with the currently popular MPC wallets, ZK wallets, modular wallets, and other new architectures:

In the MPC mode, the signing action no longer relies on a single private key, but rather on collaborative decision-making among multiple parties. The signatures generated through the integration of EIP-7702 and MPC can control the dynamically loaded contract logic, thereby enabling more flexible execution strategies.

ZK wallets verify user identities or authorizations through zero-knowledge proofs without exposing private key information. After the integration of EIP-7702, ZK wallets can temporarily inject specific logic contracts after verification is complete, enabling personalized behavior deployment after privacy computation, such as automatically executing certain logic only when specific privacy conditions are met.

Modular Wallets can decompose account logic into multiple modules with the help of EIP-7702, loading them dynamically when needed.

Therefore, EIP-7702 provides a more native "execution container" for the advanced wallets mentioned above: user addresses remain unchanged while injecting different contract logic, avoiding the address dependency issues in the traditional contract deployment process, and eliminating the need for pre-deployment, significantly enhancing the flexibility and composability of account behavior.

3. Insights for Contract Developers and Auditors

EIP-7702 will drive profound changes in the development paradigm. Contract developers will no longer simply view callers as traditional EOAs or fixed contract accounts; instead, they must adapt to a completely new mechanism: the identity of the caller can dynamically switch between EOA and contract state during the transaction process, and the logic of account behavior is no longer statically fixed but can flexibly change according to demand. This requires developers and auditors to possess:

Introduce stricter caller verification and permission judgment logic;

Check whether the call path is affected by the dynamic contract logic.

Identify potential vulnerabilities related to behaviors such as msg.sender.code.length == 0, isContract (), etc.

Clarify the contract logic's "context dependence", such as boundary control of static calls and delegate calls;

Support simulation and restoration analysis of the setCode scenario at the toolchain level.

In other words, the security of the code is no longer just a "pre-deployment issue", but has become a "dynamic process that must be validated during calls and transactions".

4. Conclusion

EIP-7702 introduces a more lightweight, native, and flexible implementation for account abstraction (AA), allowing ordinary EOAs to carry contract logic and execute it in a single transaction. This mechanism breaks the traditional static assumptions about account behavior, and developers can no longer simply rely on the code state of an account address to determine its behavioral model, but need to reconstruct their understanding of the caller's identity and permission boundaries. Consequently, there is a shift in the paradigm of security analysis. The focus of audits 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 definition of behavior, which grants accounts stronger capabilities and imposes higher demands on security audits.