The End of 10 Years of Account Abstraction Evolution: Looking at the Past and Future Through EIP-7702

Author: shisilu, Source: okx

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 expected to officially activate on May 7, 2025, the “ultimate form” of account abstraction—EIP-7702—also officially enters the public eye!

If there are any EVM-based Web3 wallets that do not support EIP-7702, then without a doubt, it means they are giving up on the entire Ethereum ecosystem and its users. This is the determination of Vitalik and EF, and it is also the prelude to the Pandora’s box about to be opened! Currently, in order to support the Ethereum ecosystem, OKX Wallet has taken the lead in supporting the latest Ethereum account abstraction standard EIP-7702, and has opened an official entry for users willing to try it out. Users can upgrade through 【OKX Wallet homepage 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 safety, be sure to operate through official channels and beware of phishing links and malicious websites to avoid asset risks.

Please follow this article to gain a comprehensive understanding of the evolution history of account abstraction, the user value and market changes brought by EIP-7702, as well as the hidden dangers it conceals.

Overview

• The code mentioned in this article is located at okx/js-wallet-sdk, and the EIP-7702 SDK implementation used by OKX Wallet is open source and available to community partners.
• EIP-7702 introduces a new type of transaction, allowing 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 presents an invisible risk to ordinary users, even if they do not upgrade, as it may trigger transaction failures or security asset loss risks in specific scenarios.
• EIP-7702 will bring a brand new user experience. When user entities undergo contract migration, market applications will evolve accordingly. Gas abstraction, hierarchical family accounts, and other long-awaited seamless experiences will lead billions of people to enter the Web3 world at low cost.
• For exchanges and DApps, applying the features of EIP-7702 will lead to a cost reduction of over 50%, thus fully embracing the era of contract accounts.

Why Should Accounts Be Abstracted?

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

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

Is it fast or slow, optimistic or limited? Let’s delve into the underlying layers and see why AA has such influence! After all, after a decade-long journey, Vitalik has finally welcomed the climax he has longed for in the AA field, adding a bold stroke to the progress bar of the Ethereum roadmap drawn for 2023.

What is the purpose of account abstraction?

In fact, the essence of the solution is addressing the issue of property rights separation. Currently, the ownership and signing rights of EOA (Externally Owned Account) are held by the same entity (both rely on private keys for controlling any instructions). The root of this comes from Ethereum’s transaction structure, where there is actually no ‘From’ party in Ethereum’s standard transactions. During execution, the ‘From’ address is derived from the VRS parameters (i.e., user signature).

Moreover, the design of Ethereum as a “world-class state machine” completely relies on transactions to achieve changes in on-chain status. Coupled with the inability to specify the From party, this ties the execution rights of transactions together with the highest ownership.

This is the root of a series of problems with EOA that, although simple and easy to understand, are inconvenient to use:

• Hard to protect private keys: Losing the private key (due to loss, hacking, or quantum cracking) means losing all assets.
• There are few signature algorithms, and different signature algorithms bring different performance overhead and even storage costs on the chain.
• High signature authority, EOA’s native private key has all these rights.
• The fees for complex transactions are high, and the fees can only be paid in ETH. Any transaction or single operation requires a minimum base fee of at least 21,000.
• Transactions lack privacy; even though there was a confidential ERC-20 protocol proposed by Circle, it has 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). This is the problem that EIP-7702 aims to solve by hiding complex information from ordinary users.

What are the core differences between ERC-4337 and EIP-7702?

Around the goal of AA, there are actually more than ten different proposals, which I have previously explored. In fact, when整理 it as a 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. In summary, it proposes a new transaction object called UserOperation, which users send to the memory pool in the form of bundlers to batch package instructions and execute transaction operations one by one through delivery contracts. Essentially, it brings the underlying transactions and account operations to be executed at the contract level.

The execution principle is shown in the figure below:

Through the role of the bundler, it can be said that this solution can address issues such as batch transactions, gasless operations, and simplified signature algorithms. However, it cannot solve the complexities and user transaction costs, as well as the single point of failure risk between the bundler and EntryPoint.

Because once users migrate to ERC-4337, even if the demand of user2 in the above image is just to make a Transfer transaction, the transaction fees for the user are doubled 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, such as batch Calls, why not just use regular CA directly?

Originating from the design of bundler, it allows for upgrades to avoid hard fork levels and be launched directly at the application layer. However, ERC-4337 has also brought about doubled costs, single point of failure risks, and users have lost the original flexibility of EOA. Therefore, in the face of diverse user demands, it is clear that current market users are not particularly fond of the ERC-4337 solution. The overall trend has significantly declined over the past two years, and even at peak user numbers, it is far from Ethereum’s 300M independent addresses.

