What is Account Abstraction (AA)

Differences between AA, EOA, and CA

The essence of account abstraction is a Contract Account. In Ethereum, there are two types of accounts:

• Contract Address
• Externally Owned Accounts

A simple example is that the Contract Address is the address where the contract is deployed. Any contract in Ethereum that can be called has a contract address, such as USDT’s contract address. An EOA account is the well-known ETH account, like the account shown in the Metamask wallet.

0xdac17f958d2ee523a2206206994597c13d831ec7 is the contract address for USDT tokens. Contract addresses cannot be directly created from outside; they are created and managed by EOAs. The EOA that created the USDT contract address is 0x36928500Bc1dCd7af6a2B4008875CC336b927D57。

Therefore, we understand that an AA account is a special type of Contract Account (CA) in Ethereum. AA accounts still need to be created by EOAs and are controlled by external EOAs because the only way to interact with the Ethereum chain is through EOAs. Consequently, AA serves as a standardized and modular implementation of CA wallets, which continues to evolve over time.

Development History of AA Accounts

We have just explained the relationship between AA and CA. Before the proposal of the ERC-4337 standard, there were already a significant number of CA wallets available. Below, we provide information on three popular CA wallets and how they operate:

Parity Wallet

During the early stages of Ethereum’s development, several contract wallets emerged. The most well-known one is the Parity wallet, developed by Gavin Wood’s team, the founders of PolkaDot. Parity is implemented in Rust and serves as an alternative to the Geth node, which is developed in Golang. Parity Wallet is a multi-signature contract wallet that allows multiple externally owned accounts (EOAs) to control and manage a contract account (CA). However, in 2017, a hacker exploited a bug in the Parity wallet and stole over 150,000 ETH. This incident caused a loss of trust in contract wallets.

As a result, AA wallets require extensive practice and standardization to prevent similar incidents from occurring.

Gnosis Wallet

The Gnosis multi-signature wallet is currently the mainstream Multi-sig wallet and is used by most institutions and developers. A significant number of teams store their development funds in Gnosis’s multi-signature wallet to prevent team members from acting maliciously. Notable teams using Gnosis Safe include Yearn, Aave, and Balancer. The security of Gnosis Safe is extremely high, but its usage is relatively expensive, which is a common problem with CA wallets.

UniPass

Unipass Wallet combines MPC technology and CA contract wallets, allowing users to use social login without self-custody of an EOA wallet. It should be noted that both the Parity wallet and Gnosis Safe still require users to self-custody their private keys. The general flow of Unipass is:

• Social login while creating a CA wallet on-chain
• Interaction with the chain
  Users initiate transactions
  MPC verifies the validity of user transactions
  An EOA wallet controlled by MPC initiates transactions on the user’s CA account
  The CA account executes the transaction and pays gas to UniPass’s paymaster

It is important to note that the original AA solution of Unipass does not fully adhere to the ERC-4337 standard. The wallet control is still delegated to an EOA that is controlled by Unipass’s MPC.

Implementation of AA ( ERC-4337)

The essence of AA is a standardized, modularized CA account. ERC-4337 mainly manifests the following innovations:

• bundler : Traditional CA accounts still require users to initiate transactions through an external EOA account, requiring users to store ETH in their EOA accounts for gas fees. In ERC-4337, users package their transactions as UserOperations and send them to the bundler, who initiates the transaction, thus eliminating the need for users to reserve gas upfront.
• BLS Aggregate Signatures: The bundler packages multiple UserOperations into a single transaction and generates a BLS aggregate signature, which is then validated on-chain through a single BLS signature verification.
• paymaster : Users can designate a paymaster to pay for the gas.

The diagram above roughly describes the standard transaction process under ERC-4337:

• User packages UserOp and sends it to the bundler
• Bundler verifies the validity of the UserOp and packages it into a transaction
• Bundler submits the transaction to the ETH mainnet
  EntryPoint : Contract entry point for bundler’s submitted transaction
  handleOps : Contract specifically used for executing user transactions
  paymaster : Contract used for paying user gas

We can summarize the main differences between AA and traditional CA as follows:

• Users don’t submit transactions directly but leave the packaging to the bundler
• Signature verification moves from the consensus layer to the contract layer, where the contract validates the signature
• Introduction of a modularized paymaster, allowing users to freely choose who pays for gas

How AA Differs From MPC

Before fully understanding AA, many people often confuse the concepts of AA and MPC because they both support features such as social recovery and browserless plugins. The essential differences between AA and MPC are as follows:

• AA is still decentralized and exists on the chain, while MPC is centralized and often hosted by one or more institutions.
• AA transactions are executed by the AA contract address, while MPC is performed by the institution-hosted EOA, making MPC still a managed EOA account.
• AA transaction execution involves interactions with multiple AA-related contracts on chain, while MPC directly interacts with the EOA. MPC does not incur additional gas fees.

Next, let’s introduce MPC and its unique features.

• MPC technology is more mature, and hot wallets of centralized exchanges have implemented MPC to prevent single-point failures, greatly improving the security of centralized exchanges.
• MPC consists of multiple nodes, with each node only possessing a shard of the private key. Transactions can only be signed when multiple MPC nodes reach consensus. As a result, the theft of a single node’s private key does not lead to the loss of funds.
• Currently, there are many open-source MPC solutions. For specific principles, you can refer to https://tor.us/, an open-source MPC node solution developed by Web3Auth.

MPC solutions are widely used in current social logins, and many projects have launched MPC wallets to provide a chainless wallet experience, eliminating the need for users to install plugin wallets or manage private keys. In the industry, these types of managed wallets are collectively referred to as Wallet-as-a-Service (WaaS). Mature projects include:

• Web3 Auth
• Particle Network
• Magic Link
• Coinbase Base

In the face of an increasing number of WaaS services, it is foreseeable that there will be more products offering WaaS in the future. However, centralized exchanges have absolute user volume and extensive business experience in this field, so it is possible that all centralized exchanges will provide related services in the future.

Pros of AA

Social Recovery

The main drawback of traditional Externally Owned Accounts (EOA) is that users are responsible for storing their own private keys. This self-custody presents the following issues:

• High cognitive cost. Most users can’t understand public and private keys.
• If users lose their private key, there’s no way to recover the account.

AA (Account Abstraction) is designed to allow users to set up social recovery accounts. They can use one or more external EOAs to regain control over their AA. The common flow for social recovery is as follows:

• The user loses access to the current EOA controlling the AA, or it gets compromised.
• Two additional EOAs are bound to the user’s AA: \
  Friend’s EOA \
  Institutionally Custodied EOA
• These two EOAs initiate an appeal, and after completing a 2/3 multisig proof, they switch the AA’s bound EOA to the user’s new EOA.

Through this appeal process, even if the user loses control of the EOA governing the AA, they can still switch to a new EOA. Unlike MPC (Multi-Party Computation) social login, this social recovery is entirely decentralized and does not have a single point of failure.

Gas Delegation

Gas delegation is core to the mass adoption of blockchain. For new users entering Web3, the biggest pain point is to pre-fund gas fees. By using AA’s Paymaster to delegate gas, new users can be subsidized, thus lowering the entry barrier to Web3 applications.

Frictionless Cross-Chain

Another core issue affecting the mass adoption of Web3 is cross-chain compatibility. Paymaster, through the integration of cross-chain protocols like Layer0/Warmhole, allows users to deposit in Chain A (e.g., Ethereum) and seamlessly use applications in another Chain B (e.g., Matic or BSC), thus chain borders disappear and helping new Dapps gain users from other chains.

Cons of Current AA

While we’ve discussed the advantages of AA, the ERC-4337 standard is still rapidly iterating to address its current disadvantages:

Separate Creation for Each Chain/Layer2

Unlike EOA, once an EOA is created, it can be used on any EVM compatible chain, as the same public-private key pair can be used to interact on different chains. However, due to the nature of AA being a Contract Account (CA), a new AA contract needs to be deployed separately on each chain or Layer2. The high deployment cost of AA contracts might discourage users from adopting AAs.

Additionally, if users deploy improperly, such as using different Factories to deploy AA contract accounts, they may end up with different AA addresses on different chains, which can cause significant confusion and difficulty in usage and understanding. While current AA Wallet Factories have achieved generating the same AA address across different chains, users still need to exercise caution in checking the protocols they are using to ensure that their AA addresses remain consistent across various chains, thereby preventing any future issues or confusion.

High Deployment Costs

As mentioned, AA accounts require users to deploy the AA contracts generated by Wallet Factory on different chains and Layer2 separately. Even with the current sidechains, EVM-compatible chains, and lower Layer2 gas fees, it is still a significant expense. With the current gas fees and ETH price at $1800, deploying an AA account on the ETH mainnet would cost roughly $20-$40, while on EVM-compatible chains or Layer2, it would range from $0.5 to $5. For most users, it is difficult to accept the deployment cost before they even use the Dapp. Assuming this cost is subsidized by a Bundler or Paymaster, the subsidy cost is still too high and requires a strong incentive.

Sigificant Higher Gas Cost Than EOAs

Depending on the implementation of AA and the number of transactions bundled in a single Bundler transaction (the more transactions, the lower the gas cost per UserOP), the gas consumption of the current standard ERC-4337 transactions may be several times higher than that of regular EOA accounts. This is because a transaction initiated by an AA account often requires calling 3 or more contracts and involves complex calculations such as on-chain BLS signature verification. The current ERC-4337 standard is also being optimized for this, with the following roadmap:

• Simplifying the number of contracts called in AA account transactions
• Introducing elliptic curve precompiled contracts in ETH to reduce gas consumption for on-chain signature verification

Gas Fee Estimation Under the ERC-4337 Standard

We just mentioned the relatively high cost of using the ERC-4337 standard. What are the specific costs? First, let’s introduce a concept, which is the calculation formula for gas fees:

fee = gas × price

So, what are the deployment and usage costs of ERC-4337? The StackUp team has provided accurate estimations in their blog.

https://www.stackup.sh/blog/how-much-more-expensive-is-erc-4337

Table 1. Gas for ERC-4337 transactions

The table above shows:

• The cost of creating an AA account is roughly 20 times the cost of an EOA transaction.
• Native token transfers in AA accounts cost around 4 times more than in EOA.
• For ERC20 transfers, AAs cost only 1.5 times more than EOAs.

Table 2. Gas fee estimates for ERC-4337 transactions

This table provides cost estimates for various operations on the ERC-4337 AA account using the current gas prices. We can observe the following:

• On ETH mainnet, the cost of creating an AA account is very high, approximately $20-30.
• Under Rollup, due to the data compression technology, the cost of creating an AA account is lower, similar to the cost of transfers.
• On other EVM-compatible chains, the cost of creating an AA account is relatively lower due to the lower gas fee base.

In summary, due to the high cost of creating ERC-4337 AA accounts on the mainnet, widespread adoption is likely to occur first on Layer2 and EVM-compatible chains.

Dapp Compatibility and Blockchain Browser Compatibility

Another obstacle to AA development is infrastructure compatibility with AA contracts. Most Dapps outside the native AA chain only support EOA accounts. Support for AA requires Dapps to use AA’s SDK for transactions and to modify query parameters for user information.

Furthermore, blockchain browsers such as Etherscan are primarily designed for EOAs. To improve the convenience of querying AA accounts, these browsers may require a series of UI and UX optimizations.

Native Account Abstraction（Native AA）

Pros and Cons of Native AA

Except for Ethereum, most of the new public blockchains have already implemented native AA accounts.

• Pros
  Consensus layer support

Native AAs are implemented at the chain’s consensus layer, meaning they don’t require community developers for deployment. These are usually internal or system contracts developed and maintained by the blockchain developers.

Lower deployment costs and extra gas fees

Internal contracts often have higher permissions and priorities, and their gas calculations are different from external contracts. Therefore, native AAs have lower deployment costs and usually don’t add significant gas overhead.

• Cons
  Lower flexibility

Upgrading native AAs requires the public chain developers to be responsible, often needing soft or hard forks. This makes them less flexible than modular ERC-4337, limiting the pace of iteration and new feature release.

• Learn from the experience of ERC-4337 and increase scalability

Chains with native AAs are actively studying ERC-4337’s extensibility and modularity, allowing more features to be built on top of native AAs.

Near

Near implements native AAs at the consensus layer with accounts stored directly in the blockchain. It supports multiple access keys and social recovery (email, phone number). The following image illustrates the differences between an ETH and a Near account.

Aptos / Sui

Because of the Resource Ownership model in Aptos and Sui, both Aptos and Sui have implemented native AA at the consensus layer. Taking Aptos as an example, an Aptos account is a set of resources on the blockchain, so when creating an Aptos account, it is necessary to prepay Aptos to complete the initialization of the account. Aptos/Sui accounts also support changing the authentication key, but the address of the account remains the same, among other AA features.

ZKsync

Unlike Near/Aptos/Sui/Starknet, ZKsync supports both EOA and AA at the consensus layer. Therefore, ZKsync can initiate transactions using both EOA and AA, allowing it to be used with popular wallets like Metamask and Argent. ZKSync’s AA design is based on ERC-4337, making it compatible with wallets and Dapps that support EIP-4337. Currently, the additional gas cost for AA transactions in ZKsync is approximately execution_gas + 20000, which is around 0.01USD at the time of writing. This is a small cost compared to non-native AA ERC-4337.

