Account abstraction implementation, the on-chain ecosystem will shift towards the buyer’s market.

With the implementation of account abstraction, the on-chain ecosystem will shift towards a buyer's market.

Author: CloudY, Jam

Editor: Vincero, YL

Reviewer: Yasmine

• A Review of Eight Hot Events in the Cryptocurrency Market in Q3
• Variant联创 Li Jin The main obstacle to the mainstream adoption of cryptocurrencies is the issue of product-market fit.
• BRC-20 speculation is prevalent, will the new FT protocol Rune released by Ordinals founder bring a new trend?

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 for their advantages and disadvantages. Of course, both models have their own merits, and it cannot be simply said which one is better, but rather which one is more suitable for certain scenarios.

But in fact, the Ethereum EOA account used for comparison is a relatively primitive product. Specifically:

• The account control is single, with only signing authorization and not signing. Whether it is a $1 transaction or a $100 million transaction, it needs to be approved first and then signed to confirm the transaction. So the only difference between being scammed and a normal transaction is a signature, which makes every new user nervous during interactions. Although now Metamask allows users to choose the approved amount when approving token permissions, for frequent interaction behaviors, users prefer to directly authorize the maximum quantity instead of approving multiple times and consuming gas fees. Compared to the account models in Web2, such as Two Factor Authentication (2FA) or hardware tokens to control the risk of large transactions, and face scanning or password-free payments to facilitate small transactions, the EOA account is very rigid and difficult to use.

• The high threshold of gas fees blocks a large number of new users. The Ethereum mainnet and Layer2 solutions such as Optimism/Arbitrum use ETH tokens as gas tokens, which requires users to convert fiat currency into stablecoins, then further convert them into ETH, and then transfer ETH into the wallet. Many users only realize that they need ETH as gas after transferring stablecoins into the wallet, and they have to buy ETH again. Moreover, public chains such as BSC/Polygon/Solana use their own gas tokens, which is another pitfall for newcomers. In addition, many users don’t really want to buy gas tokens on the spot, but they have to leave a large amount of redundant gas tokens in the wallet because they need on-chain interactions.

EOA accounts are so difficult to use, and Vitalik has known this for a long time. The Ethereum team has also been trying to solve this problem, and account abstraction is one of the solutions. However, because it is impossible to modify the underlying consensus of Ethereum for account abstraction, it was not until the proposal of ERC-4337, a smart contract wallet based on the application layer, that account abstraction truly received attention and became a hot topic.

This article will briefly introduce account abstraction and ERC-4337, and based on the application of account abstraction and the development of the Web2 account system, speculate on the evolution of the Web3 account system and the ownership of traffic entry points.

From an ecological perspective, in the past, users needed to use EOA to perform complex on-chain operations, and due to the limited development of on-chain ecology, only limited protocols could be provided, and users’ actual needs could not be effectively met. Account abstraction simplifies the above operations, and only requires user input to obtain output, eliminating frequent clicking and cumbersome signing. It can be said that the implementation of AA has shifted the on-chain ecology from being seller-driven to buyer-driven.

Account Abstraction (AA) and ERC-4337

What specifically does Account Abstraction (AA) refer to? It abstracts the underlying technology and data structure to simplify the operational steps for users and developers. In simple terms, it enables the functionality of “implementing CA on top of EOA”.

ERC-4337 has become the foundational standard for AA. ERC-4337 introduces UserOperation, which is a special transaction that represents user intent and allows contract accounts to execute operations proactively. These UserOperations are managed by a role called Bundler, which simulates the execution of UserOperations and adds valid operations to a special transaction pool. Then, the EntryPoint contract verifies and executes these UserOperations to fulfill user intent.

Account Types

There are two main types of accounts in Ethereum: Externally Owned Account (EOA) and Contract Account (CA).

