Author: CloudY, Jam
Editor: Vincero, YL
Review: Yasmine
A wallet account is an essential part of entering Web3, and the UTXO model of the Bitcoin network and the account model of the Ethereum network have always been compared. Of course, the two models have their own advantages and disadvantages. We cannot simply say which one is better, but we can only say which scenarios are more suitable.
overview
But in fact, the Ethereum EOA account used for comparison is a relatively primitive product. Specifically:
Account control is single, with only signature authorization and no signature. Whether it is a transaction worth $1 or $100 million, you need to approve it first and then sign to confirm the transaction. So the difference between the defrauded permissions and normal transactions is only one signature, which makes every new user tremble with fear when interacting. Although Metamask now allows users to choose the approved usage when users approve token permissions, for frequent interactions, users prefer to directly authorize the upper limit of the number rather than consuming Gas Fee by approving multiple times. Compared with the Web2 account model, which uses Two Factor Authentication (2FA) or U-Shield to control the risk of large transactions, and face scanning or password-free payment to facilitate small transactions, EOA accounts are very rigid and difficult to use.
The high threshold of Gas Fee has blocked a large number of new users. Ethereum mainnet and Layer2 such as Optimism/Arbitrum use ETH tokens as Gas tokens, which requires users to convert fiat currency into USD stablecoins, and then further convert it into ETH, and then transfer ETH to their wallets. However, many users only discovered that they needed ETH as Gas after transferring USD stablecoins to their wallets, and had to buy ETH again. What's more, public chains such as BSC/Polygon/Solana all use their own Gas tokens, which is another pitfall for newcomers. In addition, many users do not really want to buy spot Gas tokens, but because they need to interact on the chain, they have to leave a large number of redundant Gas tokens in their wallets.
Vitalik has known for a long time that EOA accounts are difficult to use, and the Ethereum team is also trying to solve this problem, and account abstraction is one of the solutions. However, since it is impossible to modify the underlying consensus of Ethereum for account abstraction, account abstraction did not really receive attention until the proposal of ERC-4337, a smart contract wallet based on the application layer, and became a hot topic.
After briefly introducing account abstraction and ERC-4337, this article will speculate on the future evolution of the Web3 account system and the ownership of traffic entrances based on the application of account abstraction and the development of the Web2 account system.
From an ecological perspective, users used to need to use EOA to perform complex on-chain operations, and due to the limited development of the on-chain ecology, only limited protocols can be provided, and the actual needs of users cannot be effectively met. Account abstraction simplifies the execution of the above operations, and only requires user input to get output, without frequent clicks and cumbersome signatures. It can be said that the implementation of AA has shifted the on-chain ecology from seller-dominated to buyer-dominated.
Account Abstraction and ERC-4337
What does Account Abstraction (AA) specifically mean? It abstracts the underlying technology and data structure to simplify the operation steps for users and developers. In simple terms, it means "implementing CA functionality based on EOA."
ERC-4337 has become the basic standard for AA. ERC-4337 introduces UserOperation, which is a special transaction that represents user intent and allows contract accounts to actively perform operations. These UserOperations are managed by a role called Bundler, which simulates the execution of UserOperations and adds valid operations to a special transaction pool. The EntryPoint contract then verifies and executes these UserOperations to realize user intent.
account type
There are two main types of accounts in Ethereum: EOA (Externally Owned Account) accounts and Contract Account accounts.
The address length of an EOA account is 20 bytes, which is calculated from the private key generated when the user creates it and the public key generated by the elliptic curve encryption algorithm. The EOA account status includes the number of transactions (Nonce) and the amount of assets (Balance). The addresses of contract accounts are also 20 bytes, but they are calculated from the sender address and Nonce of the contract creation transaction. The contract account status includes the number of contracts (Nonce), the amount of assets (Balance), the code hash (CodeHash), and the storage root hash (StorageRoot), which is used to store the root node hash value of the Merkle Patricia Trie tree of the contract data.
Account type and status information is crucial for transactions and smart contract execution on Ethereum, and is also the difference between EOA and CA.
trade
Ethereum transactions include sender and receiver information, digital signatures, transaction times, amount of funds transferred, optional data, gas limits, and transaction fees. The above two different account types produce two completely different types of communication transactions.
During the signing process, the transaction data is hashed and digitally signed. The verifier verifies the validity of the signature by calculating the points on the elliptic curve. There is no need to obtain the sender's private key, only the transaction information and public key. The recovery of the public key is achieved through the v value in the signature, ensuring the security of the signature and the efficiency of verification.
Account Abstraction
Ethereum's transaction structure and signature verification process reveal an important fact, that is, the account initiating the transaction must be an EOA account with a public-private key pair.
Contract accounts, due to the lack of public and private key pairs, cannot actively initiate transactions. Instead, they automatically execute the smart contract code in the account based on the information in the transaction after receiving the transaction, or send transaction information to other accounts, or even create new smart contracts. Therefore, wallets currently created by mainstream wallet applications such as Metamask are EOA accounts. However, EOA accounts have some defects in use: private key risks, limited signature algorithms, excessive signature permissions, and transaction fee restrictions.
Contract accounts can store code and data and execute predefined smart contract logic to solve the above problems of EOA accounts. However, contract accounts cannot actively initiate transactions.
Account abstraction is an improvement on the above two accounts, attempting to blur the boundary between the two and turn it into a universal account containing complex logic, so that the account can have the functions of both CA (contract account) and EOA account.
ERC-4337
ERC-4337 completed the account abstraction function without modifying the Ethereum consensus layer, and became the solution finally adopted by Ethereum. It finally realized the ultimate vision of off-chain matching and on-chain transactions.
UserOperation
ERC-4337 introduces a new concept called UserOperation to solve the problem that contract accounts cannot actively initiate transactions, while avoiding changing the underlying transaction type of the Ethereum protocol.
UserOperation is similar to a standard transaction, but it only represents the user's intention rather than a direct transaction behavior. Standard transactions are sent to Ethereum's mempool (transaction pool), then combined into a complete block by the searcher and builder, and finally sent to the blockchain by the proposer, usually selecting the block with the highest reward. Unlike this, UserOperation is not a real transaction, so ERC-4337 introduces a role called Bundler and a new mempool to execute UserOperation in a decentralized manner. This innovation allows user intentions to be processed and executed without directly participating in the standard transaction process.
Bundler
When processing UserOperation, Bundler first performs a basic legitimacy check and then simulates the execution of the operation to confirm the validity of the signature. If the simulation is successful, the UserOperation will be added to the UserOperation mempool to wait for actual on-chain execution.
To ensure consistency between simulation and actual execution, UserOperation restricts access to variables that may change during execution and only allows access to data related to the sender's address. Bundler can package UserOperation according to its own preferences, giving priority to operations that pay higher fees. Ultimately, Bundler sends valid batches of operations to the EntryPoint contract for on-chain execution.
EntryPoint
EntryPoint is a singleton contract in Ethereum, whose main task is to handle the execution of UserOperation. It has two key functions: handleOps and handleAggregatedOps, both of which verify UserOperation first and then execute the operation. Verification includes checking the account, signature validity, and fee payment. In the execution phase, the data in UserOperation is used to call the smart contract code in the target contract account. Different smart contract wallet protocols may have different parsing and execution methods.
data
According to SixdegreeLab’s ERC-4337 semi-annual data report:
After the ERC-4337 contract was deployed, more than 687,000 AA wallets were created on the chain, and more than 2 million UserOps were called. However, 88.24% of the AA wallets were used no more than 5 times, most of which were direct transfers or NFT minting.
Of the 15,000 bundlers, pimlico holds the largest market share at 43.48%, while Alchemy has generated the highest revenue ever at approximately $20,000.
However, 97.18% of Bundled transactions only contain 1 UserOp, which means that 90% of Bundlers cannot make a profit through packaged transactions.
A total of 117 Paymasters paid $465,000 in gas fees for 19 million UserOps, of which Pimlico paid 43.45%.
ZeroDev dominates Wallet Factory, deploying 62.63% of accounts.
The most commonly used AA wallet construction method is LEGO, which uses different third-party Paymaster, Wallet Factory and Bundler.
It can be seen that the adoption rate of ERC-4337 still has a lot of room for growth, and the construction of infrastructure has just begun, which makes the future of AA full of possibilities. With the rise of Layer2 and social applications, the use of AA wallets will usher in a wave of rapid growth.
The direction of account abstraction
After understanding the basic principles of account abstraction and the architecture of ERC-4337, we will further explore the expansion methods of AA. We will not go into the basic functions of smart contract wallets such as no private key and no gas, but look for more possibilities in the components of AA:
Architecture
Native Account Abstraction
ERC-4337 is just an application layer solution to the current situation that Ethereum cannot modify the underlying consensus. Although it can make the abstract concept of accounts widely popular, it is still interacting under the guise of contract accounts. The extra gas consumption in the verification process, the adoption of other competing ERCs, and the prohibition of dapps on contract account interaction are all factors that hinder the growth of ERC-4337.
Therefore, native account abstraction, especially Layer2 native account abstraction, is particularly important. Among the current Layer2s, only Starknet and ZKSync support native account abstraction. As shown in the figure below, there is no Bundler and Paymaster in the native account abstraction scheme. Starknet uses Sequencer to determine the transaction order, pay Gas and execute. ZKSync determines the transaction order and pays Gas through Operator, and then calls bootloader to operate together.
DeBank Chain, which claims to be built on OP Stack, also needs to natively integrate a system similar to account abstraction at the chain level, but the specific architecture will only be known when its mainnet is launched.
NFT Contract Wallet
NFT contract wallets are an application-layer account abstraction scheme similar to ERC-4337. They enable EOA accounts to have the functions of CA accounts through NFT, rather than calling the EntryPoint contract through Bundler. There are currently two mainstream implementations of NFT contract wallets: ERC-6551 and A3S Protocol.
ERC-6551 allows users to use the ERC-721 standard NFT in their EOA wallet as a controller to control one or more newly created smart contract wallets, thereby matching one or more smart contract accounts for existing NFTs through "plug-in contracts" without modifying the ERC-721 code. This method combines existing NFTs with account abstraction, which not only opens up the application scenarios of NFTs but also popularizes the concept of account abstraction.
A3S Protocol uses the smart contract of NFT itself as the smart contract wallet, which means that the wallet assets are on the smart contract account of NFT and completely follow the transfer of NFT ownership. There is no need to plug in a contract account as a wallet for the NFT contract like ERC-6551. The NFT contract wallet is realized in a shorter path, but this also means incompatibility with existing NFTs.
In terms of the unification of multi-chain wallet addresses, both solutions use the obfuscation value Salt to achieve the same address on different EVM-compatible public chains to solve the problem of confusion in multi-chain addresses of contract accounts. This is also the problem that caused Wintermute to lose 20 million OP tokens when transferring to multi-signature addresses on different chains.
Modularity and multi-chain abstraction
The significance of modular account abstraction is to minimize the cost of development and maintenance like OP Stack, so that wallet developers can focus more on the product itself rather than the construction and maintenance of the underlying infrastructure. Of course, the modular ecosystem established in this way is also the foundation of the modular platform, so modular account abstraction must be implemented:
• Inter-composability of modules (EIP-6900 is trying to set a standard implementation)
• Diversity of module functions (signature scheme/privacy/anti-MEV/deposit and withdrawal/Intent, etc.)
• Security (each module has a unified standard to avoid storage conflicts)
• Multi-chain abstraction (Vitalik proposed using a unified single-chain keystore contract to achieve multi-chain smart contract account collaboration)
We mentioned above that Salt is used to make the multi-chain smart contract account addresses consistent, but consistent addresses are only the first step. What is more important is to make users unaware of cross-chain operations, that is, multi-chain abstraction. This is an important step in modularization and an important step in account abstraction.
Signature Verification
We mentioned before that any transaction on Ethereum can only rely on EOA to initiate and pay ETH as Gas. In addition, EOA can only use the ECDSA signature scheme, which makes the use of EOA very cumbersome and single-function, and there is also the risk of private key leakage. The day when quantum computers come out is also the day when Ethereum EOA accounts become lambs to be slaughtered.
Signature Algorithm
At the signature level, there are currently solutions that use smart contracts to implement multi-signature and social recovery (Gnosis Safe and Argent), and there are also solutions that use so-called signature abstraction to achieve free interaction with contracts within a given scope after one authorization (Lens Protocl). However, according to "Not your keys, not your coins", we can pay more attention to the signature algorithm itself:
Signature Aggregation
Schnorr or BLS can achieve more efficient and simpler signatures, which can not only realize multi-signature from the bottom layer, but also reduce Gas consumption by aggregating signatures. Of course, they all have their own problems, such as requiring additional communication rounds, not suitable for multi-signature schemes with larger values of m and n, and a lot of matching verification time.
Post-quantum secure signatures
One-time signatures such as Lamport or W-OTS can prevent others from using quantum computers to crack part of the public private key to forge messages and signatures.
UserOperation
ERC7521 Intent Centric
When we compare account abstraction, especially ERC-4337, and the architecture of Intent Centric, we can find that Bundler and Solver can actually be the same person. That is to say, the user's interactive content "UserOperation" can be given by Bundler, which parses the user's intent and proposes a matching solution path, and then confirms the legitimacy of the path to the user through the EntryPoint contract to prevent Bundler from doing evil, and finally executes the verified intent path.
The combination of account abstraction and intent will enable the simultaneous abstraction of accounts and interactions, achieving a user experience that goes beyond Web2.
The entire transaction process can be implemented through witness/challenge and response processes, using ZK proof technology to achieve private payment. This not only allows users to prove the validity of transactions without revealing the sender's real address, but also batches multiple transactions into a single proof, thereby reducing computational overhead and significantly improving scalability, which is the so-called cost reduction and efficiency improvement. . Some corporate users who need to face supervision can also make transparent transactions to regulators independently to meet regulatory compliance requirements without sacrificing confidentiality.
Bundler
Bundler MEV 与 Bundler Competition
Bundler MEV and Bundler Competition are both the result of incomplete infrastructure. Bundler MEV comes from the transaction packaging responsibility of Bundler, which is similar to Searcher. Bundler can change the submission order of UserOperation to make a profit, while Bundler Competition occurs when different Bundlers package the same UserOperation. This is similar to the Gas War of Searcher. The Bundler that packaged the UserOperation without putting it on the chain spends Gas, but the transaction fails.
They can all draw on existing infrastructure, such as MEV-Boost, to open up communication channels between Bundler and between Bundler and Block Builder. Etherspot is developing a p2p network of mempool for AA, and UserOperations waiting to be packaged will be transmitted in this p2p network. Once packaged and processed on the chain, they will be marked and removed from the list to avoid being packaged by multiple Bundler.
Paymaster
Paymaster deposits and withdrawals
Paymaster can pay Gas Fee for users and negotiate with users to use any token or legal currency as a substitute. Therefore, it is a good solution for Paymaster to cooperate with payment service providers to provide deposit and withdrawal services for users.
The Visa team deployed two experimental Visa Paymaster contracts on the Ethereum Goerli testnet, one to explore whether users can pay fees with other tokens including USD stablecoins, and the other to try to directly sponsor transaction fees. Of course, integrating Paymaster with existing ERC-20 tokens requires the use of an external source or on-chain oracle to determine the token price and check whether the Paymaster contract has approved the collection of specified tokens from users. Under this mature solution, directly connecting to Visa cards to pay for Gas with fiat currency, and even converting with ERC-20 tokens in real time, and realizing the abstraction of deposits and withdrawals will greatly reduce the entry threshold for Web2 users.
Web3 Account System Evolution and Future Web3 Entry
The evolution of network traffic entrances and corresponding account systems in the Web2 era reflects the rapid development of the second-generation Internet and changes in user needs.
Initially, users accessed the Internet through portals, where they could freely choose online resources listed on the portals. Then, the emergence of search engines enabled users to query keywords through search engines, which provided relevant results by analyzing URLs. The Web2 era witnessed the rise of social platforms, both PC and mobile. In addition to actively using search engines to access Web2, users can also passively access Web2 through information on PC media platforms, or independently access Web2 through PC/mobile media platforms. During this period, there were two processes from passive to active, and one process of information decentralization.
The account system of Web2 is also changing. From the initial SMS/MMS using mobile phone numbers as accounts, to QQ/WeChat/blogs/Weibo establishing multiple accounts and gaining rich additional functions and independent personal network identities, these platforms have introduced profiles and contact lists, expanding user identification from a single URL to a more complex user ID and social graph.
With the development of network and hardware technology, two ways of developing their own ecosystem have emerged:
After establishing their own accounts and payment system traffic advantages, "iOS+Apple Pay+Apple Store" and "WeChat Pay+Mini Programs" have opened up an area for external developers to access, thereby keeping users within their own systems and strengthening the ecosystem.
"Taobao + Alipay" and "Douyin + Douyin Pay" develop their own accounts and payment systems based on the traffic brought by popular applications, and further integrate other applications to establish a unified account and payment system.
Both methods are effective and have their own niche. WeChat can meet most of the users' needs within one app, while Alipay payment can also be found in major apps.
In summary, the traffic entrance in the Web2 era aims to give users more initiative and decentralization, while the account system has evolved from single to rich and diverse, and realizes the development of its own ecology in two ways.
Account system
The evolution of the account system in the Web3 era retains some of the shadows of Web2 while presenting a unique development path.
The evolution of the account system in the Web3 era continues some of the characteristics of Web2, while presenting a unique development path. In Web3, there are many types of accounts, including plug-in wallets such as Metamask, software wallets such as Math and Trust, "operating platforms" such as dAppOS and Gnosis Safe, as well as UniPass embedded in dApps and OKX Web3 Wallet built into exchanges.
Plugin wallets such as Metamask are like the original text messages that can meet the most basic needs of users. Although they can be used everywhere, their functions are too single.
Software wallets such as Math and Trust are like QQ and WeChat, with various optimizations and features that enhance the user experience on top of the basic functions, such as multi-account management/social sections/affiliated applications, etc.
Compared with software wallets, "operating platforms" such as dAppOS and Gnosis Safe have gone a step further by upgrading basic functions to build another advanced account system, similar to Apple and WeChat, and have developed supporting "mini-programs" with themselves as the core to enrich the ecosystem.
Built-in wallets in apps such as UniPass and OKX Web3 Wallet are like Alipay and TikTok Pay, which take another type of account and payment route. They use the traffic of popular apps to develop their own users and establish an ecosystem through alliances.
Traffic inlet
We mentioned in the article "Web3 Traffic Entrance":
“Based on the process of users entering Web3, we can define Web3 traffic entrances into two major categories:
Account system (deposit and withdrawal and fund management): centralized exchanges, independent deposit and withdrawal projects, deposit and withdrawal aggregators, cryptocurrency ATMs, cryptocurrency bank cards and over-the-counter transactions (OTC); EOA, CA, MPC wallets and account abstraction (AA).
Web3 dapp (tools, social networking and entertainment): DEX, NFT Marketplace, domain name, DeSoc, copyright trading market, GameFi, X to Earn. ”
We still think so today, but according to the second part, all of these entrances can become part of the AA wallet. However, they also reversely divide the adoption path of the AA wallet into two categories, namely the account and application mentioned above, whether the user first obtains the account and then interacts with the application or first interacts with the application and then uses the account.
Wallet Mini Program and Wallet as a Service
When we look at the process of AA adoption, we can find that Instadapp's independent AA wallet product Avocado was first released, followed by Metamask's release of the Snaps mini-program component to support some AA functions. Payment giant Visa also joined Paymaster to test the waters and connected to Visa Card payments. Soon, the social application Lens Protocol tried to establish an AA wallet through ERC-6551, and Safe also became compatible with ERC-4337 to consolidate its own "mini-program" market. Following closely, OKX Wallet supported the use of AA wallets, and Circle chose to release its own AA wallet.
From this, we can easily find that there are two modes of AA adoption:
AA uses its own wallet to launch or be compatible with AA to attract and retain users through wallet users and internal application applets.
Applications/exchanges/payment service providers leverage their own traffic advantages to convert users into AA wallet users.
This also leads to the part we need to discuss: Since the on-chain ecosystem will change from a seller's market to a buyer's market due to the emergence of AA, which model will users pay for?
Applets
From the perspective of short-term adoption rate, the AA model based on the development of mini-program ecosystem based on its own wallet will be more easily accepted by users, which is essentially a To C solution. Because most of the users who are currently trying AA wallets are still Web3 users, the wallet itself is not unfamiliar to them and can be used directly without additional understanding, and the rich functions and smooth operation experience can attract and retain them. Taking MetaMask's Snaps as an example, the API interface allows third parties to develop corresponding wallet mini-programs to interact on non-EVM chains. It seems to be a traffic diversion for other wallets, but in fact it is to build an ecosystem for itself to educate users. There is no doubt that the day when MetaMask is fully compatible with ERC-4337 is the day when it becomes the leader of AA wallets.
When we take dappOS as an example:
dappOS=dappOS Account (multi-chain unified EOA) + dappOS Network.
dappOS Account: allows users to use a "unified account" based on account abstraction instead of an ordinary externally owned account (EOA). This approach makes it possible for users to restore accounts, pre-batch transactions, automate execution and other functions. At the same time, the multi-chain wallet aggregation method can also facilitate users to uniformly manage assets on different chains.
dappOS Network: A decentralized network that helps users automate wallet and cross-chain operations and complete the complex interaction process behind transactions.
DappOS attempts to separate the concepts of accounts, public chains, and Gas Tokens, so that users can have a similar experience to Web2 accounts. However, since it is still in a relatively early stage, the platform's cooperative dapps are limited, but this does not hinder the growth of its user data. Because users are motivated to enter from EOA, especially users who need multi-account multi-chain interaction, the interactive experience after migration is greater than the migration cost. The most important thing is that once users enter, this account system will basically not leave, because users are also being educated while using it. First of all, users who come into contact with AA wallets at the beginning cannot use EOA wallets. Secondly, wallets such as dappOS can meet most of the user's interaction needs, and users do not have to migrate. Finally, even if users want to migrate, the invisible multi-chain abstraction will make the entire migration process cumbersome.
It can be seen that mature wallet products can acquire and retain Web3 AA users faster, such as Safe, Avocado, OKX Wallet, etc.
Waas
WaaS is an AA wallet that is an application-based wallet, as opposed to the AA wallet that is a mini-program. The application comes first and then the wallet, which is obviously a To B solution. Applications use WaaS to customize their own wallets to match product functions. Standardized WaaS modules are provided for different applications to choose from. They use the traffic of applications to expand their own ecosystem, build an AA wallet platform, and then turn to the C-end to issue customized wallets for users. Users can freely match the wallet functions they need.
Take Stepn as an example. As an out-of-circle application, Stepn has tens of millions of users around the world, and each user has created a wallet through Stepn. If Stepn has an AA wallet built in and uses this wallet as the core instead of just GMT tokens, and continues to develop the ecosystem, such as the subsequent MOOAR NFT trading market, mahjong games and Gashero. Then this AA wallet alone can bring tens of millions of incremental users to the entire Crypto market, and these users are highly sticky users of this AA wallet, because the migration cost is extremely high for them.
The same is true for the recently popular Friend Tech. Every Twitter user can be a potential user of its AA wallet, and fiat currency deposits and withdrawals and gas payments can allow users to overcome the interaction barriers of Web3 and quickly integrate into Web3.
Among the products that have been put into use, we can focus on WaaS Pay and UniPass. These two products represent the characteristics of WaaS wallets respectively:
WaaS Pay is a smart contract account deployment platform that leverages the Safe{Core} protocol suite and the Safe{Core} Account Abstraction SDK, designed for organizations seeking instant blockchain payments while prioritizing privacy. It provides a user-friendly, code-free interface to customize smart contract account features such as social login, fiat currency on/off ramps, and gas-free transactions for recipients. By facilitating anonymous transactions through zero-knowledge proofs (ZKP) via ZKBob, WaaS Pay ensures that sensitive financial data remains secure and confidential. The platform is powered by Polygon ZKEVM, which guarantees scalability and efficiency, while a self-hosted IPFS node with Helia protects sensitive metadata.
UniPass is essentially an SDK for third-party dapps, which allows dapps to bypass the traditional account private key and a series of signatures and gas restrictions or the centralization of the escrow private key to generate the email binding address, and directly use UniPass's DKIM verification to realize the non-escrow account controlled by the email. At the same time, the chain interaction is simplified through the Relayer, and no gas/signature abstraction/social reply and other functions are achieved, which greatly improve the user interaction experience. As a scenario-driven application, UniPass chooses to provide customized services for different applications in the form of a federal social network while establishing an interoperable account system. Based on the interoperability of this federal social network, on the premise of providing data ownership and privacy protection, social relationships are put on the chain, and the use scenario of DID with ownership of data and assets is established to attract more applications to use UniPass's SDK to enter Web3. And the users of these applications naturally become UniPass users, and continue to interact with it in Web3, and the stickiness is extremely high.
From this we can also see that the AA wallet of the WaaS route has more advantages in terms of growth space and acquisition of Web2 users, but this is a great test of the team's product quality and BD capabilities. However, once the network effect is formed, it will have growth inertia and is a type that will be developed in the later stage.
Reference
[1] Sixdegree ERC4337 Half-Year Data Report
https://sixdegree.xyz/research/Half-Year-Data-Report-of-ERC4337-by-Sixdegree.pdf
[2] "Long article on in-depth interpretation of "account abstraction": 7 years of route evolution and track map"
https://www.chaincatcher.com/article/2085142
[3] “Interpreting Binance Research Account Abstract Report”
https://www.techflowpost.com/article/detail_12784.html
[4]《EIP-6551》
https://eips.ethereum.org/EIPS/eip-6551
[5]《A3S Protocol Gitbook 》
https://a3sprotocolcontact.gitbook.io/a3s-protocol/a3s-v1.0/how-a3s-v1.0-works
[6]《Future of Smart Accounts: Modular, Specialised & Multichain》
https://longhashvc.medium.com/future-of-smart-accounts-modular-specialised-multichain-d04f083375a6
[7] Why ERC-4337 Bundler needs to cooperate with Block Builders
https://learnblockchain.cn/article/6205
[8] A Complete Guide to Account Abstraction
https://news.marsbit.co/20230302172702633640.html
[9] How infrastructure can support billions of users through account abstraction
https://www.panewslab.com/zh/articledetails/24hz8399g6my.html
[10]《You Could Have Invented Account Abstraction: Part 1》
https://www.alchemy.com/blog/account-abstraction
[11] “Ethereum Account Abstraction Research Report: Dissecting 10 Related EIP Proposals and the Bottleneck Problems of Achieving Ten Million Daily Active Users”
https://www.odaily.news/post/5183201