Starknet

Starknet natively supports AA and does not support EOA-initiated transactions. The AA accounts in Starknet are designed based on ERC-4337. Currently, the AA contracts in Starknet are provided by OpenZeppelin and developed using Cairo.

ICP

The native AA accounts in ICP are called Internet Identity (II for short). The implementation of II is different from ERC-4337. II utilizes WebAuthn, commonly used in Web2 frameworks, allowing users to control their accounts using the built-in security chips in their smartphones. Users can freely add and remove devices. In essence, II turns the user’s smartphone devices into hardware wallets.

Existing AA Infrastructure

Bundler

Bundler replaces the previous node Mempool in the AA ecosystem. UserOps are no longer sent to Validators but are sent to Bundlers for packaging and on-chain processing. The mainstream bundlers are as follows:

• Stackup Bundler :

Stackup’s bundler is implemented in Go lang and aims to integrate seamlessly with Go Ethereum (geth). It is the first production-standard bundler on this list that fully complies with ERC-4337. Stackup is actively maintained and has comprehensive documentation, making it the most popular bundler currently. Stackup provides bundler services, eliminating the need for teams to set up their own bundler service.

• Infinitism Bundler

Infinitism’s bundler is developed in TypeScript and was developed by the original author of ERC-4337. Infinitism also develops ERC-4337 contracts, making its bundler highly compatible with ERC-4337. However, further verification is needed for performance and stability since it is developed in TypeScript.

• Silius(AA-bundler) is being developed by Vid Kersic, a core member of the Ethereum protocol, using Rust. This will contribute to the integration of AA tools in the Rust ecosystem.
• Skandha

Skandha is a bundler based on TypeScript developed by Etherspot. Etherspot is active in bundler’s mempool implementation. Skandha passed all tests in April 2023.

• Voltaire

Voltaire is a bundler protocol developed by the Candide team to support their own Candide wallet. Voltaire is a python-based implementation of ERC-4337. Voltaire currently provides good support for Candide’s own open-source wallet.

• Rundler

Rundler is a Bundler protocol developed by Alchemy, the largest node service provider for Ethereum. Currently, Rundler is not open source, but due to Alchemy’s large user base, it may receive significant traffic support.

Pain Points of Bundler

Bundler is currently in a phase of rapid development and iteration.

• Communication between bundlers

The current pain point that bundler needs to address is the consistency and communication issues of bundler’s mempool. Assuming there are multiple bundler protocols in the market and there is a lack of communication between them, it can lead to a serious problem of DDoS attacks on bundler. If a user simultaneously sends transactions to multiple bundlers without communication between them, these bundlers will simultaneously package and send UserOps to the validator. However, only the UserOp from the first bundler will be executed, and the transactions from the remaining bundlers will be rejected due to the same nonce. In this case, if the user’s paymaster has insufficient balance, the bundlers will pay invalid gas for these UserOps. So currently, communication between bundlers is a problem that needs to be addressed in order to prevent UserOp spam attacks on bundlers.

• Decentralization of bundler

The current bundlers are highly centralized. If bundlers blacklist certain users, it would result in their transactions being unable to be executed. This goes against the decentralization and permissionless nature of blockchain.

Paymaster

Paymaster is an important part of AA, as it can subsidize users’ gas fees and significantly reduce the barrier to entry for Web3. Here are some popular implementations of paymaster:

• stackups paymaster
  Stackups’ paymaster is part of the Stackups AA ecosystem. Stackups has implemented a paymaster dashboard where DApps or other service providers can set up their own subsidizing accounts at https://app.stackup.sh/sign-in to sponsor users’ transactions.

• Biconomy Dashboard

Biconomy Dashboard allows organizations and developers to utilize AA components in their projects. Project owners can configure their projects to pay gas fees for users through paymasters and add gas sponsorship conditions. By registering your paymaster for any supported chain, DApps can greatly simplify the Web3 experience for users.

Wallets

• Ambire
  Ambire is a web wallet based on AA that is self-custodial and supports plugin wallets, hardware wallets, and social logins. Ambire also issues Wallet tokens for the governance of the Ambire wallet. Currently, Ambire supports mainstream EVM-compatible chains and Layer2.
• Argent
  Argent is currently the most popular wallet in the Layer2 ecosystem and already supports mainstream Layer2 projects such as Starknet and ZKsync.
