Decrypting the changes of Ethereum's ERC-4337, what opportunities can we glimpse?

1. Background

The trade-off between decentralization and convenience has always been a major dilemma for crypto participants. To embrace decentralization, one must abandon the convenient web2 operation model, transitioning from simple button clicks to a series of processes such as managing mnemonic phrases, signing with private keys, and setting nonce values. Conversely, if one pursues convenience, the collapse of centralized institutions like FTX and JPEX makes it impossible to ignore the importance of account ownership. To solve this problem, Ethereum developers have made a series of attempts to give web3 accounts the convenience of web2—account abstraction. At this year's ETHCC conference, Ethereum founder Vitalik Buterin summarized these attempts, with the greatest consensus among developers being the ERC4337 standard.

2. ERC4337 Account Abstraction Principles

ERC4337 primarily involves three objects in the process of separating control and ownership from the account entity: UserOperation, Bundler, and on-chain contracts. UserOperation mainly contains user inputs, Bundler completes the packaging and triggering of transactions, and the on-chain contract consists of Entry Point, Paymaster Contract, and Wallet Contract, which mainly implement complex verification and execution logic.

UserOperation: UserOperation contains all transaction-related information submitted by the user. The following diagram shows the parameters that need to be input in UserOperation compared to the parameters required for a regular EOA account to initiate a transaction.

Comparison of input parameters between ERC4337 and EOA accounts, Source: Kernel Ventures

The biggest difference is that in ERC4337 wallets, the sender can be specified, whereas in EOA, the default ECDSA signature address is the transaction initiator, thus achieving the separation of account entities and ownership in ERC4337 wallets. Additionally, ERC4337 introduces the paymasterAndData parameter to set specific information for the reimbursement contract. We will explain the specific role of the reimbursement contract later.

Bundler: Bundler is essentially an EOA account. For incoming UserOperations, it first verifies the code logic involved in interacting with the Wallet Contract's validateOp function in the calldata. If it contains TIMESTAMP, BLOCKHASH, or accesses outside of wallet storage, Bundler will reject the UserOperation to prevent a type of attack known as malicious simulation. After verification, Bundler will package multiple UserOperations and broadcast them to the public or private mempool once verified. Additionally, since smart contracts on Ethereum must be triggered by EOA accounts, Bundler must subsequently interact with the Entry Point Contract to execute UserOperation. In this process, Bundler can profit from the difference between the maximum priority fee and actual gas, as well as MEV gains from sorting bundled transactions. Therefore, the rise of ERC4337 may also introduce a new mining method for Bundler miners on Ethereum.
Entry Point: The Entry Point is a smart contract used to verify and execute the contents of UserOperation, triggered by Bundler, achieving separation between Bundler and smart contract wallets. Additionally, the Entry Point in ERC4337 is a singleton contract, and each Wallet Contract in ERC4337 is assigned a special authentication to the Entry Point contract address during creation, granting special permissions during the interaction process. When Bundler calls the Entry Point contract, it triggers the handleOps function, which first checks whether the wallet has enough gas to reimburse Bundler; if not, the transaction is rolled back. Furthermore, the smart contract wallet can choose to have the Paymaster contract pay for this gas, which we will mention in subsequent content. If all verifications pass, the internal function _executeUserOp in the contract will gradually execute the contents of the calldata in UserOperation, calling the corresponding functions in the smart contract wallet. After everything is completed, the remaining gas is reimbursed to Bundler.
Wallet Contract: The Wallet Contract is essentially a smart contract wallet, which contains a multiCall function that can batch process data from UserOperation's calldata, significantly reducing gas consumption. However, unlike the execution process of ordinary smart contracts, in the multiCall function, the contents of UserOperation are not executed directly but are divided into validateOp and executeOp processes. If the contents of UserOperation cannot pass validateOp, execution will automatically terminate, and all gas consumed during the process will be borne by Bundler. However, once it reaches the executeOp function, regardless of the reason for the contract execution termination, the gas consumed will be borne by the Wallet Contract. This mechanism effectively ensures that Bundler can obtain legitimate profits through its packaging behavior while preventing DoS attacks initiated by malicious Bundlers that waste the ETH stored in the Wallet Contract.
Paymaster: Paymaster is not a mandatory component in ERC4337. When the paymasterAndData parameter in UserOperation is not empty, the specified Paymaster contract will reimburse gas for Bundler. In this process, Bundler will trigger the validatePaymasterOp function in Paymaster, which checks whether there are enough funds in Paymaster to support gas payment and pays gas for the specified UserOperation according to user-defined requirements. It is worth noting that ERC4337 itself does not set a standard for prioritizing Paymaster usage; instead, Bundler must select the optimal Paymaster based on off-chain records of past reimbursements, eliminating lower-quality Paymasters. This process creates competition among Paymasters, helping to improve network operational efficiency.
Signature Aggregator: Since ERC4337 supports non-ECDSA signature algorithms, we first need to classify UserOperations using different signature algorithms, and then Bundler will generate an aggregated signature for similar transactions through the Signature Aggregator, allowing for a single verification to validate all transactions contained within, greatly reducing gas costs.

