Original author: shisilu
Original source: OKX Research Institute
Pectra is the first major upgrade of Ethereum after Dencun, covering the Prague execution layer hard fork and the Electra consensus layer update, integrating the 11 EIPs, the largest number in history, significantly improving the flexibility of validators, network scalability and execution efficiency. With the Ethereum mainnet Pectra hard fork expected to be officially activated on May 7, 2025, the ultimate form of Account Abstraction - EIP-7702, has also officially entered the public eye!
If there are any EVM-based Web3 wallets that do not support EIP-7702, then there is no doubt that they have given up the entire Ethereum ecosystem and users. This is the determination of Vitalik and EF, and it is also the prelude to the opening of Pandoras Box! At present, in order to support the Ethereum ecosystem, OKX Wallet has taken the lead in supporting Ethereums latest account abstraction standard EIP-7702, and has opened an official entrance for users who are willing to try it out. You can upgrade through [OKX Wallet Home Function Area-More-7702 Upgrade] to experience the safe and professional EIP-7702. Warm reminder: You can choose to upgrade and experience as needed. Not upgrading will not affect the normal use of the existing ecosystem and applications. To ensure the safety of assets, be sure to operate through official channels, beware of phishing links and malicious websites, and avoid risks to assets.
Please follow this article to fully understand the evolution of account abstraction, the user value and market changes brought about by EIP-7702, and the hidden dangers.
Overview
The code involved in this article is located in okx/js-wallet-sdk . The EIP-7702 SDK implementation used by OKX Wallet is open source to community partners.
EIP-7702 adds a new transaction type that allows ordinary EOA to set a contract address as its logical proxy contract.
EIP-7702 will fully inherit and surpass the ecosystem built by ERC-4337 over the years due to its cost advantage and flexibility.
EIP-7702 is also an invisible risk for ordinary users. Even if users do not upgrade, it may cause transaction failures or security asset loss risks in certain scenarios.
EIP-7702 will bring a brand new user experience. When the user body undergoes contractual migration, market applications will also evolve accordingly. The long-awaited smooth experience of gas abstraction, family tiered accounts, etc. will lead one billion people to enter the Web3 world at a low cost.
For exchanges and DApps, applying the features of EIP-7702 will bring more than 50% cost reduction, allowing them to fully embrace the era of contract accounts.
Why do accounts need to be abstract?
It’s hard to imagine that the vision of account abstraction even predates Ethereum itself.
At the HK Web3 Carnival, Vitalik repeatedly emphasized that through a series of solutions such as multi-sig, account abstraction, and ZK Email, Ethereum has achieved 50% of its iPhone moment goal.
Is it fast or slow, optimistic or limited? Lets go deep into the bottom and see why AA has such an influence! After all, after 10 years of running, Vitalik finally ushered in the end of his dream in the field of AA, adding a strong stroke to the progress bar of the Ethereum roadmap drawn in 23 years.
What is account abstraction for?
In fact, what is essentially solved is the problem of separation of property rights , because the ownership and signing rights of EOA (Externally Owned Account) are actually held by the same individual unit (both rely on private keys to control any instructions). The root of this problem comes from the transaction structure of Ethereum. In fact, there is no From party in Ethereums standard transactions. During execution, the From address is deconstructed through its VRS parameter (ie user signature).
Moreover, Ethereum is designed as a world-class state machine that completely relies on transactions to implement changes in on-chain status. Combined with the inability to specify the From party, the execution authority of the transaction is coupled with the highest ownership.
This is the root of a series of problems that make EOA easy to understand but difficult to use:
Private keys are difficult to protect: If a user loses his private key (due to loss, hacker attack, quantum cracking), it means losing all assets.
There are few signature algorithms, and different signature algorithms bring different performance losses and even the cost of on-chain storage.
The signature authority is high, and the EOA native private key has all these rights.
The transaction fees for complex transactions are high and can only be paid via ETH. Any transaction or a single operation requires a basic fee of at least 21,000.
There is no privacy in transactions. Even though there was a confidential ERC-20 protocol proposed by Circle, it has not become mainstream.
Ultimately, todays blockchain world is too complicated for users entering and exiting it. Users need to understand concepts such as Gas price, Gas limit, and transaction blocking (Nonce order), and hide complex information from regular users. This is the problem that EIP-7702 ultimately aims to solve.
What are the core differences between ERC-4337 and EIP-7702?
There are actually more than ten different proposals around AA, which I have explored before. In fact, after sorting out the overall situation, there are essentially two routes:
Route 1: Let the EOA address drive the CA address
ERC-4337 is a typical example in this regard. It can be summarized in one sentence: a new transaction object UserOperation is proposed, and the user sends this object to the memory pool, batches instructions in the form of bundlers, and executes transactions one by one through delivery contracts. In essence, it pulls the underlying transactions and account operations to the contract level for execution.
The execution principle is as follows:
Through the role of bundler, it can be said that this solution can solve problems such as batch transactions, gas-free, fewer signature algorithms, etc. However, it cannot solve the complexity and user transaction costs, as well as the single point failure risk of bundler and EntryPoint.
Because once the user migrates to ERC-4337, even if the demand of user 2 in the above figure is just to make a Transfer transaction, the user transaction fee will double compared to EOA.
From the latest user data of CA and EOA, we can see that even if some users are high-end players, they are very dependent on various operations based on the on-chain CA, such as batch calls, etc. But if this is the case, why not just use ordinary CA?
The design of bundler allows it to avoid hard fork-level upgrades and be launched directly on the application layer, but ERC-4337 also brings double the cost of single point failure risk, and users also lose the original flexibility of EOA. Therefore, in the face of diverse user needs, it is obvious that users in the current market are not so fond of the ERC-4337 solution. The overall trend has dropped significantly in the past two years of development, even the peak number of users is far from the number of independent addresses of Ethereum, which is 300M.
Of course, we are not criticizing the shortcomings of ERC-4337. Rather , the roles and concepts such as Paymaster and Gas abstraction developed on it along with its development are actually being applied again in EIP-7702.
The author believes that the development of any industry will not happen overnight. What is important is to discover patterns and summarize experiences from past ups and downs.
Route 2: Change the EOA address to a CA address
In fact, as early as November 2015, Vitalik proposed EIP-101, which uses contracts as a new structure for accounts. The address was changed to only have code and storage space, the handling fee was changed to support payment by ERC 20, and the native token was changed to ERC 20-like to store the balance through pre-compiled contracts (with functions such as deduction authorization). In January 2018, there was another EIP-859 plan. The core function was to use the code parameter attached to the transaction to execute the contract wallet deployment if the transaction partys contract was not deployed. Finally, EIP-7702, which was further deduced from the EIP-3074 plan, was finally included in the Ethereum mainnet!
The concept and effect of EIP-7702 are actually very simple. It completes the initialization through a new transaction type. Later, users can allow EOA to temporarily and optionally have the function of a smart contract in a single transaction, thereby supporting batch transactions, gas-free transactions, and custom permission management in business. The most critical capability is to allow users to have temporary and optional space.
Moreover, multiple people can share the same logic contract, thereby greatly reducing the cost of user migration. To complete the setting of EIP-7702, users only need 8 W of Gas, which is approximately US$0.06. To set up a new contract or cancel the setting of the logic contract, only 4 W of Gas is required.
After completing the settings, it can significantly bring users a significant gas optimization during batch transactions. See the table below:
Of course, you may think, is it necessary to do two or even six token transfers?
Conventional users are used to doing one thing at a time, so it seems that there are not many scenarios. However, in diversified application scenarios such as Web3 Game and Web3 Pay, it actually happens very often, such as using copper coins (currency generated in the game) and silver coins (user recharge currency) together for consumption. Or participating in an event and consuming NFT tickets and entrance fees at the same time.
Even if we don’t imagine complicated scenarios and return to the most mainstream Swap demand on the chain today, there is also a demand for approval and transfer batches. Even now, we can make a small tool to simply help users quickly delete their useless approval authorizations. The effect is easy to compare, and obviously, the cost can be directly reduced by about 40%.
The core principle of EIP-7702
To explore why this effect occurs, we need to return to its principle. In fact, its core is two logics, which are divided into user settings and daily use.
Setting up the logical contract
The core process is as follows:
Step 1: Signature authorization. Use the original EOA private key to sign a special hash string. The content is composed of encoded chain_id, address, and nonce. Here, Address is the address of the logical contract to be set in the end, and Nonce is a strategy to ensure that the transaction is not replayed.
Step 2: Sign the transaction. With the authorization information from the first step, anyone can construct a transaction of type 4, which can contain multiple authorization information and perform authorization settings for multiple addresses at one time.
Step 3: Broadcast on the chain. Then when the transaction completes the internal authorization, the logical contract will be effective.
There are more technical details here, you can refer to: okx open source js sdk implementation to see the underlying data encoding process. Of course, this solution actually also hides some security risks and complexities, which we will explain in detail below.
Execution of logical contract
Once you have completed the settings, when any transaction To address points to you, it will be the same as calling a smart contract . The system will load the code of the logic contract you originally set into the state of your current EOA to execute its logic.
We also use 2 scenarios to view:
The first one is that you call yourself
If you set up a highly secure and customizable contract like the OKX 7702 Smart Contract, you can specify the pre-written calldata to allow your current operation to complete multiple instructions at once. For example, you can complete Approve+Transfer or Approve+Swap at the same time.
Don’t underestimate it. Among the total 2.7 billion Ethereum transactions, there are about 75M Approve transactions. Calculated at 8W Gas per transaction, 46W ETH are consumed. Calculated at the ETH market price of 1,700 US dollars, it is close to 800 million US dollars.
The second is when someone calls you.
In the past, Ethereum did not have the situation where someone else called the EOA address, but now you are a universal contract that can be fully customized. You can open sub-accounts and assign permissions, or you can set up a whitelist for a few Paymasters and allow designated accounts of DApp to initiate some transactions on your behalf, thus completely eliminating the dilemma of repeatedly popping up signatures in traditional blockchain applications.
What a powerful capability! This is why almost all mainstream wallets: OKX Wallet, Metamask, WalletConnect, Biconomy, BaseWallet, Rhinestone, ZeroDev, TrustWallet, Safe and other related teams are responding quickly to support.
Is EIP-7702 the end of account abstraction?
Yes, because this time users will choose him!
It’s not that EOA is not good enough. Objectively speaking, EOA is concise, simple and safe. But after the Prague upgrade, EOA will be better after the introduction of EIP-7702. Because of the cost and the experience. When Jobs took out the iPhone from his jeans pocket, those experiences were things that users didn’t expect at first, that they could play like this.
Account abstraction is actually an area that many chains are exploring and actively trying. For example:
Starknet, as a ZK-Rollup (Layer 2), its default accounts are all contract accounts and there is no EOA.
In zkSync Era, using AA accounts is the default method, and there is no need for the complicated steps of Bundler.
Nervos CKB is similar to the UTXO model, but it also allows all accounts to customize the validators used, stripping away the rights of ownership and control.
Aptos/Sui, as an important role in Layer 1 of the Move system, although not an AA in the EVM mode, also has the ability to customize accounts, allow modular signatures, multiple verifications, etc.
EVMs Linea/Base/Mantle/Polygon/Arbitrum/Optimism, these related ecosystems, have not only completed AA support through ERC 4337, but will also follow up on the EIP-7702 upgrade like the Ethereum mainnet.
The infrastructure in wallet and AA-related fields is laying the foundation for EIP-7702 in a more comprehensive way.
It optimizes the core experience of EIP-7702: batch transactions, Gas abstraction (i.e. Gasless and other gas-free solutions), and account custody. Service providers such as Coinbase, Metamask, Biconomy, Zerodev, Rhinestone, Ithaca, etc. fully support these.
These are all further adaptations from the ERC-4337 era, which is also a major advantage of EIP-7702. In the end, the account entity is a form that belongs to both EOA and CA, so a large amount of infrastructure that once revolved around AA can be migrated and adapted.
Now let’s use a table to reflect the differences in the final effect layer between EOA, ERC-4337, and EIP-7702.
Objectively speaking, the Ethereum system has a much heavier historical burden than other chains. This is the reason why the community recently opposed Vitaliks changes to the EVM virtual machine, and it was also the reason why ERC-4337 had to be chosen in the early days. However, once there is a better choice (EIP-7702) that can achieve compatibility with historical burdens and excellent cost optimization, users will usher in the iPhone moment.
With the transformation of the underlying form, the derived forms can be further imagined, such as
Users can use Passkey or Google Account to control their wallets, and implement features such as conditional visa exemption.
Users can implement recovery capabilities and retrieve private keys by setting up ZKEmail and other methods.
For large-scale on-chain operators, integrating multiple transactions into one can significantly reduce block waiting time, making on-chain swaps faster, and reducing the risk of transaction failures through continuous transactions.
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 arbitrarily reduce the block time from 3 s to 1.5 s to improve user experience like BSC. Therefore, the wallet tool based on EIP-7702 is the most important bridge for user experience.
Therefore, combined with our previous discussion on its underlying layer, it can be said that EIP-7702 is the ultimate form of account abstraction!
However, it is unlikely that all users will use it in the future, because its application needs to be cautious. After integrating complex intelligence, it actually brings a lot of security risks, and some attack methods are even very obscure. Therefore, on May 7, 2025, after the Ethereum Prague upgrade is activated, what users need most is a truly secure wallet, with technical expertise to protect it.
Is the Endgame over?
No.
Indeed, Pectra is the most ambitious upgrade of Ethereum so far, covering 11 EIPs, the largest number in history! And we have seen the many benefits of EIP-7702, and have also made judgments based on the principles and data above.
But it is after users participate in the selection that the market will usher in a chaotic battle.
The AA ecosystem has gradually shown a fragmented trend in its continuous development. Among them, the EIP that defines account abstraction from the framework has interface standards such as ERC-4337, ERC-6900, and ERC-7579, but there are obvious differences in user experience, interface specifications, and behavioral expectations between different implementations. Different wallet implementations focus on similar application scenarios and limited core functions, but each adopts incompatible design assumptions and implementation logic.
One of the most typical hidden problems is storage disorder.
After the introduction of EIP-7702, the storage space under the EOA account becomes available for use by contracts, and this storage space is not exclusive to a single contract, but may be used by multiple smart account providers.
When a user initiates a re-delegation operation, the original account contract will be replaced by a new contract. However, the state data written by the old contract will not be cleared and will remain in the storage of the EOA. This means that the new proxy contract can access or even modify the storage data written by the old contract, which introduces the risk of storage pollution and may interfere with or even destroy the execution logic of the current contract.
Although there are many solutions in the community, such as isolating storage through namespace (ERC-7201) to reduce the impact of storage chaos, no matter which solution is adopted, there is still a lack of mandatory unified standards in the current ecosystem to ensure the uniqueness and security of nonce.
Another typical problem is the disorder in the implementation of standards.
As revealed in this article: From fragmentation to unification: the need for smart account standardization
Today: Safe , Biconomy and ZeroDev have all implemented their own versions of the batch call function, but the function naming, interface parameters and result processing methods of the three are different. Among them, ZeroDev considers the situation where the batch call fails, while Safe and Biconomy do not handle such scenarios.
The industrys separate approach of standards will inevitably lead to a chaotic war. Users, dApps, and developers are all victims. 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 of reconstruction of consensus, promoting the entire Web3 wallet ecosystem from functional diversity to structural unification, and achieving true sustainable development.
After EIP-7702 is activated, three essential security understandings
Now, let us switch to different perspectives and look at this system from the perspectives of users, DApps, exchanges, and other organizations to see how it affects us. It will bring opportunities as well as risks. Only by understanding the risks can we enjoy the benefits of this system more perfectly.
Eip-7702 is very complicated. Is it okay if I don’t upgrade?
Of course, you can choose not to upgrade proactively, but there is a risk you need to be aware of. After the Prague upgrade, one of your message signatures may inadvertently put you in danger.
It is true that EIP-7702 has a strong phishing risk because its Authorization parameters are composed of: address, nonce, and chainid. If the chanid is 0, the signature authorization can take effect on any chain as long as the nonce is met.
From the specific implementation of the 7702 process in the OKX open-source signature SDK, we can see that in order to comply with the standard, the user ultimately signs a hash value: 0x abc, which is calculated as follows:
Keccak is the mainstream hash algorithm on Ethereum, which has the characteristic that any length of data can be calculated to a fixed length of 32 bytes. RLP is a set of information encoding methods, and Magic is a fixed value.
However, since the final result is a hash value whose specific content cannot be understood, if a user signs a message carelessly, and someone else can also carry your authorization to the chain to take effect, then you will be set with a code unconsciously, thus triggering a 0-day attack. And since setting a code is mandatory, you cannot assume that you have set a secure contract and it will not be replaced.
Therefore, secure wallets will prohibit users from signing an arbitrary hash value, and this has been the case before (because the hash value may also represent an ordinary transaction).
How can I protect myself if I mistakenly upgrade a risky contract?
This risk is also very common. After all, there is no way to ensure that you will not be phished at all.
To prevent this problem, we must first understand the technical background that transactions in the Ethereum system must follow the nonce sequence, and only if they remain continuous can they be recognized on the chain.
Therefore, there are 2 types of attacks.
The first case is that the hacker stole the next nonce value of your current address to sign the Authorization. The handling is also very simple. If you are attacked, please quickly use a customizable Gasfee wallet, such as OKX Wallet or other secure wallets, to quickly transfer ETH (to other secure addresses of yours). This action can transfer funds at the ETH level on the one hand, and replace the valid nonce value on the other hand, thereby invalidating the one in the hands of the hacker.
The second situation is that what the hacker stole may be a subsequent nonce value. In this case, it is possible that your current transfer will make the authorization in the hackers hands valid. Since you are not sure what the nonce is, no operation can lead to absolute security. You can only transfer assets as soon as possible to protect yourself.
So it seems that EIP-7702 is more dangerous? Actually not!
For a system like blockchain, which truly returns user sovereignty to the users private key, random signing at any time will lead to financial loss. But the key here is that, apart from the situation where large users are targeted and poisoned, most of the risks arise because users often have to use important private keys.
If you have already realized the combined function of family accounts and personal sub-accounts through AA, and set the available limit for each sub-account, then basically your main account only needs to be called up when modifying system-level settings, and for regular daily use, only the small account is needed to solve the problem.
Why do some common transactions fail after the upgrade?
This often happens in wallet tools that do not support EIP-7702.
First, let me add a technical background. During the contract call process on Ethereum, the code field of the users current address will be checked first. If there is content, it will go through the default accepted functions to execute the corresponding logic.
Based on this, for ordinary users, if I complete the EIP-7702 contract settings, there will basically be a default accept function, and any ordinary ETH Transfer transaction will execute some contract logic, thereby increasing the overall Gas use. If you set the Gas Limit for ordinary transactions to 21,000, then it will naturally fail.
Similarly, since many NFT projects will detect whether the recipient address is a black hole address (that is, an address that cannot transfer assets) and thus prohibit transactions, if your acceptance function is not handled properly, it will also cause ERC 20 and ERC 721 assets to be unacceptable and lost.
In this regard, it is recommended to set it up through a wallet that explicitly supports EIP-7702, or use a logic contract that has been audited and recognized by users, such as: https://github.com/okx/wallet-core
What other changes are there to Ethereum mainnet Pectra?
There are many voices in the market that think Ethereum seems to be lost? Why do many upgrades have nothing to do with users? Is this really the case? Lets take a look at other EIPs in this upgrade to find the answer. Chen Ran, EIP-7702 is the biggest upgrade change that users can feel, but there are 10 other EIPs that bring changes to the Ethereum ecosystem in different dimensions.
First of all, in terms of cryptographic support, EIP-2537 introduces the pre-compilation operation of the BLS 12-381 elliptic curve, which can optimize complex cryptographic operations such as BLS signature verification, and provide higher security (120+ bit security) and computational efficiency (Gas optimization).
There are many optimization points for the staking scenario. Objectively speaking, staking does need to be optimized. Ethereums validator cluster has been growing rapidly, with nearly one million validator staking addresses. This is because MAX_EFFECTIVE_BALANCE is limited to 32 ETH, and node operators need to create multiple validator accounts to manage larger staked assets, which leads to the existence of a large number of redundant validators. Therefore, the maximum limit is increased through EIP-7251. For aggregated staking protocols such as lido, the number of controlled accounts can be reduced and the complexity of the system can be reduced, but this may aggravate the decentralization problem and make the ETH staking market more centralized.
After this upgrade, larger node operators can merge multiple validator accounts, and it also brings more flexibility to small validators, such as increasing income through compound interest accumulation or more flexible staking increments. This is very important. Originally, after 32 ETH was reached, if you generated 10 ETH of new income, you would not continue to stake ETH, because you still need to get 32 to open a new account. But after this update, you can directly stake 42 ETH. Then obviously your compound interest income can return to the ETH system, which has the convenience of user experience and a certain foreshadowing of reducing ETH liquidity.
Finally, the L2 ecosystem has been greatly optimized. Ethereum has always been firmly on the road to the L2 ecological community. Other SVM and MOVE systems are essentially still developing their own L1, and even exploring L2 on top of them has certain contradictions and conflicts. The root cause is that the high performance of these chains is relatively less dependent on L2.
In order to encourage more L2 to interact efficiently with the Ethereum mainnet, EIP-7623 has been used to increase the gas fee of calldata in transactions from 4/16 gas per byte to 10/40 gas. This forces L2 not to use calldata, but to use Blob more.
EIP-7691 is also used to increase the capacity of blobs in blocks to support larger L2 storage space. In the previous Cancun upgrade, there were two core parameters representing blobs, target and max, which were used to indicate the target number of blobs per block and the maximum number of blobs per block.
In Cancun, the parameters were 3 and 6, and now after Prague, the parameters have become 6 and 9. In short, the capacity has been expanded.
Therefore, Ethereum uses L2s TPS to improve Ethereum itself, although there are many problems, such as dispersed liquidity, cross-chain complexity, emergency escape capacity, etc. Therefore, in the current Pectra upgrade, Ethereum is adding highways to L2, but how to solve traffic management and charge standards for different highways in the future is the most fundamental problem.
A glimpse into the future
This article is nearly 10,000 words long. We start from the development roots of account abstraction, and then go to the two routes represented by ERC-4337 and EIP-7702 and their comparison. We then delve into the principles and mechanisms of EIP-7702, and analyze its advantages and disadvantages and adjustment effects on mainstream user scenarios.
The author believes that “Not your keys, Not your money” is a great concept. EIP-7702 is not to subvert it, but to complement and improve it in another dimension, making it both sovereign and easy to use. As Yoav Weiss, a researcher at the Ethereum Foundation, said, “The next billion users will not write 12 words on paper.”
Then through the comparison between the two, it can be said that it has significantly optimized ERC-4337, giving users space and flexibility, so that it is easier to be recognized and used by users in the subsequent market. Once users begin to use CA as the on-chain entity, complex transaction types will emerge in large numbers on the EVM chain.
From this, we can see the shadow of the future. With the enrichment of underlying account entities and transaction types, many application experience problems that were once bottlenecks will also be solved. Users will no longer be forced to understand the logic of Nonce, Gas, etc., but will be simplified by entry service tools such as wallets.
Although facing the diversity of industry levels, which brings a certain degree of disorder in interface standards and storage space, the author is also optimistic that the more valuable the chaos is, the more likely it is to create a unified standard, and decentralized multi-game will eventually promote the development of the industry. It is for this reason that after EIP-7702 is launched, it will not immediately detonate the ecosystem on Ethereum, because it is a spiral technical upgrade. Often, such upgrades will be 2-3 years ahead of market applications, leaving it for the application layer to gradually ferment.
Moreover, starting from this upgrade, user security will be more dependent on the service quality of the entry tool layer. Open source is an important step to give users a sense of security. Therefore, the EIP-7702 underlying SDK implementation integrated by OKX Wallet is also open source , open to the test of the community and the market. There are also many wallets that maintain openness and are going further and further on the road of self-custody, giving users absolute autonomy with the fairness of open source.
Finally, going back to the Pectra upgrade itself, we can once again see Ethereums thinking and persistence on the future direction. Now that the L2 grand strategy has entered a stable execution period, Ethereums roadmap has undergone many changes in details in the past decade, but the core goal has always been surprisingly consistent: to have a secure and decentralized green (POS) blockchain that is both highly scalable and easy to verify. The introduction of AA proposals such as EIP-7702 that effectively improve user experience from the hard fork represents Ethereums constant exploration of how to improve the competitiveness of multiple chains while ensuring decentralization (even in the face of competition from new generation public chains such as Solana), and how to become an ideal supercomputer!
References:
