Account Abstraction (AA) is an important long-term exploration direction 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 currently, 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 threshold for using account abstraction and enhance its native support, Vitalik proposed EIP-7702 in 2024, which was included 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, thereby 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 in 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 isContract, extcodehash, and other judgment logic may become ineffective, and some assumptions that the caller is a pure EOA may also be bypassed. For auditors, it is necessary to verify the security of the injected code itself and assess its potential impact on other contract systems in a dynamic context.

In this article, the Beosin security team will systematically outline the design principles and key features of EIP-7702, as well as the security risks that AA wallets built on it may face during audits, and combine practical perspectives to propose audit processes and recommendations to help security researchers better cope with the technical challenges under this new paradigm.

1. Introduction to EIP-7702

1. Technical Overview of EIP-7702

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

1. rlp([chainid, nonce, maxpriorityfeepergas, maxfeepergas, gas_limit,

2. destination, value, data, accesslist, authorizationlist, signatureyparity, signaturer, signatures])

Where the authorization_list contains multiple authorization entries and may also include authorization actions from non-transaction initiators, with the internal structure being:

1. authorizationlist= [[chainid, address, nonce, y_parity, r, s]]

Here, chainid indicates the chain on which the user authorization is effective, and its value must equal the chain ID of the executing chain or be 0. When chainid is 0, it indicates that the authorization is effective on all EVM chains supporting EIP-7702, provided that other parameters (such as nonce) match. The address indicates the target contract address authorized by the user.

After authorization is completed, the system will modify the code field of the authorized user to 0xef0100 || address, where address is the authorized contract address. To revoke the authorization, simply initiate a SetCode transaction with the address set to the zero 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 controls, etc., to meet different scenario needs for individuals or enterprises. This design significantly enhances the functional extensibility of accounts, breaking the limitations of traditional External Owned Accounts (EOA).

(2) Enhanced Security

Abstract accounts provide multi-layer security mechanisms, including multi-factor authentication, transaction limits, and social recovery. Even if users lose their private keys, they can recover their accounts through trusted contacts or multi-factor verification, avoiding permanent asset loss due to lost private keys in traditional accounts. 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 fees through third parties or even directly use other tokens to pay transaction fees. This mechanism not only reduces users' operational costs but also further simplifies the blockchain usage process, especially suitable for novice users or complex multi-step transaction scenarios.

(4) Promoting Web3 Adoption

By optimizing experience and security, abstract accounts hide the complexity of blockchain from users, providing a more convenient operation closer to Web2. This design reduces the learning costs for ordinary users, allowing more people to participate in Web3 applications without barriers, thus promoting the adoption of decentralized technologies.

2. Analysis of Security Risks in EIP-7702 Practice

Although EIP-7702 injects new momentum into the Ethereum ecosystem and expands rich application scenarios, it inevitably introduces some new security risks:

1. Authorization Replay Attacks

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

It is particularly important to note that even if the account identifiers are the same for the same address on different chains, the underlying contract implementations may be completely different. This means that attackers may deploy a malicious version of the contract on another chain, using the authorization behavior of the same address on-chain to execute unintended operations, thereby posing risks to user assets.

Therefore, for wallet service providers or front-end interaction platforms, it is essential to clearly verify that the chainId declared in the user's authorization matches the currently connected network when users perform such authorization operations; if it detects that the user has set chainId to 0, it should provide a clear risk warning, reminding users that this authorization will be effective on all EVM-compatible chains and may be abused by malicious contracts.

Additionally, service providers should evaluate whether to default limit or prohibit authorizations with chainId set to 0 at the UI level to reduce the risk of misoperation or phishing attacks.

2. Contract Compatibility Issues

(1) Contract Callback Compatibility

Existing token contracts such as ERC-721, ERC-777, and ERC-1155 call standard callback interfaces (like onERC721Received, tokensReceived) when transferring to contract addresses to complete the transfer operation. If the receiving address does not implement the corresponding interface, the transfer will fail or even lead to 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:

• The user address will be treated as a contract;

• If the contract does not implement the necessary callback interfaces, it will cause token transfers to fail;

• Users may unknowingly be unable to receive mainstream tokens.

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 is initiated directly by a user, used for security controls to prevent contract calls.

However, in the EIP-7702 scenario:

• The user signs the authorization transaction, which is actually broadcasted by a relayer or bundler; during transaction execution, "tx.origin" is the relayer's address, not the user's address.

• "msg.sender" is the wallet contract representing the user's identity.

Therefore, using "tx.origin == msg.sender" for permission validation will lead to legitimate user operations being rejected, losing reliability, and similarly, using "tx.origin == user" to restrict contract calls will also become ineffective. It is recommended to abandon "tx.origin" as a basis for security judgment and instead use signature verification or authorization mechanisms.

(3) "isContract" Misjudgment

Many contracts use "isContract(address)" (to check the address code length) to prevent contract accounts from participating in certain operations, such as airdrops, purchases, etc.:

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

Under the EIP-7702 mechanism, user addresses can become contract accounts through "set_code" transactions, causing "isContract" to return true, leading contracts to mistakenly identify legitimate users as contract accounts, rejecting their participation in operations, and preventing users from using certain services, thus hindering their experience.