EOA accounts have an address length of 20 bytes, which is derived from the private key generated by the user during creation and the public key computed using elliptic curve encryption algorithm. The state of an EOA account includes the transaction count (Nonce) and asset balance (Balance). The addresses of contract accounts are also 20 bytes, but they are computed from the sender address and Nonce of the transaction that created them. The state of a contract account includes the contract count (Nonce), asset balance (Balance), code hash (CodeHash), and storage root hash (StorageRoot), where the latter is used for storing contract data in the Merkle Patricia Trie tree’s root node hash value.

Account types and state information are crucial for transactions and smart contract execution on Ethereum, and they differentiate EOAs and CAs.

Source: "Account Abstraction, Analysed ｜Qin Wang∗, Shiping Chen∗ ∗CSIRO Data61, Australia"

Transactions

Ethereum transactions include sender and recipient information, digital signatures, transaction count, fund transfer amount, optional data, gas limit, and transaction fee. These two different types of accounts result in two distinct communication transaction types.

During the signing process, transaction data is hashed and then digitally signed. Validators verify the validity of the signature by computing points on the elliptic curve, without needing access to the sender’s private key. They only require transaction information and the public key. Public key recovery is achieved through the v value in the signature, ensuring signature security and efficient verification.

Account Abstraction

The structure of Ethereum transactions and the signature verification process reveal an important fact: the account initiating a transaction must be an EOA account with a public-private key pair.

Contract accounts, lacking a public-private key pair, cannot initiate transactions actively. Instead, they automatically execute smart contract code within the account or send transaction information to other accounts upon receiving a transaction. They can even create new smart contracts. Therefore, currently, wallets created by mainstream wallet applications such as Metamask are all EOA accounts. However, EOA accounts have some drawbacks in usage: private key risk, limited signature algorithms, excessive signing authority, and transaction fee limits.

Contract accounts can store code and data, and execute predefined smart contract logic to solve the problems of EOA accounts mentioned above. However, contract accounts cannot initiate transactions actively.

Account abstraction is an improvement on the above two types of accounts, attempting to blur the boundary between them and become a general account with complex logic, allowing accounts to have the functions of both CA (contract account) and EOA accounts.

ERC-4337

ERC-4337 achieves the function of account abstraction without modifying the Ethereum consensus layer, becoming the solution ultimately adopted by Ethereum. It ultimately realizes the vision of off-chain matching and on-chain transactions.

Source: "Account Abstraction, Analysed | Qin Wang∗, Shiping Chen∗ ∗CSIRO Data61, Australia"

•UserOperation

ERC-4337 introduces a new concept called UserOperation to solve the problem of contract accounts not being able to initiate transactions actively, while avoiding changing the transaction types at the underlying protocol level of Ethereum.

UserOperation is similar to standard transactions, but it only represents the user’s intention, not direct transaction behavior. Standard transactions are sent to Ethereum’s mempool, then combined into a complete block by searchers and builders, and finally sent to the blockchain by proposers, usually selecting the block with the highest reward. In contrast, UserOperation is not a real transaction, so ERC-4337 introduces a new mempool and a role called Bundler to execute UserOperation in a decentralized manner. This innovation allows the user’s intention to be processed and executed without directly participating in the standard transaction process.

Source: ERC 4337: account abstraction without Ethereum protocol changes

•Bundler

When processing UserOperation, Bundler first performs basic validity checks and then simulates the execution of operations to confirm the validity of the signature. If the simulation execution is successful, 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 preferences, giving priority to operations with higher fees. Finally, Bundler sends the batch of valid 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 first validate UserOperation and then execute the operations. Validation includes checking the account, the validity of the signature, and fee payment. During the execution phase, the smart contract code in the target contract account is called using the data in UserOperation. Different smart contract wallet protocols may have different parsing and execution methods.

Source: ERC-4337: Account Abstraction Using Alt Mempool

•Data

According to SixdegreeLab’s semi-annual data report on ERC-4337:

