Beosin: EIP-7702 and next-generation AA wallet security audit analysis

Account Abstraction (AA) is an important direction of long-term exploration in the Ethereum ecosystem, aiming to break the boundary between external accounts (EOA) and contract accounts, so that the wallet has stronger programmability, security, and upgradeability. EIP-4337 is currently the most mainstream AA implementation solution, and has been widely used in a number of EntryPoint-based smart contract wallets (such as Safe, Stacks, and Argent). However, EIP-4337 still has certain limitations in terms of on-chain nativeness, operational complexity, and ecological compatibility due to its introduction of an independent transaction pool and on-ramp contract mechanism.

To further lower the barrier to entry and enhance native support for account abstractions, Vitalik proposed EIP-7702 in 2024 and included it 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, and use this code to define the execution logic of the transaction.

EIP-7702 introduces a new mechanism for "transaction-level code injection", which allows user accounts to dynamically specify execution logic in each transaction, rather than relying on pre-deployed contract code. This breaks the traditional static code-based permission model, brings greater flexibility, and introduces new security challenges: contracts that rely on judgement logic such as isContract and extcodehash may become invalid, and some systems that assume that the caller is pure EOA may also be bypassed. For auditors, it is important not only to verify the security of the injected code itself, but also to assess 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 in the audit, and put forward the audit process and suggestions from a practical perspective to help security researchers better cope with the technical challenges under this new paradigm.

1. Introduction to EIP-77021

. EIP-7702 Technical

OverviewEIP-7702 introduces a new transaction type, 0x 04 (SetCode), which allows EOA to authorise the contract code that needs to be executed through this transaction, with the following transaction structure:

1. rlp([chain_id, nonce, max_priority_fee_per_gas, max_ fee_per_gas, gas_limit,

2. destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Where authorization_list contains multiple authorisation lists, and can also contain authorisation actions of non-transaction initiators, the internal structure is:

1. authorization_list = [[chain_id, address, nonce, y_parity, r, s]].

where chain_id represents the chain in which the user's authorisation takes effect, and its value must be equal to the chain ID of the executing chain or 0. When chain_id is 0, the authorisation takes effect for all EVM chains that support EIP-7702, but only if other parameters (such as nonce) match. address indicates the target contract address authorised by the user.

After the authorisation is completed, the system will modify the code field of the authorised user to 0x ef 0100 || address, where address is the authorised contract address. If you want to deauthorize, simply initiate a SetCode transaction with the address set to 0.

2. Advantages of EIP 7702

(1) Flexibility & Customization

Abstract AccountsBy writing account logic into smart contracts, you can flexibly customise functions according to your needs. For example, users can configure multi-signature, social recovery, and quota control to meet the needs of individuals or enterprises in different scenarios. This design greatly improves the functional scalability of the account and breaks through the limitations of traditional external accounts (EOA).

(2) Enhanced

SecurityAbstract Accounts provide a multi-layered security mechanism, 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 authentication, avoiding the permanent loss of assets caused by the loss of the private key in traditional accounts. At the same time, functions such as limit control can also prevent large amounts of funds from being maliciously stolen.

(3) The Gas Optimized

Abstraction Account supports a flexible gas abstraction mechanism, allowing users to pay for Gas through a third party, and even directly use other tokens to pay transaction fees. This mechanism not only reduces the operation cost of users, but also further simplifies the use of the blockchain, especially suitable for novice users or complex multi-step transaction scenarios.

(4) Promote the popularisation of Web3By

optimising the experience and security, abstract accounts hide the complexity of the blockchain in places that users can't see, providing convenient operations closer to Web2. This design reduces the learning cost of ordinary users, allows more people to participate in Web3 applications without barriers, and promotes the popularisation of decentralised technology.

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

Although EIP-7702 has injected new impetus into the Ethereum ecosystem and expanded a wealth of application scenarios, at the same time, it has inevitably introduced some new security risks:

1. Authorization replay attack

Under the EIP-7702 model, if the user authorises the chain_ If the id field is set to 0, the authorisation can take effect on multiple chains. Although this design of "cross-chain universal authorisation" improves flexibility in some scenarios, it also introduces obvious security risks.

It is important to note that even if the account identity of the same address is the same on different chains, the contract implementation behind it may be completely different. This means that an attacker could deploy a malicious version of the contract on another chain and perform unintended actions using the authorisation of the same address on the chain, thus posing risks to user assets.

Therefore, for wallet service providers or front-end interaction platforms, when users perform such authorisation operations, they should clearly verify whether the chainId declared in the user's authorisation is consistent with the current connection network; If a user is detected setting the chainId to 0, a clear risk warning should be given to remind the user that the authorisation 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 authorisation with chainId 0 by default at the UI layer to reduce the risk of misoperation or phishing attacks.

2. Contract Compatibility

1) Contract Callback Compatibility

transferring money to a contract address for existing token contracts such as ERC-721, ERC-777, and ERC 1155, they will call standard callback interfaces (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 transformed into a contract account by being given a contract code through the "set_code" operation. In this case:

• The user address is considered a contract;

• 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 their knowledge.

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 failsIn

traditional contracts, "tx.origin" is often used to determine whether the transaction is directly initiated by the user, and is used to prevent security controls such as contract calls.

However, in the EIP-7702 scenario, the

• user signs an authorisation transaction, and the relayer or bundler broadcasts it on behalf of the user. When a transaction is executed, "tx.origin" is the relayer address, not the user address.

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

Therefore, the permission verification based on "tx.origin == msg.sender" will cause legitimate user operations to be rejected and lose reliability, and the same restricted contract calls such as "tx.origin == user" will also be invalidated. It is recommended to abandon "tx.origin" as the basis for security judgement and use signature verification or authorisation mechanism instead.

(3) "isContract" misjudgesMany

contracts prevent contract accounts from participating in certain operations, such as airdrops, flash sales, etc., through "isContract(address)":

require(!isContract(msg.sender), "Contracts not allowed"

). Under the EIP-7702 mechanism, the user's address can be changed to a contract account through a "set_code" transaction, and "isContract" returns true, and the contract will mistakenly identify the legitimate user as the contract account and refuse to participate in the operation, resulting in the user being unable to use certain services and the experience being blocked.

With the gradual popularisation of contract wallets, the design of relying on "isContract" to determine whether "a human user" is no longer secure, and it is recommended to use more accurate user identification methods such as signature verification.

3. Phishing AttackAfter

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 a user authorises a malicious contract, an attacker may gain full control over the account assets, resulting in the rapid transfer or theft of funds, which is extremely risky.

Therefore, for wallet service providers, it is necessary to support the EIP-7702 transaction resolution and risk identification mechanism as soon as possibleCrucial. 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 behaviours, thereby reducing the risk of mis-signing. Further, the wallet service should integrate automatic 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 judgements before authorisation.

In particular, EIP-7702 introduces a delegated signature format that is not compatible with the existing EIP-191 and EIP-712 signature standards. Its signature can easily bypass the original signature warning and interaction prompt of the wallet, which further increases the risk of users being deceived into signing malicious operations. Therefore, the introduction of the identification and processing mechanism of the signature structure in the wallet implementation will be a key link to ensure the security of users.

4. Wallet Contract Risks

( 1) Wallet Contract Authority Management

Many EIP-7702 wallet contracts adopt a proxy architecture (or built-in management permissions) to support logical upgrades. However, this also poses a higher risk of rights management. If the escalation privileges are not strictly restricted, an attacker may replace the implementation contract and inject malicious code, resulting in the user's account being tampered with or funds stolen.

Security recommendations

• : Use multi-signature, multi-factor authentication, or timelock mechanisms to control escalation privileges.

• Code and permission changes are subject to rigorous auditing and security validation.

• The upgrade process is open and transparent to ensure users' right to know and participate.

(2) Risk of storage conflicts 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, the reuse of the storage slot will cause the state variable conflict, data overwriting, reading exceptions and other problems. Not only can this disrupt the normal functioning of the wallet, but it can also lead to the loss of funds or abnormal permissions.

Security recommendations:

• Use a specialised storage isolation scheme, such as the EIP-1967 standard, or leverage a unique namespace to manage storage slots.

• When upgrading the contract, make sure that the storage layout is compatible and avoid overlapping variables.

• Rigorously test the plausibility of the stored state during the upgrade process.

(3) The nonce management inside the wallet

The wallet contract usually sets up a nonce inside and manages itself to ensure the execution order of user operations and prevent replay attacks. If the nonce is used incorrectly, the user operation will not be executed properly.

Security Recommendation:

• The nonce must be forcibly checked for an equivalent value (or increment) and cannot be skipped.

• It is forbidden for functions to directly modify the nonce, and the nonce will only be updated when the user operation is executed.

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

(4) Function caller permission checkIn

order to ensure security, the wallet contract must ensure that the caller of the key function is the owner account of the wallet. The two common methods include:

• off-chain signing authorises

users to sign a set of operations through the private key, and the wallet contract verifies whether the signature is legitimate, expired, and satisfies the corresponding nonce on the chain. This method is applicable to the relay transaction mode advocated by EIP-7702 (user offline signature + relayer sends transaction on behalf of the user).

• The call constraint (msg.sender == address(this))

user action function is only allowed to be triggered by the contract itself, which is essentially a call path control mechanism that ensures that the external initiator must be the account itself. This is effectively equivalent to requiring the caller to be the original EOA, since the contract address is the EOA address.

3. Outlook: The proposal of EIP-7702 and the future AA wallet standard

EIP-7702 is not only an innovation of the traditional account model, but also a major promotion of the account abstraction ecosystem. The ability to load contract code introduced by it brings a broad space for exploration for future wallet design and contract system, and also puts forward new requirements for security audit standards.

1. Co-evolution with EIP-4337: Towards dual-mode compatibilityAlthough

EIP-7702 and EIP-4337 have different design goals, the former reconstructs the code loading mechanism of the account, and the latter builds a complete transaction entry and packaging ecosystem. However, the two are not in conflict, but have strong complementarity:

● EIP-4337 provides a "common transaction channel" and an "abstract account execution interface";

● EIP-7702 allows user accounts to dynamically grant contract logic capabilities without changing the address;

Therefore, in the future, wallets may adopt a "dual-mode support architecture": use EIP-7702 as a lightweight replacement on chains that do not support EIP-4337, and continue to rely on the full protocol stack of EIP-4337 in scenarios that require off-chain packaging and multi-user aggregation.

This dual-mode mechanism will also enable wallets to support more flexible account permission models, downgrade mechanisms, and rollback schemes at the kernel layer.

2. Support and inspiration for new wallet logic such as MPC and ZK, and the

account contract mechanism advocated by EIP-7702 has natural integration potential with the current popular MPC wallet, ZK wallet, modular wallet and other new architectures:

● In the MPC model, the signature behaviour no longer relies on a single private key, but is a multi-party collaborative decision-making. Signatures generated through the convergence of EIP-7702 and MPC control the dynamically loaded contract logic, enabling more flexible execution strategies.

● ZK wallet verifies user identity or authorisation through zero-knowledge proofs, without exposing private key information. Combined with EIP-7702, ZK wallets can temporarily inject specific logic contracts after verification is completed, so as to realise the deployment of personalised behaviours after privacy computing, such as automatically executing a certain logic only after certain privacy conditions are met.

● Modular Wallets can use EIP-7702 to disassemble the account logic into multiple modules and dynamically load them when needed.

Therefore, EIP-7702 provides a more native "execution container" for the above-mentioned advanced wallets: different contract logic can be injected with the same user address, avoiding the address dependency problem in the traditional contract deployment process, and eliminating the need for pre-deployment, greatly improving the flexibility and combination of account behaviour.

3. Implications for Contract Developers and

will drive a profound change in the development paradigm. Contract developers no longer simply treat the caller as a traditional EOA or a fixed contract account, but must adapt to a new mechanism: the caller's identity can be dynamically switched between EOA and contract status during the transaction, and the account behaviour logic is no longer statically solidified, but can be flexibly changed according to demand. This requires developers and auditors to:

• introduce stricter caller verification and permission judgement logic;

• Check whether the call path is affected by the dynamic contract logic;

• identify potential vulnerabilities that rely on behaviours such as msg.sender.code.length == 0, isContract(), etc.;

• Clarify the "context dependencies" of contract logic, such as boundary control of static calls and delegatecalls;

• At the toolchain level, simulation and revert analysis of setCode scenarios are supported.

In other words, code security is no longer just a "pre-deployment issue" but a "dynamic process that must be verified during invocation and transaction".

4.

introduces a lighter, native, and flexible implementation of Account Abstraction (AA), so that ordinary EOA can carry contract logic and execute it in a single transaction. This mechanism breaks the traditional static assumptions about account behaviour, and developers can no longer simply rely on the code state of the account address to judge its behaviour model, but need to reconstruct the understanding of the identity and authority boundary of the caller.

With that comes a paradigm shift in security analytics. The focus of the audit is no longer limited to "whether an address has permissions", but to "what the contract logic carried in the transaction can do in the current context". Each transaction may carry an independent definition of behaviour, which gives the account greater functionality and puts forward higher requirements for security audits.