Of course, we are not criticizing the shortcomings of ERC-4337, but rather accompanying its development, the roles and concepts such as Paymaster and Gas abstraction that have developed on it are actually applied again in EIP-7702.

The author believes that the development of any industry will not happen overnight; what is important is to discover the规律 and summarize the经验 from past ups and downs.

Route 2: Convert EOA address to CA address

In fact, as early as November 2015, Vitalik proposed EIP-101, which introduced a new structure for accounts as contracts. The address was changed to consist only of code and storage space, altering the fee support to be paid by ERC20, and allowing native tokens to be converted into ERC20-like tokens for balance storage through precompiled contracts (which can have features such as authorized deductions). In January 2018, there was also the EIP-859 proposal, which primarily served the purpose of deploying a contract wallet using the code parameter attached to the transaction if the counterparty’s contract was not deployed. Ultimately, the EIP-7702, further derived from the EIP-3074 proposal, was finally incorporated into the Ethereum mainnet!

The concept and effect of EIP-7702 are actually quite simple. It achieves initialization through a new transaction type, allowing users to enable EOA with temporary and optional smart contract functionalities within a single transaction. This further supports batch transactions, gasless transactions, and custom permission management in business operations. The most crucial capability is that it provides users with temporary and optional space.

Moreover, multiple users can share the same logic contract, significantly reducing the cost of user migration. To complete the setup for EIP-7702, users only need 80,000 Gas, which is approximately 0.06 USD. If they need to set up a new contract again or cancel the logic contract, it only requires 40,000 Gas.

After completing the setup, it can significantly bring users substantial gas optimization during batch trading. See the table below:

Of course, you might wonder if it’s necessary to perform the Token Transfer twice, or even six times?

Regular users are accustomed to doing one thing per transaction, which may seem like there aren’t many scenarios. However, in diverse application scenarios like Web3 Game and Web3 Pay, such situations frequently arise. For instance, there may be cases where both copper coins (in-game currency) and silver coins (user recharge currency) are used together for consumption. Alternatively, one might participate in an activity while simultaneously consuming an NFT ticket and an entrance fee.

Even if we don’t imagine complex scenarios, returning to the current mainstream Swap demand on the chain, there is still a need for batch approve and Transfer. In fact, we can now create a small tool that helps users quickly delete their already useless approve authorizations. The effect can be easily compared, and it is clear that costs can be directly reduced by about 40%.

The Core Principles of EIP-7702

To explore why there is such an effect, we must return to its principles. Its core actually consists of two logics, divided into the user settings phase and the daily usage phase.

Set up the logic contract process

The core process is as follows:

• Step 1: Sign authorization, sign a special hash string using the private key of the original EOA. The content is composed of an encoded chain_id, address, and nonce. Here, Address is the address of the logic contract that is to be set finally, while Nonce is the strategy to ensure that the transaction is not replayed.
• Step 2: Sign the transaction. With the authorization information from Step 1, anyone can construct a transaction of type 4, which can include multiple authorization information, allowing for bulk authorization settings for multiple addresses at once.
• Step Three: Broadcast on-chain, at which point the logic contract will already be in effect when the transaction’s internal Authorization has been processed.

There are more technical details here that can be referenced: the implementation of the okx open-source js sdk, 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.

Execution of logical contract phase

When you have completed the setup, any transaction to the address pointing to you will be similar to calling a smart contract, where the system will “load” the code of the logical contract you have originally set into the current state of your EOA to execute its logic.

Similarly, we use two scenarios to take a look:

The first type, you call yourself.

If you set it up like the OKX 7702 Smart Contract, which has high security and customizable control capabilities, then you can specify through pre-written calldata to complete multiple instructions in one go. For example, you can simultaneously complete Approve + Transfer, or you can concurrently execute Approve + Swap.

Don’t underestimate it. Among the current total of 2.7 billion Ethereum transactions, there are approximately 75 million Approve transactions. Calculating at 80,000 Gas per transaction, that results in 460,000 ETH consumed. Based on the current market price of ETH at 1700 USD, that amounts to nearly 800 million USD.

The second type is when others call you.

Once upon a time, there was no situation where others could call EOA addresses on Ethereum, but now you are a universal contract, fully customizable. You can create sub-accounts with different permissions, and you can also whitelist a few Paymasters, allowing designated accounts of DApps to initiate some transactions on your behalf, thus completely eliminating the awkward situation of repeatedly popping up signatures in traditional blockchain applications.

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

