OKX Research Institute | The Final Battle of 10 Years of Account Abstraction: Looking at the Past and Future through EIP-7702

Author: shisilu

Preface

Pectra is the first major upgrade after Ethereum's Dencun, covering the Prague execution layer hard fork and the Electra consensus layer update, integrating a record 11 EIPs, significantly enhancing validator flexibility, network scalability, and execution efficiency. With the Ethereum mainnet Pectra hard fork officially activated on May 7, 2025, the "ultimate form" of account abstraction (Account Abstraction) ------ EIP-7702, has also officially entered the public eye!

If there are still any EVM-based Web3 wallets that do not support EIP-7702, then undoubtedly, it means they have given up on the entire Ethereum ecosystem and its users.

This is the determination of Vitalik and the Ethereum Foundation, and it marks the beginning of the Pandora's box about to be opened! Currently, to support the Ethereum ecosystem, OKX Wallet has taken the lead in supporting Ethereum's latest account abstraction standard EIP-7702, and has opened an official entry for users willing to try it out. Users can upgrade through the 【OKX Wallet Home Function Area - More - 7702 Upgrade】 to experience the secure and professional EIP-7702. A friendly reminder: users can choose to upgrade and experience as needed; not upgrading will not affect the normal use of existing ecosystems and applications. To ensure asset security, please operate through official channels and beware of phishing links and malicious websites to avoid asset risks.

Please follow this article to fully understand the evolution of account abstraction, the user value and market changes brought by EIP-7702, as well as the hidden dangers within.

Overview

• The code discussed in this article is located in okx/js-wallet-sdk, and the EIP-7702 SDK implementation used by OKX Wallet is open-sourced for community partners.

• EIP-7702 introduces a new transaction type that allows ordinary EOAs to set a specific contract address as their logical proxy contract.

• EIP-7702 will fully inherit and surpass the ecosystem built over many years by ERC-4337 due to its "cost advantages" and "flexibility."

• EIP-7702 also poses invisible risks to ordinary users; even if users do not upgrade, specific scenarios may lead to transaction failures or security asset loss risks.

• EIP-7702 will bring a brand new user experience. When the user entity undergoes contract migration, market applications will evolve accordingly. Gas abstraction, family-tier accounts, and other long-awaited smooth experiences will lead billions of users to enter the Web3 world at low cost.

• For exchanges and DApps, applying the features of EIP-7702 will bring over 50% cost reduction, thus fully embracing the era of contract accounts.

Why Abstract Accounts?

It is hard to imagine that the vision of account abstraction predates Ethereum itself.

During this HK Web3 Carnival, Vitalik repeatedly emphasized that through a series of solutions such as multi-signature (Multi-sig), account abstraction, and ZK Email, Ethereum has achieved 50% of the "iPhone moment" goal.

Is it fast or slow? Is it optimistic or limited? Let us delve into the fundamentals and see why AA has such influence! After all, after a decade-long journey, Vitalik has finally welcomed the conclusion he has long dreamed of in the AA field, adding a significant stroke to the Ethereum roadmap he envisioned for 2023.

What is the Purpose of Account Abstraction?

In essence, it addresses the issue of property rights separation. Currently, the ownership and signing rights of EOAs (Externally Owned Accounts) are held by the same entity (both rely on private keys for any command control). This stems from Ethereum's transaction structure, where there is actually no "From" party in standard Ethereum transactions; the "From" address is derived from the VRS parameters (i.e., user signatures) during execution. Moreover, as Ethereum is designed as a "world-class state machine," it relies entirely on transactions to achieve on-chain state changes. Coupled with the inability to specify the "From" party, this intertwines transaction execution authority with ultimate ownership. This is the root cause of a series of issues where EOAs, despite being simple and understandable, are inconvenient to use:

• Private keys are hard to protect: losing a private key (due to loss, hacking, or quantum cracking) means losing all assets.
• Limited signing algorithms lead to different performance losses and even costs for on-chain storage.
• High signing authority: the native private key of EOA has all these rights.
• High fees for complex transactions: fees can only be paid in ETH, and any transaction or single operation requires at least 21,000 in base fees.
• No transaction privacy: even though there was once a confidential ERC-20 protocol proposed by Circle, it did not become mainstream.