Overall, in this process, the user first sends a UserOperation containing user-defined parameters to Bundler. If there is a paymasterAndData parameter, the reimbursement contract will be called to pay for gas. If there is an initCode parameter, the user will create a new smart contract wallet according to the code logic inside. Finally, to reduce gas consumption during the verification process, ERC4337 adopts a batch packaging transaction method, using Signature Aggregator to package similar UserOperations into an aggregated signature, requiring only one verification. Once both the off-chain Bundler's simulated verification and the on-chain actual verification pass, the smart contract wallet successfully executes the user-defined functions in UserOperation while refunding excess gas to Bundler as a reward.

ERC4337 Account Abstraction Workflow Diagram, Source: Kernel Ventures

In contrast, initiating a transaction using an EOA account is extremely simple; it only requires an EOA account to sign the transaction data and broadcast it across the network. The broadcast transaction is verified by nodes and awaits packaging, ultimately recorded on-chain by nodes selected through the POS mechanism. This process is very straightforward, without intermediaries like Bundler and Entry Point contracts, resulting in relatively low gas consumption. Additionally, security is solely related to the ECDSA encryption algorithm, without the inherent security risks brought by complex contract logic. However, in this process, the private key and account control are uniquely bound and cannot be changed, and every transaction must be individually signed and verified, making automation impossible.

EOA Account Transaction Process, Source: Kernel Ventures

In summary, ERC4337 achieves the separation of private keys and account ownership, reduces gas consumption in complex transaction processes through batch processing, eliminates the Ethereum balance entry threshold for wallets through reimbursement contracts, and realizes the diversification of signing methods and customization of account functions through smart contract wallets. These improvements have made significant strides in facilitating the use of web3 accounts and diversifying their functions.

3. Current Types of Ethereum Wallets and Their Pros and Cons