• After the deployment of the ERC-4337 contract, over 687,000 AA wallets were created on the chain, and over 2 million UserOps were called. However, 88.24% of AA wallets were used less than 5 times, mostly for direct transfers or minting NFTs.
• Among the 15,000 Bundlers, Pimlico accounted for 43.48% with the largest market share, while Alchemy generated the highest revenue ever of about $20,000.
• However, 97.18% of Bundled transactions only contained 1 UserOp, which means that 90% of Bundlers cannot profit from packaging transactions.
• 117 LianGuaiymasters accumulated a total of 19 million UserOps and paid $465,000 in gas fees, with Pimlico accounting for 43.45%.
• ZeroDev dominates the Wallet Factory, deploying 62.63% of the accounts.
• The most common way to build AA wallets is LEGO, which involves different third-party components such as LianGuaiymaster, Wallet Factory, and Bundler.

It can be seen that there is still a lot of room for growth in the adoption of ERC-4337, and the construction of the infrastructure has just begun, making the future of AA full of possibilities. With the rise of Layer2 and social applications, the use of AA wallets will experience a wave of rapid growth.

The Development 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 elaborate on the basic functions of keyless and gasless smart contract wallets, but rather look for more possibilities in the components of AA:

Architecture

Native Account Abstraction

ERC-4337 is only an application-layer solution adopted by Ethereum to address the inability to modify the underlying consensus. Although it popularizes the concept of account abstraction on a large scale, it is ultimately an interaction using contract accounts as a pretense. Additional gas consumption during the verification process, the adoption of other competing ERCs, and the prohibition of dapps interacting with contract accounts are all factors that hinder the growth of ERC-4337.

Therefore, native account abstraction, especially Layer2 native account abstraction, becomes particularly important. Among the current Layer2s, only Starknet and ZKSync support native account abstraction. As shown in the following figure, in the native account abstraction scheme, there are no Bundlers and LianGuaiymasters. Starknet uses Sequencer to determine the transaction order, pay gas, and execute, while ZKSync uses Operator to determine the transaction order, pay gas, and then calls the bootloader to operate together.

DeBank Chain, which claims to be built based on OP Stack, also intends to integrate a similar account abstraction system at the chain level, but the specific architecture will only be known when it is launched on its mainnet.

Source: "Introduction to Native Account Abstraction in zkSync"

NFT Contract Wallet

An NFT contract wallet is an application-layer account abstraction scheme similar to ERC-4337. It allows EOA accounts to have the functionality of CA accounts through NFTs, instead of calling the EntryPoint contract via the Bundler. There are currently two mainstream implementation methods for NFT contract wallets: ERC-6551 and A3S Protocol.

ERC-6551 allows users to use NFTs in their EOA wallets that conform to the ERC-721 standard as controllers to manipulate one or more newly created smart contract wallets. This allows users to match existing NFTs to one or more smart contract accounts without modifying the ERC-721 code, using the “attached contract” approach. This approach combines existing NFTs with account abstraction, opening up new applications for NFTs while popularizing the concept of account abstraction.

Source: "EIP-6551"

The A3S Protocol uses the NFT’s own smart contract as the smart contract wallet, which means that the wallet assets are on the NFT’s smart contract account and follow the transfer of NFT ownership completely. It does not require attaching a separate contract account as a wallet for the NFT, as in the case of ERC-6551. This shorter path achieves NFT contract wallets, but it also means incompatibility with existing NFTs.

Source: "A3S Protocol Gitbook"

Both solutions use a salt value to achieve uniform addresses across different EVM-compatible public chains, solving the problem of chaotic contract account addresses on multiple chains. This is also what caused Wintermute to lose 20 million OP tokens when transferring to different multi-signature addresses on different chains.

Modularity and Multi-Chain Abstraction

The significance of modular account abstraction is to minimize the development and maintenance costs, similar to OP Stack, so that wallet developers can focus more on the product itself rather than building and maintaining the underlying infrastructure. Of course, the modular ecosystem established as a result is also the foundation of modular platforms, so modular account abstraction must achieve:

• Composability of different modules (EIP-6900 is attempting to establish standard implementations)

• Diversification of module functions (signature scheme/privacy/MEV resistance/deposits and withdrawals/intents, etc.)