• Avocado
  Avocado is a web wallet that allows users to pay all gas fees using USDC and provides a seamless user experience across different chains.
• Safe
  Safe is the aforementioned multisignature CA wallet developed by Gnosis. Due to its high security and usage costs, it is mostly used by institutions and teams for fund management.
• Sequence
  Sequence supports social logins and provides a plugin-free wallet experience.

The Significance of AA for Web3 Mass Adoption

AA achieves centralization, usability, and security simultaneously.

Traditional EOA accounts often struggle to achieve decentralization, usability, and security simultaneously.

• Self-custodial EOA wallets like Metamask satisfy decentralization but require users to manage their private keys, which poses a high barrier to entry for new users. Additionally, if the device is compromised, there is a risk of private key theft.
• MPC custodial EOA accounts eliminate the need for users to self-custody their private keys, but the MPC itself is still controlled by an institution. If the institution acts maliciously or gets hacked, it introduces a single point of failure, which goes against the decentralization logic of blockchain.
• AA wallets, on the other hand, can address these issues. During user onboarding, bundlers can create accounts for users and manage the EOA private keys of AA. As users become familiar with Web3 or when their on-chain assets reach a certain threshold, control of the AA EOA account can be decentralized through smart contracts, such as using hardware wallets.

Paymaster gas delegation transfers the cost burden for users

In the traditional EOA framework, users often need to acquire blockchain tokens like ETH through fiat currencies to use Web3 applications. This typically involves using centralized exchanges (CEX) to deposit fiat currency, exchanging it for the required token, and finally transferring it to a newly created EOA account. This process requires a significant understanding of Web3 and is cumbersome in many regions. By introducing paymasters in AA, the initial onboarding costs for users can be delegated to the project owners of DApps. The transfer of gas fees has significant implications for the mass adoption of Web3.

Enhanced Security

• Security audits for paymaster

Currently, ERC-4337 is in its early stages, and numerous tools are being developed based on it. On the paymaster side, the user’s UserOp can be audited to prevent rug from happening, such as excessive approvals or unauthorized fund transfers. The paymaster’s security audit can be conducted using well-established methods in the web2 financial sector to review problematic transactions and ensure the safety of user funds.

• Account isolation

Another innovation being developed is the security isolation of accounts, such as separating the fund account from the game account, etc. When users use familiar DeFi and transfer functions, the fund account with stricter security auditing is used. When users try GameFi or unfamiliar DeFi, the game account is used. In this way, without increasing the private keys that users need to manage, the security isolation design of accounts ensures the security of users’ funds at the underlying level.

Prospects and Opportunities for AA

Enhanced Security Experience with Mobile/Computer Native Secure Chips and Hardware Wallets

Currently, many devices such as smartphones and laptops have built-in secure chips, such as the Apple T2 Security Chip used in Mac and iPhone. Therefore, fundamentally, every device with a Tee chip is a reliable hardware wallet. However, these secure chips currently do not support common blockchain signature algorithms like ECDSA.

• The current security of EOA private keys
  Plugins/mobile wallets

The current security of EOA private keys in plugins/mobile wallets is directly stored in plaintext on the device. If the device is compromised, the user’s assets can be quickly lost. Therefore, browser extension wallets like Metamask have high usability but low security.

Hardware wallets

Hardware wallets ensure that private keys never leave the device and cannot be directly accessed by external parties. However, most users cannot carry their hardware wallets with them at all times, resulting in high security but low usability.

• Introducing AA, using a secure chip for device security

By using the AA wallet and the innovative on-chain verification method, transactions can be directly signed by the device’s secure chip, ensuring that the user’s private key never leaves the device. This provides greater security compared to traditional EOA accounts. Currently, the Internet Computer’s Internet Identity and a project called Porton Wallet in the ETHBogota Hackathon have implemented a solution that utilizes device secure chip signing and session key, allowing users to fully utilize the security of their devices such as smartphones or computers, equivalent to a hardware wallet.

Thanks to the highly modular design of ERC-4337, through its expansion and iteration, AA accounts will achieve significantly improved security.

Cross-chain + AA: Chainless Experience for Users

Currently, another obstacle to the mass adoption of Web3 is the fragmentation of blockchain ecosystems across different chains.

• Experience of using DApp across chains currently

As a simple example, let’s consider a user on Ethereum (ETH) who wants to experience an application on Binance Smart Chain (BSC). What should this user do? First, the user needs to exchange their ETH for the corresponding USDT/USDC and then use a cross-chain bridge to transfer these tokens from ETH to BSC. After that, the user needs to purchase some BNB from a centralized exchange (CEX) and transfer it to BSC. Only then can the user start experiencing various DeFi applications on BSC. This entire process is time-consuming, has poor security, and comes with a steep learning curve, especially for new users who might not be familiar with cross-chain bridges.