EOA (Externally Owned Account): Ethereum EOA accounts are controlled through private key signatures, with the private key generated from a 12-word mnemonic phrase. While EOA accounts have proactive operation capabilities and can initiate transactions, ensuring ownership of EOA accounts requires proper storage of a 64-character hexadecimal number or 12 mnemonic words, which brings many inconveniences to users. Additionally, transactions involving identity verification for EOA accounts require individual signatures, which is extremely inconvenient, as each confirmation behind a single confirmation must be individually verified for state changes and permission alterations. Lastly, initiating transactions with EOA accounts requires pre-funding the account with Ethereum, raising the usage threshold for wallets.
SCW (Smart Contract Wallet): Smart contract wallets have greatly improved operational convenience and automation compared to EOA wallets. Through built-in code in smart contracts, they can package transactions and automate the execution of complex operations according to user intent. However, SCWs have far lower permissions than EOA accounts and cannot autonomously execute transactions; initiating transactions requires an EOA account to trigger them.
MPC (Multi-Party Computation Wallet): MPC wallets split the private key and distribute it among multiple parties for safekeeping, reassembling it when a signature is needed. This sounds similar to multi-signature wallets, but there are significant differences. First, there is only one private key in MPC; we are merely fragmenting its storage. Secondly, multi-signature verification is entirely conducted through on-chain smart contracts, while MPC's threshold settings and signature generation occur off-chain. MPC wallets effectively avoid single points of failure, eliminating concerns about losing account ownership due to private key loss in EOA. However, the off-chain signature generation process is centralized and requires strict oversight to prevent potential malfeasance. Additionally, most MPC solutions are custom products and not open-source, making modular integration during development challenging and increasing development costs. It is important to emphasize that MPC wallets do not compete with the AA wallets mentioned later. MPC addresses the pain point of private key storage, while AA focuses on improving the flexibility of transaction processes, and both can be used in conjunction in future developments.
AA (Account Abstraction): The concept of account abstraction can be traced back to EIP86 in 2017, which proposed turning all accounts into contracts, allowing users to freely define their security models. However, this proposal involved changes to the Ethereum consensus layer, making it quite challenging and raising a series of potential security issues. Thus, EIP86 and subsequent proposals related to changes in the Ethereum consensus layer or protocol layer have been indefinitely shelved. It wasn't until the introduction of EIP2938 that significant changes to the Ethereum base layer were reduced, and security issues were addressed by setting rules for the node's memory pool. The overall solution for account abstraction shifted to how to achieve it by only modifying the smart contract layer. In 2021, ERC4337 was proposed, fully realizing account abstraction with only changes at the smart contract layer. In March of this year, the Entry Point contract of ERC4337 was deployed on Ethereum, marking the beginning of the ERC4337 era of account abstraction.

4. Challenges and Responses

4.1 Uncertain Account Abstraction Standards

Consensus Layer Account Abstraction: First, for account abstraction on Ethereum's Layer 1, ERC4337 is not the only solution. The consensus layer account abstraction led by EIP2938 has only been temporarily shelved, not completely dismissed. Perhaps at this stage, the benefits brought by account abstraction do not drive developers to make changes at the Ethereum base layer. However, as development of ERC4337-style account abstraction reaches a bottleneck, people will seek better user experiences. At that point, proposals for consensus layer account abstraction that enhance contract account permissions to allow them to autonomously initiate transactions, removing Bundler and reducing transaction costs and complexity, may re-enter consideration.
Undetermined EIP Proposals: Secondly, ERC4337 has been officially implemented for less than a year, and issues are still being discovered and addressed. Since changes to the Entry Point cannot be made, the currently proposed EIP proposals to optimize ERC4337 mostly involve optimizations related to Bundler and opcodes, such as the endorser contract in EIP-1589 that can prevent MEV attacks, and the opcode added in EIP-3974 that involves changes to the consensus layer, which entrusts EOA account control to smart contract accounts. Whether these proposals can pass remains to be discussed by the Ethereum developer community.
Layer 2 Native Account Abstraction: Lastly, there are various native account abstraction wallets on Layer 2, such as Starknet and Zksync Era. Starknet uses a different signature algorithm than Ethereum's ECDSA, significantly reducing the costs of signing and verification processes, thereby greatly lowering gas consumption. Additionally, Starknet only has contract accounts, defaulting them as top-level accounts, allowing contract accounts to autonomously initiate transactions without needing complex contract layer operations, providing developers with a more flexible and rich application design environment.

In summary, while ERC4337 is currently the most widely recognized option for account abstraction on Ethereum, it is not the only option.

4.2 Deficiencies of ERC4337 Itself

Higher Fixed Gas Costs: The gas consumption for basic operations in ERC4337 wallets is 42,000 gas, which is twice that of regular EOA accounts. The specific reasons are as follows:

Gas consumption differences between ERC4337 accounts and EOA accounts, Source: Kernel Ventures