As contract wallets gradually become popular, relying 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 Attacks

After implementing the delegation mechanism of EIP-7702, the assets in user accounts will be completely controlled by the delegated smart contract. Once a user authorizes a malicious contract, the attacker may gain complete control over the account's assets, leading to rapid transfer or theft of funds, posing a high security risk.

Therefore, for wallet service providers, it is crucial to support the parsing and risk identification mechanisms for EIP-7702 type transactions as early as possible. When users sign delegation transactions, the front end should clearly and prominently display the target contract address, along with auxiliary information such as contract source and deployment information, to help users identify potential phishing or fraudulent behavior, thereby reducing the risk of mis-signing. Furthermore, wallet services should integrate automated security analysis capabilities for target contracts, such as checking the open-source status of contract code, analyzing permission models, and identifying potential dangerous operations, to assist users in making safer judgments before authorization.

It is particularly important to note that the delegation signature format introduced by EIP-7702 is not compatible with existing EIP-191 and EIP-712 signature standards. Its signatures can easily bypass the original signature warnings and interaction prompts of wallets, further increasing the risk of users being deceived into signing malicious operations. Therefore, introducing recognition and processing mechanisms for this signature structure in wallet implementations will be a key step in 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 permission management risks. If upgrade permissions are not strictly limited, 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.

• Maintain a publicly transparent upgrade process to ensure users' right to know and participate.

(2) Storage Conflict Risks and Data Isolation

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

Security Recommendations:

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

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

• Rigorously test the rationality of storage states during the upgrade process.

(3) Internal Nonce Management of Wallets

Wallet contracts typically set and manage nonces internally to ensure the execution order of user operations and prevent replay attacks. Improper use of nonces can lead to user operations not executing correctly.

Security Recommendations:

• Nonces must be strictly checked for equality (or incrementing) and cannot be skipped.

• Direct modification of nonces by functions is prohibited; nonces must only be updated when user operations are executed.

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

(4) Caller Permission Checks for Functions

To ensure security, wallet contracts must ensure that the caller of key functions is the wallet's owner account. Two common methods include:

• Off-chain signature authorization

Users sign a set of operations with their private keys, and the wallet contract verifies the signature on-chain for validity, expiration, and corresponding nonce. This method is suitable for the relay transaction model advocated by EIP-7702 (user offline signing + relayer broadcasting transactions).

• Call Constraints (msg.sender == address(this))

User operation functions are only allowed to be triggered by the contract itself, essentially a call path control mechanism that ensures external initiators 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 introduction of EIP-7702 is not only a revolution in the traditional account model but also a significant push for the Account Abstraction (AA) ecosystem. The ability to load contract code by users introduces vast exploration space for future wallet design and contract systems, as well as new requirements for security auditing standards.

1. Collaborative Evolution with EIP-4337: Moving Towards Dual-Mode Compatibility

Although EIP-7702 and EIP-4337 have different design goals, with the former reconstructing the account code loading mechanism and the latter building a complete transaction entry and packaging ecosystem, the two are not in conflict; rather, they are highly complementary:

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

● EIP-7702 allows user accounts to dynamically assign contract logic capabilities without changing addresses;

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 requiring off-chain packaging and multi-user aggregation.

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

2. Support and Inspiration for New Wallet Logics like MPC and ZK

The account contract mechanism advocated by EIP-7702 has a natural integration potential with popular new architectures such as MPC wallets, ZK wallets, and modular wallets:

● In the MPC model, signing behavior no longer relies on a single private key but involves multi-party collaborative decision-making. The signatures generated by the integration of EIP-7702 and MPC can control dynamically loaded contract logic, enabling more flexible execution strategies.

● ZK wallets use zero-knowledge proofs to verify user identity or authorization without exposing private key information. After combining with EIP-7702, ZK wallets can temporarily inject specific logic contracts after verification, enabling personalized behavior deployment after privacy computation, such as automatically executing certain logic only when specific privacy conditions are met.

● Modular wallets can leverage EIP-7702 to decompose account logic into multiple modules, dynamically loading them as needed.

Thus, EIP-7702 provides a more native "execution container" for the aforementioned advanced wallets: user addresses can 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 combinability of account behaviors.

3. Insights for Contract Developers and Auditors

EIP-7702 will drive profound changes in development paradigms. Contract developers will no longer simply view callers as traditional EOAs or fixed contract accounts but must adapt to a completely new mechanism: the caller's identity can dynamically switch between EOA and contract states during transactions, and account behavior logic is no longer statically fixed, but can flexibly change according to needs. This requires developers and auditors to possess:

• Introduce stricter caller verification and permission judgment logic;

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

• Identify potential vulnerabilities in behaviors relying on msg.sender.code.length == 0, isContract(), etc.;

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

• Support simulation and restoration analysis for setCode scenarios at the toolchain level.

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

4. Conclusion

EIP-7702 introduces a lighter, more native, and flexible implementation method 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 account addresses to determine their behavior models but need to reconstruct their understanding of caller identity and permission boundaries.

This brings about a shift in the paradigm of security analysis. The focus of auditing 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, granting accounts stronger functionality and imposing higher requirements on security auditing.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。