Is EIP-7702 the ultimate solution for account abstraction?

Yes, because this time users will choose him!

It’s not that EOA is not good enough; objectively speaking, EOA is simple and clear, and safe. However, the EOA after the introduction of EIP-7702 in this Prague upgrade will be even better. Because of cost, because of experience. When Jobs took out the iPhone from his jeans pocket, those experiences were something users hadn’t thought of at first, that it could be played this way.

Account abstraction is actually a field that many chains are exploring and actively trying out. For example:

1. Starknet, as a ZK-Rollup (Layer 2), has contract accounts as its default accounts and does not have EOAs.
2. zkSync Era, using AA accounts is the default method, and there is no need for the complicated steps of Bundler.
3. Nervos CKB, similar to the UTXO model, but it also allows all accounts to customize the validators they use, separating ownership from control.
4. Aptos / Sui, as a pivotal player in the Move-based Layer 1, although not an EVM mode AA, also possesses the ability for account customization, permissioned modular signatures, multi-verification, and so on.
5. The EVM ecosystems such as Linea / Base / Mantle / Polygon / Arbitrum / Optimism have not only completed AA support through ERC4337, but they will also almost certainly follow the upgrade of EIP-7702 just like the Ethereum mainnet.

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

The core experience optimizations from EIP-7702 include: batch transactions, gas abstraction (i.e., gasless solutions such as gasless), and account custody, all of which are fully supported by service providers like Coinbase, Metamask, Biconomy, Zerodev, Rhinestone, and Ithaca.

These adaptations have also been 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 amount of infrastructure that once surrounded AA to 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 carries a much heavier historical burden than other chains. This is the reason behind the recent community voices opposing Vitalik’s changes to the EVM virtual machine, and also the reason why ERC-4337 had to be chosen in the early days. However, once a better option (EIP-7702) emerges that can achieve compatibility with the historical burden while also offering excellent cost optimization, users will welcome their “iPhone moment.”

With the transformation of the underlying form, the derived forms can also be further imagined, such as

• Users can control their wallets using Passkey or Google Account. This enables features such as conditional waivers and other experience functionalities.
• Users can enable recovery capabilities through methods such as setting up ZKEmail to retrieve their private keys.
• For large on-chain operators, integrating multiple transactions into one can significantly reduce block waiting time, making on-chain swaps faster and lowering the risk of transaction failures through consecutive transactions.

Time has a huge impact on user experience. As the second-ranked consensus system in the entire blockchain world (next to BTC), ETH cannot enhance user experience by arbitrarily reducing block time from 3s to 1.5s like BSC. Therefore, the wallet tool based on EIP-7702 is the most important bridge for user experience.

Therefore, combining our previous discussion on its underlying principles, 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 applications require caution. After integrating complex intelligence, the security risks it brings are not insignificant, 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, safeguarded by technical expertise.

Has the Endgame battle ended?

No.

Indeed, Pectra is the most ambitious upgrade to Ethereum so far, encompassing 11 EIPs, the highest number in history! We have observed the many benefits of EIP-7702, and we have made judgments based on the principles and data presented above.

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

The ecosystem of AA is continuously evolving and has gradually shown signs of fragmentation. Among them, the EIP that defines account abstraction from a framework perspective has already seen interface standards like ERC-4337, ERC-6900, and ERC-7579. However, there are significant differences in user experience, interface specifications, and behavioral expectations between different implementation solutions. Various wallet implementation solutions focus on similar application scenarios and limited core functionalities, but each adopts incompatible design assumptions and implementation logic.

A typical hidden problem is the disorder of storage.