It can be seen that due to the introduction of smart contracts, there is significant gas consumption during the execution of contract operations (unpacking UserOperation, executing condition verification, on-chain hashing, etc.) and triggering events and publishing logs on Ethereum. Additionally, the proposed transaction batching in ERC4337 to reduce transaction costs has proven impractical in actual transactions, as most users do not need to package a large number of transactions in a single call, only benefiting from ERC4337's batch processing in rare scenarios such as airdrops from project parties. Furthermore, if a UserOperation originally intended to share transaction costs fails on-chain, it can lead to higher losses for the wallet account or Bundler.

High Upgrade Costs: In the Entry Point smart contract, the entryPoint() function can return a parameter that conforms to the IEntryPoint interface. In the Wallet Contract, this parameter can determine whether external transactions come from function calls in the Entry Point contract. However, this requires the EntryPoint address to be hardcoded into each generated smart contract account entity, meaning that upgrading the EntryPoint contract requires consensus from all smart contract account entities. Once ERC4337 is widely accepted, the difficulty of making this change will be comparable to changes at the consensus layer. Therefore, the deployment of ERC4337 must be very cautious, with thorough security audits in all aspects. Subsequent performance optimizations will also be very challenging.
Contract Security Issues: In the original EOA accounts, the transaction process is simple, and transaction security is ensured through cryptography and the consensus mechanism of the consensus layer. Both encryption algorithms and the consensus mechanism of distributed systems are well-tested and academically validated technologies, with a very low likelihood of vulnerabilities. However, ERC4337 wallets have shifted many operations that were previously verified by blockchain consensus mechanisms to contract function evaluations, which raises the security requirements for the contracts themselves. As transaction logic becomes more complex, security risks also increase sharply.

4.3 Update Costs of ERC4337

Traditional Wallet Giants' Hesitation:

According to ChainCatcher, MetaMask product lead Alex Jupiter stated in an interview with Decrypt that although account abstraction, EOA, and various technologies to optimize user experience were frequently mentioned during EthCC, MetaMask would be very cautious in adopting these technologies.

As a traditional wallet provider, MetaMask can help users conveniently create EOA accounts and charge fees by providing decentralized swap services. For these traditional wallet giants that have already established stable profit models, most are reluctant to take risks and make changes, currently adopting a wait-and-see attitude towards account abstraction, exploring actively but remaining cautious in attempts.

Update Costs for Dapps:

Existing Dapps on Ethereum, including Opensea, Uniswap, MetaMask Swap, etc., all use EOA accounts as their default service objects. To make these Dapps fully compatible with ERC4337 wallets, changes are needed in the review mechanisms for Dapp-wallet interactions and token staking mechanisms. Completing this change would require modifications to the smart contract code of mainstream Dapps today, and the potential security risks and update costs involved in this process are immeasurable. Additionally, considering the previous backlash against contract accounts due to the Tornado contract, the workload for this update will be even more substantial.

4.4 ERC4337 and Cross-Chain

In cross-chain bridges interacting between Ethereum and Layer 2, the receiving address on the receiving network is often defaulted to the payment address on the sending network. This poses no issues in traditional EOA accounts, as the same private key can control addresses on both networks through signatures. However, in ERC4337 wallets, the transfer initiation address is a contract address, which is not controlled by a private key, making it impossible to set the receiving address to be the same as the sending network. Therefore, ERC4337 wallets face compatibility issues with almost all existing cross-chain bridges between Ethereum Layer 1 and Layer 2.

4.5 Improvement Measures for ERC4337