• Security (uniform standards for modules to avoid storage conflicts)

• Multi-chain abstraction (Vitalik proposed using a unified single-chain key library contract to achieve multi-chain smart contract account collaboration)

As mentioned earlier, we use salt to achieve consistent addresses for multi-chain smart contract accounts. However, having consistent addresses is just the first step. What’s more important is to make users unaware of cross-chain operations, i.e., multi-chain abstraction. This is an important step in modularity and account abstraction.

Source: "Future of Smart Accounts: Modular, Specialised & Multichain"

Signature Verification

We have previously mentioned that any transaction on Ethereum can only be initiated and paid for with ETH by an Externally Owned Account (EOA). In addition, EOAs can only use the ECDSA signature scheme, making their use cumbersome and limited in functionality, with the risk of private key leakage. The day when quantum computers emerge will also be the day when Ethereum EOAs become vulnerable.

Signature Algorithms

At the signature level, there are already solutions that use smart contracts to achieve multi-signature and social recovery (such as Gnosis Safe and Argent), as well as solutions that use so-called signature abstraction to freely interact with contracts within a given range after a one-time authorization (such as the Lens Protocol). However, according to the saying “Not your keys, not your coins,” we can pay more attention to the signature algorithms themselves:

• Signature Aggregation

Implementing more efficient and simpler signatures using Schnorr or BLS, which can not only achieve multi-signature at the underlying level but also reduce gas consumption through aggregated signatures. Of course, they each have their own issues, such as requiring additional communication rounds, not suitable for multi-signature schemes with large values of m and n, and a significant amount of time for matching verification.

• Post-Quantum Secure Signatures

Using one-time signatures such as Lamport or W-OTS to prevent others from using quantum computers to crack publicly known parts of private keys and forge messages and signatures.

UserOperation

ERC7521 Intent Centric

When we compare account abstractions, especially ERC-4337, with the Intent Centric architecture, we can see that the Bundler and Solver can actually be the same person. In other words, the user’s interactive content “UserOperation” can be provided by the Bundler. The Bundler analyzes the user’s intended path and proposes a matching solution path, then uses the EntryPoint contract to confirm the legitimacy of the path to the user, avoiding malicious behavior by the Bundler, and finally executes the verified intended path.

The combination of account abstractions and intent will enable synchronous abstractions of accounts and interactions, achieving a user experience beyond Web2.

Source: "ERC-7521"

The entire transaction process can be implemented using ZK proof technology for privacy payments through processes such as witnesses/challenges and responses. This allows users to prove the validity of a transaction without revealing the sender’s real address, and batch multiple transactions into a single proof, thereby reducing computational costs and significantly improving scalability, achieving cost reduction and efficiency improvement. Additionally, some enterprise users who need to comply with regulations can also transparentize transactions to regulatory authorities separately, meeting regulatory compliance requirements without sacrificing confidentiality.

Source: "ZKLianGuaiyments: Achieving Privacy and Scalability"

Bundler

Bundler MEV and Bundler Competition

Bundler MEV and Bundler Competition are both the result of incomplete infrastructure. Bundler MEV comes from the bundler’s transaction packaging responsibility, similar to the searcher. Bundlers can profit by changing the submission order of UserOperations. On the other hand, Bundler Competition occurs when different Bundlers package the same UserOperation, similar to a Gas War for searchers. If the packaged UserOperation is not included in the chain by the bundler, although gas is spent, the transaction fails.

Both of them can learn from existing infrastructure, such as MEV-Boost, to establish communication channels between Bundlers and between Bundlers and Block Builders. Etherspot is developing a mempool p2p network for AA, and UserOperations waiting to be packaged will be transmitted in this p2p network. Once they are packaged and processed on the chain, they will be marked and removed from the list to avoid being packaged by multiple Bundlers.

Source: "Why Does the Bundler of ERC-4337 Need to Collaborate with Block Builders"

LianGuaiymaster

LianGuaiymaster Deposits and Withdrawals

