The final stage of the 10-year evolution of account abstraction: looking at the past and the future through EIP-7702

Author: shisilu, Source: okx

Pectra is the first major upgrade of Ethereum after Dencun, covering the Prague execution layer hard fork and Electra consensus layer update, integrating the 11 EIPs, the largest number in history, significantly improving validator flexibility, network scalability and execution efficiency. With the Ethereum mainnet Pectra hard fork scheduled to be officially activated on May 7, 2025, the "ultimate form" of Account Abstraction - EIP-7702, has officially entered the public eye!

If there is any EVM-based Web3 wallet that does not support EIP-7702, then there is no doubt that it has given up on the entire Ethereum ecosystem and users. This is the determination of Vitalik and EF, and it is also the prelude to the opening of Pandora's Box! Currently, in order 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 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 it as needed. Not upgrading will not affect the normal use of the existing ecosystem and applications. To ensure the safety of your assets, be sure to operate through official channels and beware of phishing links and malicious websites to avoid exposing your assets to risks.

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 therein.

Overview

• The code involved in this article is located at 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, allowing 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 new user experience. When the user entity 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 reduce costs by more than 50%, allowing them to fully embrace the era of contract accounts.

Why do accounts need to be abstracted?

It’s hard to imagine that the vision of account abstraction even predates Ethereum itself.

In this HK Web3 Carnival, Vitalik repeatedly emphasized that through a series of solutions such as multi-sig, account abstraction, ZK Email, etc., Ethereum has completed 50% of its "iPhone moment" goal.

Is it fast or slow, optimistic or limited? Let’s dig deeper and see why AA has such an influence! After all, after a 10-year long run, Vitalik finally ushered in the end of his dream in the AA field, adding a strong stroke to the progress bar of the Ethereum roadmap drawn for 23 years.

What is the purpose of account abstraction?

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 cause comes from the transaction structure of Ethereum. In fact, there is no From party in the standard transaction of Ethereum. 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 cause of a series of problems that make EOA easy to understand but inconvenient to use:

• Private keys are difficult to protect: If a user loses their private key (due to loss, hacker attack, quantum cracking), it means losing all their 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.

• Complex transactions have high transaction fees, which can only be paid via ETH. Any transaction or a single operation requires a basic fee of at least 21,000.

• Transactions have no privacy. Even though there was a confidential ERC-20 protocol proposed by Circle, it has not become mainstream.

Ultimately, today’s 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?

Around AA, there are actually more than ten different proposals, which I have explored before. In fact, after sorting out the whole, 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 the instructions in the form of bundlers, and executes transactions one by one through the delivery contract. In essence, it is to bring 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, and fewer signature algorithms. But what it cannot solve is 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 user2 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, it can be seen 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, but if this is the case, why not just use ordinary CA?

Due to the design of bundler, it can avoid hard fork-level upgrades and be launched directly on the application layer, but ERC-4337 also brings double the cost expenditure, the risk of single point failure, and users also lose the original flexibility of EOA. Therefore, in the face of diverse user demands, it is clear that current market users are not so fond of the ERC-4337 solution. The overall trend has declined significantly in the past two years. Even the peak number of users is far from the 300M independent addresses of Ethereum.

Of course, we are not criticizing the shortcomings of ERC-4337, but as it develops, the roles and concepts such as Paymaster and Gas abstraction developed on it are actually used 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 EOA address to CA address

In fact, as early as November 2015, Vitalik proposed EIP-101, using contracts as a new structure for accounts. Change the address to have only code and storage space, change the handling fee to support ERC20 payment, and change the native token to ERC20-like through a precompiled contract to store the balance (which can have functions such as withholding authorization). In January 2018, there was another EIP-859 solution. Its core function was to use the code parameter attached to the transaction to execute the contract wallet deployment if the transaction party’s contract was not deployed. Finally, EIP-7702, which was further deduced from the EIP-3074 plan, was finally incorporated into 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.

And multiple people can share the same logic contract, thereby greatly reducing the cost of user migration. To complete the EIP-7702 setting, users only need 8W Gas, which is about 0.06 US dollars, and to set up a new contract again or cancel the setting of the logic contract, it only takes 4W Gas.

After completing the settings, it can be seen that it will 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?

Regular 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 spending copper coins (currency generated in the game) and silver coins (user recharge currency) at the same time. Or participate in an event and consume 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 approve and transfer batches. Now you can even make a small tool to help users quickly delete their useless approve authorizations. The effects are easy to compare, and it is obvious that costs can be directly reduced by about 40%.

The core principle of EIP-7702

To explore why it has such an effect, we must return to its principle. In fact, its core is two logics, which are divided into user settings and daily use.

Setting logic contract link

The core process is as follows:

• The first step: signature authorization, use the private key of the original EOA to sign a special hash string, the content is composed of encoded chain_id, address, 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: Signature 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 hides some security risks and complexities, which we will explain in detail below.