EIP Proposal Improvements: Although the ERC4337 standard itself is difficult to change, we can propose new EIP supplementary proposals to complement ERC4337, such as EIP5189 proposed in June 2022, which introduces the endorser contract to reduce the risks in Bundler's selection process and further prevent malicious attacks from MEV bots. Additionally, there are many pending review proposals related to ERC4337, such as EIP3074 and EIP5003.
Supplementing Cross-Chain Protocols: The most fundamental solution to the cross-chain issues between Ethereum Layer 1 and Layer 2 is to allow users to set their receiving addresses on the receiving network, but this improvement is costly, involving the redeployment of cross-chain bridges and new contract security issues. Currently, a more ideal solution is to set up a trusted third-party EOA account to act as an intermediary between ERC4337 wallets and cross-chain bridges, requiring this intermediary to hold a large amount of ETH or Layer 2 tokens staked, and to stake excess assets before executing a cross-chain transaction, returning the staked tokens after the receiving smart contract wallet receives the transfer, along with a certain reward.
Self-Built Dapps for ERC4337: Since the deployment of the entry point contract in March this year, a large number of wallet projects based on ERC4337 have been launched on Ethereum. These projects are inherently compatible with ERC4337 wallets, such as the highly scalable smart contract wallet project ZeroDev Kernel and the wallet abstraction project MynaWallet in collaboration with the Japanese government. These projects form a large ecosystem of account abstraction wallets, and even as traditional wallet providers remain cautious, the usage of UserOperation on Ethereum has continued to rise since March this year, experiencing rapid expansion.

Monthly usage changes of UserOperation on Ethereum, Source: Dune, Date: October 8, 2023

5. Opportunities Brought by ERC4337

Overview of ERC4337, Source: Kernel Ventures

5.1 Miners Bundler under ERC4337

In ERC4337, Bundler is introduced to separate account entities from account control. Only an EOA account with a certain amount of Ethereum stored can act as a Bundler. Compared to traditional mining under the POW mechanism, this new mining method has almost zero input costs and does not carry potential legal risks. In contrast to staking mining under the POS mechanism, Bundler has an extremely low participation threshold, requiring no staking of 32 Ethereum, only needing to retain enough gas to interact with the Entry Point contract once. The fundamental reason for this difference is that the difficulty of malicious actions by Bundlers is much higher than that of validating nodes, and the potential gains from malicious actions are far lower than those of validating nodes, thus not requiring a large amount of Ethereum to ensure the balance of rewards and penalties in the overall operation of the ERC4337 protocol. Finally, compared to staking rewards in liquidity pools, Bundler offers shorter lock-up periods, providing higher liquidity for assets, allowing users to withdraw promptly to reduce losses during significant sell-offs on Ethereum. Given these advantages, Bundler is likely to become a new investment method on Ethereum and further give rise to Bundler pools similar to Bitcoin mining pools and Ethereum staking pools, characterized by low costs, stable returns, and high liquidity.

5.2 Intent-Centric under ERC4337

Intent-centric refers to a user-centered approach where users do not need to understand the specific execution steps when performing operations; instead, the program automatically executes modular operations based on user needs. For new investors entering web3, the various signatures and gas settings in transactions are very unfriendly, so even if they are interested in crypto, they often rely on CEX for investment and cannot enter the true web3 world. The essence of this phenomenon lies in the differences in operational intent between DEX and CEX. For example, if someone wants to exchange their USDT for ETH in the most profitable way through DEX, they must first select the optimal trading pool from many options, then sign to authorize the Dapp a certain permission, sign to confirm staking USDT into the liquidity pool, and finally sign to confirm withdrawing the equivalent ETH from the liquidity pool. Each of these steps is based on behavioral operations, with one operation corresponding to one underlying action.

However, in CEX, operations are intent-based. To achieve the intent of exchanging USDT for ETH in the most favorable way, only a market order is needed; users do not need to set or understand specific order prices. Although some argue that completing this series of processes independently can provide a more detailed understanding of the transaction process and prevent potential inherent issues in modular processes, overall, very few people possess this capability. Most people only need a modular process that can realize their intent without the desire to understand the corresponding specific operations behind it.