LianGuaiymaster can pay Gas Fees for users and negotiate with users to use any token or fiat currency as a substitute. Therefore, it is a good solution for LianGuaiymaster to cooperate with payment service providers to provide deposit and withdrawal services for users.

The Visa team has deployed two experimental Visa LianGuaiymaster contracts on the Ethereum Goerli testnet, one to explore whether users can pay fees with tokens including USD stablecoins, and the other to directly sponsor transaction fees. Of course, integrating LianGuaiymaster with existing ERC-20 tokens requires using an external source or an on-chain oracle to determine token prices and check whether the LianGuaiymaster contract is approved to charge users with the specified tokens. In this mature solution, directly connecting Visa cards to pay Gas with fiat currency, or even converting in real-time with ERC-20 tokens, will greatly reduce the entry threshold for Web2 users.

The Evolution of Web3 Account Systems and the Future of Web3 Gateways

The network traffic gateways and corresponding account system evolution in the Web2 era reflect the rapid development of the second-generation Internet and changes in user needs.

Initially, users entered the Internet through portal websites, where they could freely choose from the online resources listed on the portal website. Then, the emergence of search engines allowed users to query keywords through search engines, which provided relevant results by analyzing URLs. The Web2 era witnessed the rise of social platforms, including both PC and mobile platforms. In addition to actively using search engines to access Web2, users could passively encounter Web2 through information on PC media platforms or independently access Web2 through PC/mobile self-media platforms. During this period, there were two transitions from passive to active access and one process of information decentralization.

The account system in Web2 also changed accordingly, from initially using phone numbers as accounts through SMS/MMS, to establishing multiple accounts and gaining rich additional features and independent personal network identities on platforms such as QQ/WeChat/blogs/weibo. These platforms introduced personal profiles and contact lists, expanding user identification from a single URL to more complex user IDs and social graphs.

With the development of network and hardware technology, there are two ways to develop their own ecosystems:

• “iOS+Apple LianGuaiy+Apple Store” and “WeChat Pay+Mini Program” have established their own account and payment systems, and opened up an area for external developers to access, thereby keeping users within their own ecosystem and strengthening it.
• “Taobao+Alipay” and “TikTok+TikTok Pay” have developed their own account and payment systems based on the traffic brought by popular applications, and further integrated other applications to establish a unified account and payment system.

Both of these methods are effective and have their own market. WeChat can meet most of users’ needs within the app, while Alipay can also be found in various major applications.

In summary, the traffic entrance of the Web2 era aims to give users more initiative and decentralization, while the account system has evolved from being single to being rich and diverse, and has achieved its own ecosystem development through these two methods.

Source: OP Research

Account System

The evolution of the account system in the Web3 era retains some shadows of Web2 and presents a unique development path.

The evolution of the account system in the Web3 era continues some characteristics of Web2, while presenting a unique development path. In Web3, there are various types of accounts, including plugin wallets such as Metamask, software wallets such as Math and Trust, “operating platforms” such as dAppOS and Gnosis Safe, as well as UniLianGuaiss embedded in dApps and OKX Web3 Wallet embedded in exchanges.

1. Plugin wallets like Metamask are like the initial SMS that can meet the most basic needs of users. Although they can be used everywhere, their functions are too single.
2. Software wallets like Math and Trust are like QQ and WeChat, adding various optimizations and functions to enhance the user experience, such as multi-account management/social sections/affiliated applications, etc.
3. “Operating platforms” like dAppOS and Gnosis Safe further upgrade the basic functions to build another advanced account system, similar to Apple and WeChat, which enriches the ecosystem by developing supporting “mini-programs” centered around themselves.
4. Embedded wallets like UniLianGuaiss and OKX Web3 Wallet are like Alipay and TikTok Pay, which take another route of account and payment system development, relying on the traffic of popular applications to develop their own users and establish ecosystems through alliances.

Traffic Entrance

We mentioned in the article “Web3 Traffic Entrance”:

“Based on the user’s process of entering Web3, we can define Web3 traffic entrances into two main categories:

1. Account system (deposit/withdrawal and fund management): centralized exchanges, independent deposit/withdrawal projects, deposit/withdrawal aggregators, cryptocurrency ATMs, cryptocurrency debit cards, and over-the-counter (OTC) trading; EOA, CA, MPC wallets, and Account Abstraction (AA).
2. Web3 dapps (tools, social, and entertainment): DEX, NFT marketplaces, domain names, DeSoc, copyright marketplaces, GameFi, X to Earn.”

Today, we still hold this belief, but according to the content in the second part, all these entry points can also become part of the AA wallet. However, they also divide the adoption path of the AA wallet into two categories in reverse, namely, the account and the application mentioned above. Users can either obtain an account first and then interact with the application, or interact with the application first and then use the account.

Mini Programs and Wallet as a Service

When we look at the adoption process of AA, we can find that the initial independent AA wallet product Avocado was released by Instadapp, followed by Metamask releasing Snaps mini-program components to support partial AA functions. Payment giant Visa also joined LianGuaiymaster to test the waters and integrate Visa Card payments. Soon after, social application Lens Protocol attempted to establish an AA wallet through ERC-6551, while Safe also supported ERC-4337 to consolidate its “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 see that there are two main patterns of AA adoption:

1. Self-owned wallet release or compatibility with AA to attract and retain users using wallet users and internal application mini-programs.
2. Applications/exchanges/payment service providers leverage their own traffic advantages to convert users into AA wallet users.

This also raises the question we need to discuss: since the on-chain ecosystem will shift from a seller’s market to a buyer’s market due to the emergence of AA, which pattern will users choose?

Source: "Binance Research: Account Abstractation Report"

Mini Programs

In terms of short-term adoption rates, the AA model based on developing mini-program ecosystems with their own wallets is more likely to be accepted by users. Essentially, it is a To C (business-to-consumer) solution. Because most of the users who try AA wallets are still Web3 users, the wallet itself is not unfamiliar to them and can be used directly without additional understanding. The rich features and smooth user experience can attract and retain them. Taking MetaMask’s Snaps as an example, it allows third-party developers to develop corresponding wallet mini-programs for interaction on non-EVM chains through API interfaces. It seems to be diverting traffic to other wallets, but in fact, it is educating users for its own ecosystem. Undoubtedly, the day when MetaMask is fully compatible with ERC-4337 will be the day it becomes the leader in AA wallets.

Let’s take dappOS as an example:

dappOS = dappOS Account (Unified EOA for Multiple Chains) + dappOS Network.

dappOS Account: Allows users to use a “unified account” based on account abstraction, rather than a regular externally owned account (EOA). This approach makes it possible for users to recover accounts, pre-batch process transactions, and automate execution, and the way of aggregating multi-chain wallets also facilitates users to manage assets on different chains in a unified manner.

dappOS Network: A decentralized network that helps users automatically execute wallet and cross-chain operations, completing the complex interactive process behind transactions.

dappOS attempts to abstract the concepts of accounts, public chains, and Gas Tokens, allowing users to have a similar experience to Web2 accounts. However, due to its relatively early stage, the number of cooperating dapps on the platform is limited. Nevertheless, this does not hinder the growth of user data. Because users have the motivation to enter from EOA, especially users who need multi-account and multi-chain interactions, the interactive experience after migration is greater than the migration cost. Most importantly, once users enter, this account system is unlikely to be abandoned, because users are being educated while using it. Firstly, users who initially use AA wallets cannot use EOA wallets. Secondly, wallets like dappOS can meet most of the users’ interactive needs, so users don’t need to migrate. Lastly, even if users want to migrate, the invisible abstraction of multiple chains will make the entire migration process cumbersome.

Therefore, mature wallet products can quickly acquire and retain Web3 AA users, such as Safe, Avocado, OKX Wallet, etc.

Waas