• Experience after introducing AA + cross-chain paymaster

Through current commonly used cross-chain protocols, such as Layer0 + AA, the process of using DApp on different chains can be greatly simplified. The paymaster can fully integrate cross-chain protocols to achieve “charge it once, pay everywhere”. For example, if a user recharges USDC on the pay master of ETH, as long as the user’s AA account on different chains is the same and is bound to the same pay master, the paymaster can handle the accounting on behalf of the user. The user does not need to manually transfer assets to any EVM-compatible chain/Layer2 with the same account address.

Ads Placement, Dapp Promotion Subsidizes Gas

The biggest advantage of introducing paymaster is that it programmatically establishes conditions for subsidizing Dapp users.

• Subsidies without AA and paymaster

In the past, there have been cases where Web3 ecosystem projects subsidized gas to attract customers. However, subsidizing EOA accounts without programmatically setting conditions often led to the misuse of subsidy funds by bots and fraudsters, such as directly transferring the subsidy funds, without attracting genuine customers.

• Subsidies with paymaster

Currently, paymaster dashboards generally include the functionality of subsidizing gas fees for Dapps. Project developers can easily set the conditions for subsidies in the dashboard, so that only transactions that meet specific conditions are eligible for the subsidy. By controlling the transaction conditions in subsidies through paymaster, Dapps can attract more genuine users while keeping the costs under control.

• Due to the modular design of ERC-4337, future paymasters can integrate more services, such as advertising service providers, opening up broader possibilities for the mass adoption of Web3 applications.

Explosive growth in Mobile DApps

Under EOA, due to the dominance of Metamask, current Dapps are mainly accessed through web interfaces, resulting in a higher market share for web plugin wallets. However, the mass adoption of web3 relies on the participation of mobile users, making the development and adaptation of AA more Mobile Native.

Fully On-Chain Games

With the rising popularity of Dark Forest, the trend of fully on-chain games is quietly emerging. However, the user experience of using EOA (Externally Owned Accounts) in games is very poor. Imagine having to use a wallet for authorization or signing transactions every time you perform any action in a game. This constant interruption prevents players from fully focusing on the game itself. To address this issue, Arcade Accounts, which are specialized versions of regular AA, have been developed specifically for fully on-chain games. These accounts authorize specific game operations, allowing players to participate in full on-chain games without the need for repetitive authorization and transaction signing. As a result, the gaming experience is greatly improved. The rise of fully on-chain games in the future is likely to drive the widespread adoption of AA accounts.

Intent-Based Transactions

Recently, the concept of intent-based transactions has gained popularity with the rise of Unibot, and Uniswap has also launched the Uniswap X project to promote the implementation of intent-based transactions. The following example can explain what intent-based transactions are:

• Alice wants to exchange 1 ETH for 1000 USDT. Alice sends this intent to a specific transaction pool. The intent defines that Alice will transfer 1 ETH and receive 1000 USDT. The intent also defines the validity period of the transaction, let’s say 1 hour.
• Other traders in the transaction pool continuously search for executable intents.

If someone is willing to execute the intent, the counterparty initiates another intent to transfer 1000 USDT to Alice and receive 1 ETH.

The transaction is successfully matched.

• Finally, a bundler packages multiple intents and submits them to the blockchain.

Intent-Based Transactions provides the following advantages:

• Deterministic execution price, which provides a significant advantage compared to the price uncertainty of swaps.
• Lower gas fees, as multiple intent transactions can be aggregated and submitted to the blockchain, reducing gas consumption for individual transactions.
• More diverse trading experiences, as intent-based transactions open up the possibility of off-chain trading matching, leading to the emergence of more diverse trading models, such as Unibot, which implements Orderbook and front-running functionalities.

Currently, CowSwap has implemented Intent-Based Transactions based on EOA. However, Intent-Based Transactions based on EOA still require users to authorize (ERC-20, Approve) before initiating the transaction. However, under the new account architecture of AA, users can send Approve and Intent together to the bundler. AA’s bundler can simultaneously access the Intents Poll, match intents, and provide a more convenient trading experience.

Disclaimer：

1. This article is reprinted from [chaincatcher]. All copyrights belong to the original author [Chairman: Bill Qian, Researcher: Bonan Yuan]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.