At the same time, manual operations carry higher risks compared to long-tested modular processes. Before the advent of ERC4337 account abstraction, EOA accounts had low execution efficiency, requiring individual signatures for each transaction, which hindered the development of intent-centric applications that modularly process transactions according to user intent on Ethereum. In ERC4337, by introducing UserOperation and Bundler, users do not sign each transaction; instead, they send transactions (UserOperations in ERC4337) to a backup memory pool, mixing them with their own or other users' UserOperations, waiting for Bundler to bundle these UserOperations and submit them to the entry contract for verification and execution. In this process, users only need to declare or sign their preferences, while Bundlers choose and execute the specific process according to existing consensus layer or contract layer logic without requiring user involvement in any specific processes. In Dapps, we can design intent-centric logic, allowing users to simply sign their intent when they want to achieve a goal, rather than selecting transaction behaviors and signing each one as before. It can be anticipated that with the widespread promotion of ERC4337, intent-centric Dapps will become popular on Ethereum, significantly lowering the entry barriers to web3.

5.3 Defi under ERC4337

Defi was closely linked to EOA accounts during the last bull market, enhancing the diversity of on-chain interaction functions for crypto investors and providing various financial methods such as staking, market-making, and lending, ultimately leading to Defi Summer. However, the complex transaction processes and on-chain losses of Defi have set a significant barrier to participation for ordinary users, hindering further promotion of Defi. The combination of ERC4337 wallets and Defi can provide intent-centric interaction methods, allowing users to experience something close to CEX. Additionally, through the Paymaster in ERC4337, gas-free transactions can be realized, and some operators can use this method to lower the barriers to Defi and attract more participants.

However, unlike tracks like Socialfi and gamefi, Defi involves a large number of token transfers and staking, requiring high security. The contract layer of account abstraction has relatively high complexity, making it prone to security vulnerabilities that could lead to the loss of users' crypto assets. Moreover, since the U.S. government issued bans on many mixing contracts like Tornado, many Defi projects strictly review or even suspend interactions with contract addresses, leading to significant incompatibilities between smart contract wallets and the current Defi systems. There is even a possibility of being mistakenly blacklisted during interactions with Defi contracts, which poses considerable obstacles to the promotion of ERC4337 wallets in Defi.

5.4 Full-Chain Games under ERC4337

Unlike early gamefi's "semi-chain" games, which only put game assets and items on-chain to ensure asset security through decentralization, full-chain games write the core logic and economic models of the game into on-chain smart contracts, achieving complete decentralization and high security in game interactions. However, current web3 games aiming for full-chain status come at a significant cost. First, there is a surge in gas fees; every interaction involving on-chain games, items, and scenes must be recorded on-chain, leading to skyrocketing game costs. To address this issue, the interaction logic of current full-chain games is often very simple, which limits the user transaction experience. Additionally, using traditional EOA accounts in full-chain game interactions requires enduring a cumbersome verification process, confirming each interaction, which greatly diminishes the gaming experience. With the introduction of account abstraction, transaction costs are significantly reduced, and the transaction confirmation process only requires BLS aggregated signatures and a single verification, greatly saving gas consumption in cryptographic verification processes.

Furthermore, batch packaging transactions can consolidate the previously required confirmations. The introduction of personalized smart contract accounts can facilitate the modular construction of full-chain games, improving development efficiency. However, to date, the combination of account abstraction and full-chain games has primarily appeared on Layer 2 solutions like StarkNet, which have achieved native account abstraction, such as the projects Loot Realms and Cartridge. The reason is not that Ethereum is unsuitable for full-chain games or the combination with ERC4337 wallets, but rather that the Entry Point contract was only completed on-chain in March this year, so many full-chain games based on ERC4337 on Ethereum are still in development. It can be anticipated that many full-chain games based on ERC4337 will soon land on Ethereum, significantly improving the interaction experience and reducing interaction costs. Additionally, some existing large full-chain games on Ethereum, such as Dark Forest and Wolf Games, may also consider making changes to their contract layers to be compatible with ERC4337 account interactions.

5.5 Socialfi under ERC4337