WaaS is an application route that is opposite to the AA wallets that follow the WeChat Mini Program route. Applications come first, and then wallets, which obviously is a B2B solution. Applications use WaaS to customize their wallets to match the product’s functions. Standardized WaaS modules are available for different applications to choose from. By leveraging the traffic of applications, wallets can expand their own ecosystems, build AA wallet platforms, and then shift their focus to issuing customized wallets for users on the consumer side, allowing users to freely match the wallet functions they need.

Take Stepn as an example. As a popular application, Stepn has tens of millions of users globally, and each user has created a wallet through Stepn. If Stepn embeds an AA wallet and continues to develop its ecosystem, such as the subsequent MOOAR NFT trading market, mahjong games, and Gashero, then this AA wallet alone can bring millions of incremental users to the entire crypto market. Moreover, these users are highly sticky users of this AA wallet because the migration cost for them is extremely high.

Friend Tech, which has recently gained popularity, is also similar. Every Twitter user can be a potential user of its AA wallet, and fiat currency deposits and gas fee payment can help users overcome the interaction barriers of Web3 and quickly integrate into Web3.

In the landing products, we can pay attention to WaaS LianGuaiy and UniLianGuaiss, which represent the characteristics of WaaS-oriented wallets:

• WaaS LianGuaiy is a smart contract account deployment platform designed for organizations that seek instant blockchain payments while prioritizing privacy, using the Safe{Core} protocol suite and the Safe{Core} Account Abstraction SDK. It provides a user-friendly no-code interface to customize smart contract account functions, such as social login, fiat currency on-ramps and off-ramps, and gas-less transactions for recipients. By leveraging zero-knowledge proofs (ZKPs) facilitated by ZKBob, WaaS LianGuaiy ensures that sensitive financial data remains secure and confidential. The platform is supported by Polygon ZKEVM, ensuring scalability and efficiency, while the self-hosted IPFS node with Helia protects sensitive metadata.

•UniLianGuaiss is essentially an SDK provided for third-party dApps, allowing them to bypass the traditional account private key and a series of signatures and Gas limitations, or to manage private key generation and email binding addresses in a centralized manner. It enables dApps to directly use UniLianGuaiss’s DKIM verification to achieve unmanaged accounts controlled by email, while simplifying on-chain interactions through Relayers. This greatly enhances user interaction experience by eliminating the need for Gas, signature abstraction, social replies, and more. As a scenario-driven application, UniLianGuaiss chooses to provide customized services for different applications in a federated social network manner, while establishing an interconnected account system. Based on the interoperability of this federated social network, social relationships are recorded on the blockchain while ensuring data ownership and privacy protection. This creates a use case where individuals can prove ownership of data and assets through DID, attracting more applications to use UniLianGuaiss’s SDK in Web3. Users of these applications naturally become users of UniLianGuaiss and continue to interact with it in Web3, resulting in high user stickiness.

From this, we can also see that in terms of growth space and acquiring Web2 users, the WaaS route AA wallet has more advantages. However, this puts a lot of pressure on the team’s product quality and business development capabilities. However, once network effects are formed, there will be growth momentum, making it a type that can exert its strength 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] “In-depth Analysis of ‘Account Abstraction’: 7-Year Evolution and Track Map”

https://www.chaincatcher.com/article/2085142

[3] “Interpreting the Binance Research Account Abstraction 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 does the Bundler of ERC-4337 need to cooperate with Block Builders”

https://learnblockchain.cn/article/6205

[8] “Complete Guide to Account Abstraction”

https://news.marsbit.co/20230302172702633640.html

[9] “How Infrastructure Supports Billions of Users Through Account Abstraction”

https://www.panewslab.com/zh/articledetails/24hz8399g6my.html

[10] “You Could Have Invented Account Abstraction: LianGuairt 1”

https://www.alchemy.com/blog/account-abstraction

[11] “Ethereum Account Abstraction Research Report: Breaking down 10 related EIP proposals and addressing the bottleneck issue of impacting tens of millions of daily active users.”

https://www.odaily.news/post/5183201

We will continue to update Blocking; if you have any questions or suggestions, please contact us!