After the launch of EIP-7702, the storage space under EOA accounts became accessible for contracts, and this storage space is not exclusively occupied by a single contract, but may be jointly switched and 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 still remain in the storage of the EOA. This means that the new proxy contract can access and even modify the storage data written by the old contract, introducing the risk of “storage pollution” that could 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 namespace (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 chaos in executing standards.

As revealed in this article: “From Fragmentation to Unity: The Necessity of Standardizing Smart Accounts”

Currently: Safe, Biconomy, and ZeroDev have all implemented their own versions of batch calling functionality, but the naming of functions, interface parameters, and result handling methods are all different among the three. Among them, ZeroDev takes into account the scenario of batch call failures, while Safe and Biconomy do not handle such situations.

The industry standard of “each doing their own thing” inevitably leads to a chaotic battle. Users, dApps, and developers are all victims in this scenario. Therefore, the introduction 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,” driving the entire Web3 wallet ecosystem from diverse functionalities to a unified structure, achieving true sustainable development.

Three Essential Security Understandings After EIP-7702 Activation

Now, let’s switch to different perspectives, from users, from DApps, from exchanges and other organizations, to see how this system affects us, it will bring opportunities, but also bring risks, only by understanding the risks, but also in order to enjoy the benefits brought by this system more perfectly.

Is Eip-7702 very complicated? Can I not 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 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, then the signature authorization can be effective on any chain as long as the nonce is satisfied.

Through the specific implementation method of the 7702 process in the open-source signature SDK by OKX, it can be seen that in order to comply with this standard, the user ultimately signs a hash value: 0xabc, which is calculated as follows:

Among them, keccak is the mainstream hashing algorithm on Ethereum, characterized by the ability to produce a fixed 32-byte length result from data of arbitrary length. RLP, on the other hand, is a set of information encoding methods, and the Magic at the end is a fixed value.

However, due to the final result being a hash value that is not comprehensible, users may inadvertently sign a message, and if others can also carry your authorization on-chain, it could unknowingly set you up with code, leading to a 0-day level attack incident. Moreover, since setting code is mandatory, you cannot assume that a previously set safe contract will not be replaced.

Therefore, secure wallets will prohibit users from signing any arbitrary hash value, as this could also represent a regular transaction.

How can I protect myself if I mistakenly upgrade a risky contract?

This risk is also very common, as it is impossible to ensure that one will never fall for phishing.

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

Therefore, there are two types of attack methods.

The first scenario is that a hacker steals a nonce value from your current address and signs the Authorization. In this case, the process is quite simple; if you are under attack, please quickly use a wallet that allows you to customize the Gas fee, such as OKX Wallet or another secure wallet, to swiftly transfer your ETH (to another secure address that you own). This action can not only transfer ETH funds but also replace the valid nonce value, thereby rendering the hacker’s access ineffective.

The second scenario is that the nonce value stolen by the hacker may be used later, so your current Transfer could inadvertently validate the Authorization in the hacker’s hands. Since you are uncertain about what the nonce actually is, any operation cannot guarantee absolute security. The only option is to quickly transfer assets to protect yourself.

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

For blockchain, which truly returns user sovereignty to the system where users own their private keys, any random signing at any time can lead to financial losses. However, the key point here is that aside from the situation where large users are targeted for poisoning, the majority of risks arise because users often have to use their important private keys, which exposes them to risks.

If you have already achieved the functionality of a family account and personal sub-accounts through AA, and have set available limits for each sub-account, then essentially your main account only needs to be activated when modifying system-level settings, whereas regular daily use can be handled by the small accounts.

Why did some common trades fail after the upgrade?

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

First, let’s provide some technical background. During the contract call process on Ethereum, the system first checks the code field of the user’s current address. If there is content present, it will execute the corresponding logic by going through its default accept function.

Based on this, for us ordinary users, the performance will be that if I complete the contract setup for EIP-7702, there will basically be the functionality of a default accept function, so any ordinary ETH transfer transaction will execute some contract logic, thereby increasing the overall gas use. If the gas limit you set for an ordinary transaction is 21000, then it will naturally fail.

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

In this regard, it is recommended to set up using wallets that explicitly support EIP-7702, or to use logic contracts that are highly regarded for security audits and user approval, such as:

What other changes are there in the Ethereum mainnet Pectra?

There are many voices in the market suggesting that Ethereum seems to be lost? Why do many upgrades not matter to users? Is it really the case? Let’s take a look at the other EIPs of this upgrade to find the answers. Chen Ran, EIP-7702 is the most significant upgrade change that users can feel, but there are also 10 other EIPs that bring changes to the Ethereum ecosystem from different dimensions.

First, regarding cryptographic support. With EIP-2537, the precompiled operations of the BLS12-381 elliptic curve have been introduced, which can optimize complex cryptographic operations such as BLS signature verification, providing higher security (120+ bits of security) and computational efficiency (Gas optimization).

The staking scenario has several optimization points. Objectively speaking, staking does need optimization; the Ethereum validator cluster has been growing rapidly, with nearly a million validator staking addresses. This is due to the MAX_EFFECTIVE_BALANCE being limited to 32 ETH, and node operators need to create multiple validator accounts to manage larger staking assets, leading to a significant number of “redundant validators”. Therefore, the maximum cap has been raised through EIP-7251, which can reduce the number of controlled accounts for staking protocols like Lido, thereby decreasing system complexity. However, this may exacerbate decentralization issues, making the ETH staking market more centralized.

After this upgrade, larger-scale node operators can merge multiple validator accounts, while also providing more flexibility for smaller validators. For example, they can increase their earnings through compound returns or more flexible staking increments. This is very important because originally, after reaching 32 ETH, if you earned an additional 10 ETH, you wouldn’t continue to stake the ETH since you still needed to gather 32 to open a new account. However, after this update, you can directly stake 42 ETH. Therefore, your compound returns can return to the ETH ecosystem, providing user experience convenience and hinting at a certain reduction in ETH liquidity.

Finally, there is a significant optimization of the L2 ecosystem. Ethereum has always firmly walked the path of the L2 ecosystem community. Other SVM and MOVE systems 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 does not rely so much on doing L2.

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

Also, through EIP-7691, the capacity of blobs in blocks is increased to support larger-scale L2 storage space. In the previous Cancun upgrade, there were two core parameters representing blobs: target and max, which indicate the target number of blobs per block and the maximum number of blobs per block, respectively.

Cancun is 3 and 6, now after Prague, the parameters have changed to 6 and 9, in short, it has been expanded.

So Ethereum is enhancing itself through the TPS of L2. Although there are many issues such as liquidity fragmentation, cross-chain complexity, emergency escape capacity, etc. Therefore, in the current Pectra upgrade, Ethereum is adding “highways” to L2, but the fundamental problem is how to solve “traffic management” and “different toll standards for highways” in the future.

Glimpse into the Future

This article is nearly ten thousand words long. We start from the development origins of account abstraction, then discuss the two routes represented by ERC-4337 and EIP-7702 and compare them. Next, we delve into the principles and mechanisms of EIP-7702, analyzing its advantages and disadvantages in mainstream user scenarios and the effects of adjustments.

The author believes that “Not your keys, Not your money” is a great concept. EIP-7702 is not a disruption of it, but rather a complementary enhancement from another dimension, providing both sovereignty and usability. As Yoav Weiss, a researcher at the Ethereum Foundation, stated, “The next billion users won’t write down 12 words on paper.”

Then, through the comparison of the two, it can be said that it has significant optimizations for ERC-4337, providing users with space and flexibility, making it easier for users to recognize and use it in the subsequent market. Once users start adopting CA as an on-chain entity, complex transaction types will emerge in large numbers on EVM-compatible chains.

From this, we glimpse the shadow of the future accompanied by a rich variety of underlying account subjects and transaction types. Many application experience issues that used to be bottlenecks will also be resolved accordingly, no longer forcing users to understand the logic of Nonce, Gas, etc., but instead providing simplified processing through wallet and other entry service tools.

Although facing industry-level diversity, which brings a certain degree of interface standards and storage chaos, I also optimistically see that the more valuable the chaos, the more it can carve out a unified standard. The decentralized multi-game will ultimately promote the development of the industry. Therefore, after the launch of EIP-7702, it will not immediately ignite the ecosystem on Ethereum, because it is a spiral upward technology upgrade. Such upgrades often lead market applications by 2-3 years, leaving time for the application layer to gradually ferment.

Moreover, starting from this upgrade, users’ security will increasingly rely on the service quality of the entry tool layer. Open source is an important step in providing users with a sense of security. Therefore, the underlying SDK implementation of EIP-7702 integrated into OKX Wallet this time is also open source, publicly accepting the tests from the community and the market. Many wallets that maintain openness are going further down the path of self-custody, granting users absolute autonomy through the fairness of open source.

Finally, returning to the Pectra upgrade itself, we can once again see Ethereum’s reflection and persistence on its future direction. Now that the L2 strategic deployment has entered a stable execution phase, Ethereum’s roadmap has undergone many changes in detail over the past decade, but the core objective has surprisingly remained consistent: the hope for a secure and decentralized green (POS) blockchain that is both highly scalable and easy to verify. Proposals like EIP-7702, which effectively enhance user experience through hard forks, represent Ethereum’s ongoing exploration of how to enhance competitiveness among multiple 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!

Reference materials:

About “OKX Research Institute”

The “OKX Research Institute” column is based on an institutional research perspective, focusing on phenomenal hotspots, innovative applications, and cutting-edge technological developments in the cryptocurrency industry. Through methods such as data analysis, on-chain behavior, and cross-market linkage analysis, it reveals the core reasons and potential impacts behind market dynamics. The aim is to promote knowledge sharing, intellectual exchange, and in-depth discussions within the industry, contributing to the healthy development of the ecological cryptocurrency.