Constrained by the binding mechanism of private key accounts and the limited interaction functions of EOA accounts, Socialfi has long faced high participation barriers and account management difficulties. Poor user experience has greatly limited the development potential of SocialFi projects, and the introduction of account abstraction will fundamentally change this situation. However, the trade-off between convenience, retrievability, and security still needs to be weighed based on the importance of specific web3 accounts in Socialfi. First, the separation of private keys and account control means users no longer need to manage complex and disordered private keys or mnemonic phrases, and they can dynamically adjust account passwords. For example, the ERC4337 project Ambire launched at the end of 2021 allows for the creation and recovery of web3 accounts via email. Secondly, the batch processing transactions provided by ERC4337 address the web3 threshold issue raised at the beginning of this article, allowing what can be solved with a single button in web2 to also be resolved with a single button in web3. Finally, the introduction of customizable code logic in ERC4337 accounts is also closer to the personalized design of accounts in web2, allowing each Socialfi account to introduce different account functions according to user preferences, similar to how QQ users can choose whether to enable channel features based on their preferences.

6. Future Outlook

As of the time of writing, the number of web3 users is approximately 300 million, accounting for about 4% of the global population, leaving significant room for growth compared to the 6 billion internet users worldwide. For web3 to catch up with the scale of web2 and surpass the 1 billion user mark, lower participation thresholds and more account customization features are prerequisites. Among all options to achieve this goal, ERC4337 presents a relatively low-risk, mature framework that has received recognition from the Ethereum Foundation and major developers. Therefore, since the deployment of the Entry Point contract on Ethereum, the number of users utilizing account abstraction has also experienced explosive growth.

Monthly new user growth for Ethereum account abstraction, Source: Dune, Date: October 11, 2023

Although ERC4337 is now widely recognized and promoted by the Ethereum community, it still faces several issues in practical implementation. First is the uncertainty of its standards; many supplementary proposals for ERC4377 are still under review, making the final overall implementation form uncertain, which poses significant obstacles to the development of ERC4377 ecosystem projects. Secondly, the update costs of ERC4377 are high; once the entry point contract is deployed, the majority of wallets across the network must uniformly cover the original addresses to complete the update, which is extremely costly. Lastly, there are compatibility issues with existing Dapps and cross-chain bridges; to fully implement ERC4337, existing Dapps on Ethereum need extensive upgrades, facing high security risks and costs.

However, ERC4377 has also actively responded to these issues, such as improving Bundler's packaging efficiency by adding external smart contracts, enhancing the permissions of smart contract accounts through additional opcodes, and supplementing EIP proposals to address the difficulties in upgrading the Entry Point. At the same time, in response to the incompatibility issues with traditional Dapps, ERC4337 is actively building its ecosystem to promote the broader application of account abstraction wallets on Ethereum. The comprehensive implementation of ERC4337 wallets can achieve EVM intent-centric operations at the virtual machine level, and further abstraction of EVM intent-centric operations in Dapps can simplify operations in web3 to the user-intent-centered ease of web2. If intent-centric operations can be fully realized in Ethereum Dapps, Defi, gamefi, and almost all tracks that require operational simplicity and automation will significantly optimize user experience, attracting more outsiders to participate. However, tracks like Defi, which directly involve token transfers, may be relatively conservative in growth due to their stringent security requirements. In contrast, tracks like Socialfi and gamefi prioritize user experience, somewhat downplaying security. Yet, previously hindered by the limitations of EOA accounts, they have been unable to implement complex interaction designs. Through ERC4337, these tracks can address the two major issues of high user thresholds and poor user experience, leading to a massive increase in user numbers and potentially becoming a major breakout point in the next bull market.

Related tags

ERC-4337 Ethereum

ChainCatcher reminds readers to view blockchain rationally, enhance risk awareness, and be cautious of various virtual token issuances and speculations. All content on this site is solely market information or related party opinions, and does not constitute any form of investment advice. If you find sensitive information in the content, please click "Report", and we will handle it promptly.