Execute the logic contract link

When 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.

Similarly, we use two scenarios to view:

The first is that you call yourself

If you set up a contract like the OKX 7702 Smart Contract with high security and custom control capabilities, then you can specify it through the pre-written calldata to allow your current operation to complete multiple instructions at one time. For example, you can complete Approve+Transfer at the same time, or you can complete Approve+Swap at the same time.

Don’t underestimate it. Among the total 2.7 billion Ethereum transactions, there are about 75M Approve transactions. Based on 8W Gas per transaction, 46W ETH are consumed. Based on the ETH market price of US$1,700, it is close to US$800 million.

The second type is others calling you

There used to be no situation in Ethereum where others called EOA addresses, 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 ability! Therefore, this is also the reason 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, clear, simple and safe. But in this Prague upgrade, EOA will be better after the introduction of EIP-7702. Because of cost, because of experience. When Jobs took the iPhone out of his jeans pocket, those experiences were things that users had not initially thought of, that they could play with it in this way.

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

1. Starknet, as a ZK-Rollup (Layer 2), its default accounts are all contract accounts and there is no EOA.

2. In zkSync Era, using AA account is the default method, and there is no need for the complicated steps of Bundler.

3. Nervos CKB is similar to the UTXO model, but it also allows all accounts to customize the validators used, stripping away the rights of holding and control.

4. Aptos/Sui, as an important role in the Move Layer1, although it is not an AA in the EVM model, it also has the ability to customize accounts, allow modular signatures, multiple verifications, etc.

5. And EVM's Linea / Base / Mantle / Polygon / Arbitrum / Optimism, these related ecosystems, have not only completed AA support through ERC4337, but will also follow up on the EIP-7702 upgrade like the Ethereum mainnet.

The infrastructure in wallet and AA-related fields is paving the way 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), account custody, which are fully supported by service providers such as Coinbase, Metamask, Biconomy, Zerodev, Rhinestone, Ithaca, etc.

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 final effect layer differences 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 Vitalik’s 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 baggage and excellent cost optimization, users will usher in the "iPhone moment".

With the transformation of the underlying form, the derived form can be further imagined, for example

• Users can use Passkey or Google Account to control the wallet. Realize experience functions such as visa-free with limited conditions.

• 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 3s to 1.5s to improve user experience like BSC. Therefore, the wallet tool based on EIP-7702 is the most important bridge for user experience.

So 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 being integrated with complex intelligence, it actually brings many security risks. Some attack methods are even very obscure. Therefore, after the Ethereum Prague upgrade is activated on May 7, 2025, what users need most is a truly secure wallet that is backed by technical expertise.

Is the final battle over?

No.

Indeed, Pectra is Ethereum’s most ambitious upgrade to date, covering 11 EIPs, the largest number in history! We have seen the many benefits of EIP-7702 and have made our judgment based on the principles and data mentioned above.

But it is after users participate in the selection that the market will usher in a chaotic battle.

AA's ecosystem has gradually shown a fragmented trend in its continuous development. Among them, EIP, which defines account abstraction from the framework, already 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 launch of EIP-7702, the storage space under the EOA account becomes available for use by contracts, and the storage space is not exclusive to a single contract, but may be used by multiple smart account providers.

When a user initiates the "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 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", which may interfere with or even destroy the execution logic of the current contract.

However, a variety of solutions have emerged in the community, such as isolating storage through namespace (ERC-7201) to reduce the impact of storage chaos. But 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 necessity of smart account standardization

Today: Safe, Biconomy  href="https://github.com/zerodevapp/kernel/blob/dev/src/utils/ExecLib.sol#L24">ZeroDev all implement 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 case of batch call failure, while Safe and Biconomy do not handle such scenarios.

The practice of “each doing its own thing” in each industry’s 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 opportunity to "reconstruct consensus", pushing the entire Web3 wallet ecosystem from diverse functions to unified structure and achieving true sustainable development.

Three essential security understandings after EIP-7702 is activated

Now, let us switch to different perspectives and look at this system from the perspective 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 it?

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.

Through 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 finally signs a hash value: 0xabc, which is calculated as follows:

Keccak is the mainstream hash algorithm on Ethereum, which is characterized by the fact that data of any length can be calculated to have 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 is incomprehensible, if a user carelessly signs a message and someone else can also bring your authorization to the chain to take effect, then the code will be set unknowingly, thereby triggering a 0day level attack. And since set code is mandatory, you can't assume that if you have set up a secure contract, it will not be replaced.

Therefore, secure wallets will prohibit users from signing an arbitrary hash value, and this was also the case before (because the hash value may also represent an ordinary transaction).

How to protect yourself if you 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 two ways of attack.