Ultimately, the current blockchain world is too complex for users entering and exiting. Users need to understand concepts like Gas price, Gas limit, and transaction blocking (Nonce order). Hiding complex information from regular users is precisely the problem EIP-7702 aims to solve.

What are the Core Differences Between ERC-4337 and EIP-7702?

Around the goal of AA, there are actually more than a dozen different proposals, which I have previously explored. Overall, it can be summarized into two routes:

Route One: Let EOA Addresses Drive CA Addresses

ERC-4337 is a typical example in this regard. In summary: it proposes a new transaction object called UserOperation, which users send to the memory pool in the form of bundlers, batch packaging instructions, and executing transactions one by one through delivery contracts. Essentially, it pulls the underlying transaction and account operations to the contract layer for execution.

The execution principle is illustrated in the following diagram:

Through the role of bundler, this solution can address issues like batch transactions, gas-free transactions, and fewer signing algorithms.

However, it does not solve the complexity and user transaction costs, as well as the single point of failure risk of bundler and EntryPoint.

Once users migrate to ERC-4337, even if user2's requirement in the diagram is just to make a Transfer transaction, the user's transaction fees will double compared to EOA.

From the latest user data of CA and EOA, it can be seen that even if some users are high-end players who heavily rely on various operations based on on-chain CA, batch calls, etc., if so, why not directly use ordinary CA? This stems from the design of bundler, allowing it to avoid hard fork-level upgrades and launch directly at the application layer. However, ERC-4337 also brings doubled cost expenditure and single point of failure risks, and users lose the original flexibility of EOA. Therefore, facing diverse user needs, it is evident that the current market users are not so keen on the ERC-4337 solution, with a significant downward trend over the two years of development. Even at its peak, the number of users is far from Ethereum's 300M independent addresses. Of course, we are not criticizing the shortcomings of ERC-4337, but rather observing that the roles and concepts developed on it, such as Paymaster and Gas abstraction, are also applied again in EIP-7702. I believe that the development of any industry is not achieved overnight; what is important is to discover patterns and summarize experiences from past ups and downs.

Route Two: Let EOA Addresses Become CA Addresses

As early as November 2015, Vitalik proposed EIP-101, which introduced a new structure for accounts as contracts. It changed addresses to only contain code and storage space, altering fee support to be paid via ERC20, and using precompiled contracts to convert native tokens into ERC20-like for balance storage (capable of having functions like authorization for deduction). In January 2018, there was also the EIP-859 proposal, which core function was to deploy contract wallets if the trading party's contract was not deployed. Ultimately, EIP-7702, derived from the EIP-3074 proposal, was incorporated into the Ethereum mainnet!

The concept and effect of EIP-7702 are quite simple. It completes initialization through a new transaction type, allowing users to temporarily and optionally have smart contract functionality in a single transaction, thus supporting batch transactions, gas-free transactions, and custom permission management. The most critical capability is that it provides users with temporary and optional space.

Moreover, multiple users can share the same logical contract, significantly reducing the cost of user migration. To complete the setup for EIP-7702, users only need 80,000 Gas, approximately $0.06, while setting up a new contract or canceling the logical contract setup only requires 40,000 Gas.

Once the setup is complete, it can significantly optimize gas usage during batch transactions, as shown in the table below:

Of course, you might wonder, is it necessary to perform two or even six Token Transfers?

Regular users have become accustomed to doing one thing per transaction, so it seems there are not many scenarios. However, in diverse application scenarios like Web3 Game and Web3 Pay, such situations frequently arise, such as consuming both copper coins (in-game currency) and silver coins (user-recharged currency) simultaneously. Or participating in an event while consuming both NFT tickets and entry fees.

Even if we do not delve into complex scenarios, returning to the current mainstream on-chain Swap demand, there is also a need for batch approvals and transfers. In fact, a small tool can be created to help users quickly delete their already useless approval authorizations. The effect can be easily compared, and it is clear that costs can be directly reduced by about 40%.

Core Principles of EIP-7702

To explore why it has such effects, we must return to its principles, which essentially consist of two logics: the user setup phase and the daily usage phase.

Setting Up Logical Contracts

The core process is as follows:

• Step One: Signature Authorization. Using the original EOA's private key, sign a special hash string composed of encoded chain_id, address, and nonce. Here, the Address is the logical contract address to be set, while the Nonce ensures that the transaction is not replayed.