The first case is that the hacker steals the next nonce value of your current address for signing Authorization. The solution is also very simple. If you are attacked, please quickly use a wallet with customizable Gasfee, such as OKX Wallet or other secure wallets, to quickly transfer ETH (to other secure addresses of yours). On the one hand, this action can transfer funds at the ETH level, and on the other hand, it can replace the valid nonce value, making it invalid 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 hacker's hand valid. Since you are not sure what the nonce is, no operation can lead to absolute security. The only way to protect yourself is to transfer assets as soon as possible.

It seems that EIP-7702 is more dangerous? Actually, it is not!

For a system like blockchain that truly returns user sovereignty to the user's 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 time, there is a risk because users have to use important private keys frequently.

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 awakened when modifying system-level settings, and for regular daily use, only small accounts are needed to solve the problem.

Why do some common transactions fail after the upgrade?

This situation often occurs 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 user's current address will be checked first. If there is content, the default accepted function will be used to execute the corresponding logic.

Based on this, for ordinary users like us, if I complete the contract settings of EIP-7702, then there will basically be a default acceptance 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 a normal transaction to 21000, 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 ERC20 and ERC721 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 subject to security audits and user recognition, such as: https://github.com/okx/wallet-core

What other changes are there to the Ethereum mainnet Pectra?

There are many voices in the market that believe that Ethereum seems to be lost? Why do many upgrades have nothing to do with users? Is this really the case? Let’s 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 will bring changes to the Ethereum ecosystem in different dimensions.

First of all, there is cryptographic support. Through EIP-2537, the pre-compilation operation of the BLS12-381 elliptic curve is introduced, which can optimize complex cryptographic operations such as BLS signature verification, providing higher security (120+ bit security) and computing efficiency (Gas optimization).

There are many optimization points in the pledge scenario. Objectively speaking, staking does need to be optimized. Ethereum’s 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, by raising the maximum limit through EIP-7251, the number of controlled accounts and the complexity of the system can be reduced for aggregated staking protocols such as lido, but this may aggravate the decentralization problem and make the ETH staking market more centralized.

This upgrade will allow larger-scale node operators to merge multiple validator accounts, while also providing more flexibility for small validators, such as increasing income through compound interest accumulation or more flexible staking increments. This is very important. After the original 32 ETH is reached, if you generate 10 ETH of new income, you will 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 can be returned to the ETH system, which not only brings convenience to user experience, but also foreshadows the reduction of ETH liquidity.

Finally, there is a significant optimization of the L2 ecosystem. Ethereum has always been firmly on the path of L2 ecological community. Other SVM and MOVE chains are essentially still developing their own L1, and even exploring L2 on top of it 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, the gas fee of calldata in the transaction is directly increased from 4/16 gas per byte to 10/40 gas through EIP-7623. 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 improves itself through L2’s TPS, 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 a "highway" to L2, but how to solve the "traffic management" and "charging standards for different highways" in the future is the most fundamental problem.

Glimpse into the future

This article is nearly 10,000 words long. We start from the development roots of account abstraction, and then go into the two routes and comparisons represented by ERC-4337 and EIP-7702. 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 intended to subvert it, but to complement and improve it in another dimension, allowing it to have both sovereignty and ease of use. As Yoav Weiss, a researcher at the Ethereum Foundation, said, “The next billion users are not going to write 12 words on a piece of paper.”

Then by comparing the two, it can be said that he has significantly optimized ERC-4337, giving users space and flexibility, making it easier to be recognized and used by users in the subsequent market. Once users begin to adopt CA as the on-chain entity, complex transaction types will emerge in large numbers on the EVM chain.

Thus, 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 about 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 diversified games will ultimately promote the development of the industry. It is for this reason that after EIP-7702 goes online, it will not immediately detonate the ecosystem on Ethereum, because it is a spiral-upward technical underlying 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 this time 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, using the fairness of open source to give users absolute autonomy.

Finally, returning to the Pectra upgrade itself, we can once again see Ethereum’s thinking and persistence on the future direction. Now that the L2 grand strategy has entered a stable execution period, Ethereum’s roadmap has undergone many changes in details over 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 through hard forks represents Ethereum's continued exploration of how to enhance 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!

Reference materials:

• https://github.com/okx/js-wallet-sdk

• https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md

• https://www.okx.com/zh-hans/learn/smart-account-standardization

• https://mp.weixin.qq.com/s/WjpPNKEVlxlCSz1WyHH4tw

• https://vitalik.eth.limo/general/2024/12/03/wallets.html

• https://metamask.io/news/account-abstraction-past-present-future

About "OKX Research Institute"

The "OKX Research Institute" column is based on institutional research perspectives, focusing on the phenomenal hot spots, innovative applications and technological development frontiers of the encryption industry. Through data analysis, on-chain behavior and cross-market linkage analysis, it reveals the core reasons and potential impacts behind market dynamics, aiming to promote knowledge sharing, ideological collisions and in-depth discussions within the industry, and to help the healthy development of ecological encryption.