• Step Two: Sign the Transaction. With the authorization information from Step One, anyone can construct a transaction of type 4, which can include multiple authorization information, allowing for unified authorization settings for multiple addresses at once.

• Step Three: Broadcast on-chain. When the transaction processes the internal Authorization, the logical contract will already be effective.

There are more technical details to consider, which can be referenced in the implementation of the open-source js SDK by OKX to see the underlying data encoding process. Of course, this solution also hides some security risks and complexities, which we will discuss in detail later.

Executing Logical Contracts

Once you have completed the setup, when any transaction's To address points to you, it will be like calling a smart contract; the system will "load" the code of your originally set logical contract into the current EOA's state to execute its logic.

Let’s look at two scenarios:

The first scenario is you calling yourself.

If you set up a highly secure and customizable contract like the OKX 7702 Smart Contract, you can specify through pre-written calldata to complete multiple instructions in one go. For example, you can simultaneously complete Approve + Transfer, or Approve + Swap.

Do not underestimate this; among the total of 2.7 billion Ethereum transactions, Approve accounts for about 75 million transactions. Calculating at 80,000 Gas per transaction, that results in 460,000 ETH consumed, which, at a market price of $1,700 for ETH, amounts to nearly $800 million.

The second scenario is someone else calling you.

Previously, it was not possible for others to call an EOA address on Ethereum, but now you are a universal contract, fully customizable. You can create sub-accounts with different permissions, or whitelist specific Paymaster settings, allowing designated DApp accounts to initiate some transactions on your behalf, completely eliminating the need for repeated signature prompts in traditional blockchain applications.

What a powerful capability! This is also why almost all mainstream wallets, such as OKX Wallet, Metamask, WalletConnect, Biconomy, BaseWallet, Rhinestone, ZeroDev, TrustWallet, Safe, and related teams are quickly responding to support it.

Is EIP-7702 the Ultimate Form of Account Abstraction?

Yes, because this time users will choose it!

It is not that EOA is not good; objectively speaking, EOA is straightforward and secure. However, after the Prague upgrade, EOA will be even better due to cost and experience. When Jobs pulled the iPhone out of his jeans pocket, those experiences were things users had not initially thought could be done this way.

Account abstraction is an area that many chains are exploring and actively trying. For example:

1. Starknet, as a ZK-Rollup (Layer 2), has contract accounts as its default accounts, without EOAs.

2. zkSync Era uses AA accounts as the default method and does not require the complex bundler process.

3. Nervos CKB, similar to the UTXO model, also allows all accounts to customize their validators, separating ownership from control.

4. Aptos / Sui, as significant players in Move-based Layer 1, although not EVM-style AA, also possess account customization capabilities, allowing for modular signatures, multi-signatures, etc.

5. EVM ecosystems like Linea / Base / Mantle / Polygon / Arbitrum / Optimism have not only completed AA support through ERC-4337 but will also follow up with the EIP-7702 upgrade, just like the Ethereum mainnet.

The infrastructure related to wallets and AA is also comprehensively paving the way for EIP-7702.

From the core experience optimization of EIP-7702: batch transactions, gas abstraction (i.e., gasless solutions), and account custody, services like Coinbase, Metamask, Biconomy, Zerodev, Rhinestone, Ithaca, etc., fully support these.

These are also adaptations further completed from the era of ERC-4337, which is a significant advantage of EIP-7702. Ultimately, the account entity is a form that belongs to both EOA and CA, allowing a large number of previously existing infrastructures around AA to migrate and adapt.

Now, let us use a table to illustrate the final effect layer differences between EOA, ERC-4337, and EIP-7702.

Objectively speaking, the Ethereum system carries a much heavier historical burden than other chains. This is the reason for the recent community voices opposing Vitalik's changes to the EVM virtual machine and also the reason for the early choice of ERC-4337. However, once a better option (EIP-7702) is available that can achieve compatibility with historical burdens and excellent cost optimization, users will welcome their "iPhone moment."

With the transformation of the underlying form, derivative forms can be further envisioned, such as:

• Users can use Passkey or Google Account to control their wallets, achieving conditional signature-free experiences.

• Users can set up ZKEmail and other methods to enable recovery capabilities, allowing them to retrieve their private keys.

• For large on-chain operators, integrating multiple transactions into one can significantly reduce block waiting times, making on-chain swaps faster, and through continuous transactions, reduce the risk of transaction failures.

Time has a huge impact on user experience. As the second-ranked consensus system in the entire blockchain world (second only to BTC), ETH cannot simply reduce block time from 3 seconds to 1.5 seconds like BSC to enhance user experience. Therefore, wallet tools based on EIP-7702 are the most important bridge for user experience.

Thus, combining our previous discussions on the underlying aspects, we can say that EIP-7702 is the ultimate form of account abstraction!

However, it is unlikely that all users will fully adopt it in the future, as its application needs to be cautious. Once complex intelligence is integrated, it can also bring numerous security risks, and some attack methods can be very subtle. Therefore, after the activation of the Ethereum Prague upgrade on May 7, 2025, what users need most is a truly secure wallet, with technical expertise to safeguard their assets.

Has the Final Battle Ended?

No.

Indeed, Pectra is the most ambitious upgrade Ethereum has undertaken to date, encompassing 11 EIPs, the highest number in history! We have seen many benefits of EIP-7702, and we have provided judgments through the principles and data discussed above.

However, it is precisely after user participation and choice that the market will usher in a chaotic battle.

The ecosystem of AA is continuously evolving and has gradually shown signs of fragmentation. Among the frameworks defining account abstraction, there are already interface standards like ERC-4337, ERC-6900, and ERC-7579, but there are significant differences in user experience, interface specifications, and behavioral expectations among different implementation solutions. Different wallet implementation solutions focus on similar application scenarios and limited core functionalities, but each adopts incompatible design assumptions and implementation logic.

One of the most typical hidden issues is the disorder of storage.

After the launch of EIP-7702, the storage space under EOA accounts becomes usable by contracts, and this storage space is not exclusively owned by a single contract but may be shared among multiple smart account providers.

When a user initiates a "re-delegation" operation, the original account contract will be replaced by the new contract. However, the state data written by the old contract will not be cleared and will remain in the storage of that EOA. This means that the new proxy contract can access or even modify the storage data written by the old contract, introducing the risk of "storage pollution" (see Reference 2), which may interfere with or even disrupt the execution logic of the current contract.

Although various solutions have emerged in the community, such as isolating storage through namespaces (ERC-7201) to reduce the impact of storage chaos, there is still a lack of mandatory unified standards in the current ecosystem to ensure the uniqueness and security of nonces.

Another typical issue is the disorder of execution standards.

As revealed in this article: "From Fragmentation to Unity: The Necessity of Standardizing Smart Accounts" (see Reference 3).

Currently: Safe, Biconomy, and ZeroDev have each implemented their versions of batch calling functions, but the function names, interface parameters, and result handling methods of the three are all different. Among them, ZeroDev considers the situation of batch call failures, while Safe and Biconomy do not handle such scenarios.

The industry's standard of "each for themselves" approach inevitably leads to a chaotic battle. Users, DApps, and developers are all victims in this situation. Therefore, the launch of EIP-7702 is not only a technological innovation but also an opportunity to establish a universal infrastructure for smart accounts. It provides us with a window to "reconstruct consensus," promoting the entire Web3 wallet ecosystem from diverse functionalities to structural unity, achieving true sustainable development.

Three Essential Security Understandings After EIP-7702 Activation

Now, let us switch perspectives and look at this system from the viewpoints of users, DApps, exchanges, and other organizations, comprehensively assessing how it affects us. It will bring opportunities but also risks; only by understanding the risks can we better enjoy the benefits this system brings.

Can I Not Upgrade EIP-7702 Because It’s Complex?

Of course, you can choose not to upgrade actively, but there is a risk you need to be aware of. After the Prague upgrade, a message signature of yours could inadvertently put you in danger.

Indeed, EIP-7702 has a strong phishing risk because its Authorization parameters consist of: address, nonce, and chainid. If the chainid is 0, this signature authorization can also be effective on any chain as long as the nonce is satisfied.

Through the specific implementation of the 7702 process in OKX's open-source signing SDK, we can see that to comply with this standard, the final hash value signed by the user is: 0xabc, calculated as follows:

Here, keccak is the mainstream hashing algorithm on Ethereum, characterized by being able to produce a fixed 32-byte length result from data of any length. RLP is a set of information encoding methods, and the Magic is a fixed value.

However, since the final result is a hash value that does not reveal specific content, if users hastily sign a message and others can carry your authorization on-chain, they may unknowingly set the code, leading to a 0-day level attack event. Moreover, since setting the code is mandatory, you cannot assume that a previously set secure contract will not be replaced.

Thus, secure wallets will prohibit users from signing arbitrary hash values, as hash values could also represent a regular transaction.

How to Protect Yourself If You Accidentally Upgrade to a Risky Contract?

This risk is also quite common, as it is impossible to ensure that one will never be phished.

To guard against this issue, it is essential to understand a technical background: in the Ethereum system, transactions must be processed in nonce order; only by maintaining continuity can they be recognized on-chain.

Thus, there are two types of attack methods.

• The first scenario is that a hacker steals the next nonce value of your current address to sign the Authorization. The solution is straightforward: if you are attacked, quickly use a wallet that allows customizable Gas fees, such as OKX Wallet or other secure wallets, to swiftly transfer ETH (to another secure address of yours). This action can transfer funds at the ETH level while also replacing the effective nonce value, rendering the hacker's authorization ineffective.

• The second scenario is that the hacker steals a subsequent nonce value. In this case, your current Transfer may inadvertently validate the hacker's Authorization. Since you cannot determine what the nonce is, no operation can guarantee absolute security. You can only quickly transfer assets to protect yourself.

From this perspective, it seems that EIP-7702 is more dangerous? Not necessarily!

In a blockchain system that truly returns user sovereignty to the ownership of user private keys, any random signature can lead to financial loss. However, the key point is that aside from large users being targeted for poisoning, most risks arise because users often need to use their important private keys.

If you have already implemented the combined functionality of family accounts and personal sub-accounts through AA, and set usable limits for each sub-account, then your main account only needs to be invoked when modifying system-level settings, while regular daily use can be handled by small accounts.

Why Do Some Common Transactions Fail After Upgrading?

This situation often occurs in wallet tools that do not support EIP-7702.

First, let’s provide a technical background: during contract calls on Ethereum, the system first checks the code field of the user's current address. If there is content, it will execute the corresponding logic through its default accepting function.

Based on this, for ordinary users, if I complete the EIP-7702 contract setup, it will generally have the functionality of a default accepting function. Therefore, any ordinary ETH Transfer transaction will execute some contract logic, increasing overall Gas usage. If your ordinary transaction's Gas Limit is set to 21,000, it will naturally fail.

Similarly, many NFT projects check whether the receiving address is a black hole address (i.e., an address that cannot transfer out assets) to prohibit transactions. Therefore, if your accepting function is not handled properly, it may lead to the inability to accept ERC20 and ERC721 assets, resulting in losses.

In this regard, it is recommended to set up using wallets that explicitly support EIP-7702 or to use logically secure contracts that have been well-audited and approved by users.

What Other Changes Does the Ethereum Mainnet Pectra Bring?

There are many voices in the market suggesting that Ethereum seems to have lost its way. Why do many upgrades not seem to matter to users? Is this really the case? Let us look at other EIPs from this upgrade to find answers. Indeed, EIP-7702 represents the most significant upgrade change that users can feel, but the other 10 EIPs also bring changes to the Ethereum ecosystem from different dimensions.

First, in terms of cryptographic support, EIP-2537 introduces precompiled operations for the BLS12-381 elliptic curve, optimizing complex cryptographic operations like BLS signature verification, providing higher security (120+ bits of security) and computational efficiency (Gas optimization).

In terms of staking scenarios, there are multiple optimization points. Objectively speaking, staking does need optimization. The Ethereum validator cluster has grown rapidly, with nearly a million validator staking addresses. This is due to the MAXEFFECTIVEBALANCE being limited to 32 ETH, requiring node operators to create multiple validator accounts to manage larger staking assets, leading to a large number of "redundant validators." Therefore, EIP-7251 raises the maximum limit, allowing protocols like Lido to reduce the number of controlling accounts and decrease system complexity, but this may exacerbate centralization issues, making the ETH staking market more concentrated.

After this upgrade, larger node operators can merge multiple validator accounts while providing more flexibility for smaller validators, such as accumulating compound returns or more flexible staking increments to increase yields. This is very important; originally, after reaching 32 ETH, if you generated 10 ETH in returns, you would not continue to stake ETH because you would need to gather another 32 to open a new account. However, after this update, you can directly stake 42 ETH. Thus, your compound returns can return to the ETH system, providing user experience convenience and hinting at a reduction in ETH liquidity.

Finally, there is a significant optimization for the L2 ecosystem. Ethereum has always firmly walked the path of the L2 ecosystem community. Other SVM-based and MOVE-based chains are essentially still developing their L1s, and even exploring their L2s has certain contradictions and conflicts, as the high performance of these chains does not heavily rely on developing L2.

To encourage more efficient interactions between L2 and the Ethereum mainnet, EIP-7623 increases the gas fees for calldata in transactions from 4/16 gas per byte to 10/40 gas, compelling L2s to avoid using calldata and instead utilize Blob more.

Additionally, EIP-7691 increases the capacity of blobs in blocks, supporting larger-scale L2 storage space. In the previous Cancun upgrade, there were two core parameters representing blobs: target and max, indicating the target number of blobs per block and the maximum number of blobs per block.

In Cancun, these parameters were 3 and 6; now, after Prague, they have changed to 6 and 9, indicating an expansion.

Thus, Ethereum enhances itself through the TPS of L2. Although there are many issues, such as liquidity dispersion, cross-chain complexity, and emergency escape capacity, the current Pectra upgrade allows Ethereum to add a "highway" for L2. However, how to solve "traffic management" and "different toll standards" is the fundamental issue.

Glimpsing the Future

This article has nearly ten thousand words, starting from the roots of account abstraction development to the two routes represented by ERC-4337 and EIP-7702, and then delving into the principles and mechanisms of EIP-7702, analyzing its advantages and adjustments in mainstream user scenarios.

I believe that "Not your keys, Not your money" is a great concept. EIP-7702 does not overturn it but rather complements and perfects it from another dimension, allowing it to possess both sovereignty and usability. As Ethereum Foundation researcher Yoav Weiss said, "The next billion users will not write 12 words on paper."

Through the comparison of the two, it can be said that EIP-7702 significantly optimizes ERC-4337, providing users with space and flexibility, making it easier for users to recognize and use it in the subsequent market. Once users begin to adopt CA as the on-chain entity, complex transaction types will emerge in large numbers on EVM-based chains.

Thus, we glimpse the shadows of the future. With the richness of underlying account entities and transaction types, many previously bottlenecked application experience issues will also be resolved, no longer forcing users to understand concepts like Nonce and Gas, but rather simplifying the processing through wallet and other entry service tools.

Although facing industry-level diversity brings a certain degree of interface standardization and storage space disorder, I am also optimistic that the more valuable the chaos, the more likely it is to carve out a unified standard. The decentralized multi-faceted competition will ultimately promote the development of the industry. Therefore, after the launch of EIP-7702, it will not immediately ignite the ecosystem on Ethereum, as it is a spiral upgrade of the technological foundation. Such upgrades often lead market applications by 2-3 years, allowing time for the application layer to gradually ferment.

Moreover, starting from this upgrade, user security will increasingly depend on the service quality of entry tools. Open-source and openness are crucial steps in providing users with a sense of security. Therefore, the underlying SDK implementation of EIP-7702 integrated by OKX Wallet is also open-sourced, publicly accepting community and market scrutiny. Many wallets maintaining openness are moving further along the path of self-custody, providing users with absolute autonomy through the fairness of open-source.

Finally, returning to the Pectra upgrade itself, we can once again see Ethereum's reflections and persistence on future directions. Today, the L2 strategy has entered a stable execution phase. The Ethereum roadmap has undergone many changes in detail over the past decade, but the core goal has surprisingly remained consistent: to have a secure, decentralized, green (POS) blockchain that is both highly scalable and easy to verify. Proposals like EIP-7702, which effectively enhance user experience, introduced through hard forks, represent Ethereum's ongoing exploration of how to enhance competitiveness among multi-chains while ensuring decentralization (even in the face of strong competition from new-generation public chains like Solana) and how to become the ideal supercomputer!