The author of this article, Kiwi, a researcher at OKX Ventures, does not constitute any investment advice.
Since Vitalik Buterin proposed EIP-4337 in September 2021, the concept of account abstraction is gradually being introduced into mainstream Web3 wallets. OKX Ventures uses the origin of this concept as an entry point to systematically sort out the past, current status and future of account abstraction. future opportunities.
Main points of the article
• About basic information:
￮ Account abstraction (AA), which supports session key, can decouple transaction sources and signatures, while helping users avoid complex operations such as backing up private keys and gas fees, and lowering the threshold for users to participate in Web3;
￮ In order to simplify account types, give more freedom to behaviors on the chain, and place accounts at a higher security level, account abstraction is required.
￮ After experiencing EIP-86, EIP-1014, EIP-2938, and EIP 3074, EIP 4337 can basically be regarded as the final solution of Ethereum AA because there is no need to change the consensus layer.
• Two routes for multi-chain account abstraction: 4337 compatible method and native account abstraction.
￮ Compatible with 4337 scheme: Currently Arbitrum, Polygon, Optimism and BNB do not have native integrated account abstraction. However, most of them are supported through 4337 related products (such as Biconomy, Stackup, etc.), and the infrastructure construction is still in the conceptual stage;
￮ Native account abstraction solution: Starknet and zkSync support native account abstraction, which is different from the 4337 solution. Difference: Starknet does not have Bundler and Paymaster. The Sequencer determines the transaction sequence, pays gas and executes it. zkSync determines the transaction sequence, pays gas through the Operator, and then calls the bootloader to operate together;
• Development data: Ethereum, Arbitrum, Optimism and Polygon have deployed more than 520,000 AA accounts, of which more than 80% were just created in July-August, mostly through the launch of AA products on Polygon and Optimism chains. Substantial growth. Bundler and Paymasters are currently making fewer agreements, and each chain is currently monopolized by projects such as Pimlico and StackUp.
• Opportunities presented by AA:
￮ Paymaster is a smart contract deployed by dApp, which triggers Paymaster through Bundler to pay gas for the specified UserOperation. Paymaster is a standardized service and it is difficult to form an independent project alone. Only web2 traffic can be used as a functional integration to serve web3 business. Business opportunities for payers: payment traffic portals, automatic redemption, integration with DeFi game projects, and macroscopically similar innovations in the payment industry. Paymasters innovation direction is relatively single, but it is the most stable part of value capture and lowers the threshold for web2 users to enter web3. A large number of web2 organizations may deploy Paymaster services.
￮ Bundler is one of the components with the most opportunities. Its essence is similar to relayer. The profit direction mainly revolves around a series of opportunities extended by packaged transactions (such as earning gas price difference, MEV and privacy pools that are biased towards B-side needs), but transaction packaging Failure to do so will cause the bundler to lose money, so choosing a trade is difficult.
▪ It will be easier to build a Bundler network with a protocol that has its own node and Relayer services. For example, Rpc as a decentralized facility can help bundler decentralization;
▪ It is a better choice for Bundler to cooperate with searchers and sequencers. In the future, revenue may be fed back to users through various channels through mev share, which will eventually become more and more equitable;
▪ Bundler is currently a private pool and there is no public pool. Currently, only stackup is well-operated and profitable, and Biconomy is average;
▪ Bundler is a public good that is difficult to make a profit but is very necessary for the ecology. However, there is no mature public goods operation plan on the market, and most project parties currently prefer to privatize it for profit considerations;
▪ The technical improvement directions Bundler faces include: avoiding nonce collisions. The p2p network can optimize such problems through marking and deletion; and modifying the contract storage causing the bundler to be unable to obtain sufficient compensation. This part requires subsequent optimization through proposals.
￮ The combination of AA and MEV: AA, Sequencer and intent essentially extend the chain of operations on the chain. MEV requires a longer chain of bribery. AAs Bundler and intent solve may cooperate with roles such as Searcher in the MEV chain to form MEV share form. Since AA provides Bundler and entrypoint contracts, theoretically AA can also share the income of PEV (Prover Extractable Value);
￮NFT: The improvement of the user experience itself can attract more new users, and at the same time make market monitoring and transactions more automated. ERC 6551 and 4337 both have account capabilities at the user perception level and can integrate full-chain games, DID and middleware. Subsequent full-chain games require the composability of ERC-6551 to complete the game experience of multi-chain + tradable equipment accounts;
￮ Social and gaming: The optimization of identity infrastructure will greatly improve product ease of use, and the lowering of the operating threshold for full-chain games + account model optimization + multi-chain account system will bring about a multi-chain game worldview;
• AA and intent:
￮In essence, there is no necessary binding relationship between intent and AA. Intent is essentially innovation in the user experience layer, better and faster understanding and decomposition of user needs, turning them into one or more UserOperations; AA is back-end optimization, better execution of user instructions. Telegram bot is a typical Intent innovation, but the backend still uses the EOA wallet, which does not affect the user experience.
￮ Intent is the process of solving the optimal op route for a specific goal. In the past, Intent tended to be simple requirements, but in the future, it may form complex problems with multiple conditions, multiple steps, multiple execution environments, and even the introduction of AI agents.
￮ Intent opportunities: The operator can reduce the number of signatures and improve user experience. The application side can form new infrastructure, new languages and new solution forms based on intention narrative, which is one of the most potential use cases in the future.
▪ Intermediary intent pools or intent public chains: Intent-based applications involve not only new message formats for interacting with smart contracts, but also dissemination and counterparty discovery mechanisms in the form of alternative memory pools. It is difficult to design an intention discovery and matching mechanism that is both incentive-compatible and non-centralized.
▪ Solvers diversified implementation paths: Various Super Smart Contracts that are already relatively mature in the short term will be integrated first. In the long term, AI with a higher degree of freedom will be the most ideal form, but it is very difficult to implement; Solver will bring the first off-chain The new paradigm of pre-processing and then uploading to the chain is beneficial to some automated protocols (such as Uniswap X); currently the ZK co-processor Axiom can be used as a demo of privacy solve.
▪ New language to express intentions: Juvix and Essential already exist. It is important for such projects to be launched first and users need to build trust in them in advance;
￮ Wallet and entrance opportunities: The wallet can be used as the intention layer construction end, and its strategic position is greatly increased, and it can become the drainage infrastructure and entrance of various protocols. The Intent backend can integrate traditional EOA, MPC and smart contract wallets; both transaction and cross-chain applications will improve the experience with the diversification of entry points (such as automation, multiple solutions);
￮ZK application opportunities: Users Intents have a large number of encryption requirements. 4337s own mechanism can meet privacy payment. Deeper integration will be developed in the zkProof market.
￮ Risks and thresholds: Intent requires strong trust expectations, corresponding to high entry barriers, resulting in over-centralization and insufficient innovation.
• Key projects:
￮ There are two types of participants in the account abstraction market: one is a smart contract wallet with functions such as social login and recovery, gas abstraction, transaction batching, and integration and aggregation of third-party services (such as legal currency deposits and withdrawals and DeFi protocols). There are many start-up projects on the track, but the solutions are rudimentary; one category is the modular providers of Bundler and Paymaster, most of which are in their early stages except biconomy and stackup.
￮ Key projects: Biconomy, Stackup and Pimlico are relatively mature 4337 solutions currently on the market. Continuing to improve the SDK and modular solutions will help occupy the leading market and achieve high market coverage of technical solutions. Currently, Stackup has implemented two types Paymaster and Bundler models, full-process solutions + multiple component libraries will be the way for such leading projects to continue to expand their advantages in the future.
▪ Pimlico’s bundler market share (userop share of the entire chain bundle52% ) and profit (the first in profit on polygon, reaching 637 MATIC in July, and also positive profit on optimization);
▪ All Stackup chains have bundler businesses, with Arbitrum (5 ETH in August) and Ethereum (0.4 ETH in July) taking the lead in profitability. The bundler is in a state where it loses more but makes more;
￮Innovative projects: Privacy is a hard requirement. For example, ZK co-processor Axiom can be used as a demo of privacy solver; Nocturne is a composable privacy AA layer. Users can interact with the contract after depositing funds from EOA or contract, and use zkp to achieve privacy. Protect. AI is a hot topic in the market. For example, Echooo Wallet combines MPC and AI technologies to achieve multi-signature and AI risk monitoring. At the same time, innovations based on traditional projects are also highlights. For example, the Uniswap teams Universal Paymaster can match the flows of both wallet users and Paymaster operators. sex market.
• Other EIPs and Opportunities:
￮ For EIPs related to 4337, since the official direction of 4337 has been given, most proposals currently focus on optimizing AA deployment. For example, ERC 6551 is an auxiliary to 4337 derivatives; EIP 6662, ERC 6900, ERC 1271, ERC 6492, EIP 7204 and EIP 7197 are all optimizing the direction of AA; ERC 7377 is helpful for later account migration;
￮Other award-winning projects: Ethereum funded a total of 4 account abstraction-related projects in the first and second quarters of 2023, two of which were produced by the 4337 official team (the AA official team and the 4337 browser wallet trampoline developed by it), and the other two major Innovative projects generated around the composability of 4337 with existing protocols/technologies (zkShield is a private multi-signature that uses ZKP and account abstraction to hide the account owner, Universal Paymaster launched by the Uniswap team is a single liquidity as ERC-20 Gas payment matching market)
• Future development: In the short term, we will focus on expanding the market and forming a joint promotion model with layer 2; in the mid-term, we will focus on the implementation of modular Bundler and Paymaster and the deployment of SDK, while optimizing the user experience in details (such as reducing gas costs, adding optional Selected EOA-to-ERC-4337 conversion, etc.); in the long term, consider forced conversion of EOA wallets.
1. Account abstract introduction
• Definition and summary:
￮The essence of account abstraction is: decoupling transaction sources and signatures;
￮ Why we need account abstraction: 1) Simplify account types; 2) Separate accounts from signatures, giving more freedom to behaviors on the chain, while placing accounts at a higher security level;
￮ Evolution of account abstraction: The workload and complexity of direct distinction are large, and EIP 2938 and EIP 3074 require changes to the consensus layer. In the end, the EIP 4337 solution was chosen without changing the underlying layer.
• Principle of ERC 4337:
￮ Role: EIP 4337 standardizes smart contract wallets and related infrastructure into five contract interfaces: Bundler, Entry Point Contract, Paymaster, and Smart Contract Wallet Factory ) and Signature Aggregator. and a new transaction type (UserOperation).
￮Transaction steps: 4337 Without modifying the Ethereum consensus layer, introduce new operation logic useroperation and add Bundler to be responsible for packaging userop. After the original process, the EntryPoint and Wallet contracts are added to split the verification and execution processes to complete custom task execution. Finally, the payment logic of gas fees is extracted through Paymaster. The user initiates a userop - the userop is sent to the user userop memory pool - Bundler is responsible for packaging the selected UserOps into a transaction and submitting it to EntryPoint - EntryPoint verifies the user operation, and the smart contract wallet executes the user operation and incorporates it into the block.
• 4337 compared to other solutions:
￮The AA plan of EIP-3074: Two new op codes need to be introduced to enable EOA accounts to use the contract, which involves changes to the consensus layer, so it is abandoned;
1.1 Definition and scheme outline
• What is the account abstraction:
￮ Ethereum has two types of accounts: external accounts (EOA) and contract accounts (CA). As a traditional solution, EOA relies too much on key management and ECDSA signatures. The operation logic is rigid, and its mechanism strictly binds signature rights and accounts. Will affect the entry and subsequent development of new users;
￮ A solution is needed that allows users to use smart contract wallets containing arbitrary verification logic to solve such problems. This solution is called Account Abstract (AA), and the principle is to decouple transaction sources and signatures.
• Why we need account abstraction:1) Simplify account types; 2) Separate accounts from signatures, giving more freedom to on-chain actions and placing accounts at a higher security level;
• Evolution of account abstraction:The workload and complexity of directly distinguishing between EIP 2938 and EIP 3074 required modifications to the consensus layer. Finally, the EIP 4337 solution was chosen without changing the underlying layer.
￮ Direct differentiation: For example, adding new transaction types through EIP 86, EIP 101, and EIP 859;
￮ To improve the status of a certain type of account:
▪ EIP 2938, making contract accounts the “top-level” accounts that can pay fees and execute transactions;
▪ EIP 3074, introducing two new op codes to enable EOA accounts to use contracts;
￮ EIP 4337: Introducing new operation logic - user operation pool;
1.2 ERC 4337 basic knowledge principles
• Introduction: In September 2021, Vitalik Buterin proposed EIP-4337 with Ethereum researchers from OpenGSN and Nethermind. EIP-4337 adds a new UserOperation memory pool in the hope of completely replacing the current transaction memory pool to achieve account abstraction.
Role
• UserOperation: The transaction that the user needs to initiate will be packaged and sent to Bundler, and packaged into a Bundle together with other UserOperations;
• Bundler: The node responsible for selecting transactions from the transaction pool, bundling multiple UserOperations and creating EntryPoint.handleOps() transactions.
• EntryPoint: The smart contract that handles transaction validation and execution of the UserOperations bundle, which acts as a middleman between the Bundler and the smart contract wallet:
• Wallet contract: a smart contract that can create contract wallets for 4337 users;
• Aggregator: used to verify aggregate signatures;
• Paymaster: A smart contract that helps users pay gas fees.
Transaction steps
• Transaction signature: The user initiates a wallet user operation and uses any form of private key to sign the user operation (the instructions remain unchanged, but the content fields change, non-ECDSA signatures can be selected) to generate a signed user operation (UserOperations), The UserOp will be sent to the memory pool of pending user operations to wait for processing;
• Send transaction: Bundler packages the user operations in the user operation memory pool, then signs a separate transaction to wrap the users instructions, processes the UserOp into one transaction in batches and submits it to the entry point contract; after packaging multiple UserOperations After being together, Bundlers will first simulate the transaction, detect whether there will be a contract execution failure, and calculate whether the gas fee is sufficient. If the simulation passes, this batch of UserOperations will be submitted to the block node as a transaction;
• Handle user operations: The entry point contract verifies the existence of the wallet - requires the wallet to verify user operations - sends user operations to the smart contract wallet for execution, it acts as a middleman between Bundler and the smart contract wallet;
• Block chaining: The smart contract wallet executes user operations and incorporates them into the block.
1.3 Comparison between traditional wallet and MPC wallet
1.4 AA plan of EIP-3074
• EIP-3074: Two new op codes need to be introduced to enable EOA accounts to use contracts, which involve changes to the consensus layer, so they are abandoned;
• If EIP-4337 allows CAs account wallet to be used like EOA, then EIP-3074 allows EOA external wallets to have programmable functions of smart contract accounts. The core is to allow others to use my account to issue instructions through signatures.
• EIP-3074 adds two new OpCodes, namely AUTH and AUTHCALL. It tends to allow User (EOA) to perform various actions on its behalf through a contract (Invoker Contract, Invoker is not upgradeable), while allowing developers to Use a more flexible framework to design transaction objects and verification mechanisms (signature algorithms) so that any EOA can operate like a contract account (Contract Account) without deploying any contracts yourself.
• Advantages: 1) Higher degree of freedom, such as batch transactions, packaging transactions, fee payment, multi-signature, etc. can be realized; 2) Multiple fee payments can be made, and external accounts can also pay Invoker through their favorite tokens handling fee;
• Disadvantages: 1) EIP-3074 involves changes to the huge consensus layer. Once a problem occurs, a hard fork is required to solve the problem; 2) Since EIP-3074 allows EOA externally owned accounts to own smart contract accounts Features, the signature mechanism still uses a fixed ECDSA signature, and cannot use any signature method like EIP-4337;
• EIP-5003: is an extension proposal to EIP-3074 (AUTH and AUTHCALL) that introduces the new AUTHUSURP opcode. If EOA address A has authorized another address B to act on its behalf using the EIP-3074 mechanism, then AUTHUSURP allows B to set As code. That is to upgrade existing EOAs to contracts and allow them to migrate from ECDSA to more efficient or quantum-resistant signature schemes.
2. Multi-chain account abstraction solution
Summarize
• Two routes: 4337 compatible method and native account abstraction.
• Compatible with 4337 scheme:
￮ Currently Arbitrum, Polygon, Optimism and BNB do not have native integrated account abstractions. However, most of them are supported through 4337 related products (such as Biconomy, Stackup, etc.), and the infrastructure construction is still in the conceptual stage;
￮ Arbitrum passed the endpoint support proposal for AA in July this year;
￮ Polygon zkEVM in whichOfficial documentationIt is stated that multi-token gas payment will be supported in the future;
￮ Optimism and BNB provide some account abstraction infrastructure, such asAlchemy、Biconomy、PimlicoandStackupwait.
• Native account abstraction solution: Starknet and zkSync two chains support native account abstraction, which is different from the 4337 solution
Compatible with 4337 scheme
• Arbitrum：
￮ Arbitrum has passed the resolution regarding support for account abstraction endpoints on July 17, 2023.AIP-2 proposalCurrently, Offchain Labs has officially activated support for account abstraction endpoints on Arbitrum One and Arbitrum Nova;
￮ The proposal states that Ethereum researchers propose a new RPC endpoint, eth_sendRawTransactionConditional, to adapt the L2 sequencer to the specific needs of ERC-4337 bundlers.
• Polygon：
￮ Polygon is compatible with 4337 and has released solutions related to meta transactions, such asBiconomy(Multi-chain relay protocol),Gas Station Network (GSN)(Decentralized public goods protocol can help abstract the process of users paying Gas),Infura(node provider) andGelato(Repeater SDK, multi-token payment available)
￮Polygon in itOfficial documentationIt is stated in that Polygon zkEVM supports account abstraction through ERC 4337 and will allow users to pay fees with any token, with more details to be released.
• Optimism: Currently the OP mainnet provides some account abstraction infrastructure, such asAlchemy、Biconomy、CyberConnect、PimlicoandStackupFor other projects, architectural details have not yet been released;
• BNB: On the BNB chain in 2023Technology roadmap in, the official stated that an account abstraction infrastructure will be established. Currently, 4377 is compatible on BNB, and more details will be released.
Native account abstraction solution
• Starknet natively supports account abstraction, that is, all accounts are smart accounts.
￮ PlanTarget: Signature abstraction (different account contracts use different signature verification schemes) and payment abstraction (different transaction payment modes and token forms)
￮ Process: The transaction is verified by nouce before being put into the pool, and then sent to the address of the account smart contract for verification, and then added to the block. These two phases are encoded in two separate functions validate and execute in the account contract.
▪ The Sequencer first requires the account contract to verify the transaction; in order to prevent DoS attacks, the Sequencer accepting the transaction must perform local simulation based on the known state before adding the transaction to the mempool and broadcasting it to other Sequencers.
▪ Upon successful completion of the simulation, the transaction is executed, entered into the pool and propagated in the network.
￮Differences between Starknet and Ethereum solutions:
▪ In Starknets native account abstraction, all accounts are smart accounts and must contain validate and execution functions. Users can implement arbitrary logic in these two functions to expand account functions.
▪ StarkNet supports a variety of elliptic curves, and signature verification is highly programmable; validate ensures that only the account owner can initiate a transaction by verifying the signature, and also ensures that the transaction executor can obtain sufficient gas fees. Users can implement different signature verifications in the validate function algorithm;
▪ Eliminate the additional complexity brought by Bundler: Starknet simplifies the process by specifying Sequencer to fulfill the role of Bundler;
▪ Starknet does not have a transaction fee abstraction protocol similar to Paymaster;
▪ Starknet does not distinguish between regular transactions and UserOperations: because all Starknet transactions are triggered by contract accounts. In Ethereum, Bundlers execute UserOperation transactions, while in Starknet, Sequencers execute all transactions;
▪ There are different ways to deploy contract accounts:
• Starknet deploys a contract account before calling it. Starknet requires an account with a token balance to create a new contract account by calling a special deploy_account function. This deployed account contract can pay gas;
• EIP 4337 does not require advance deployment. Bundler deploys contract accounts by executing UserOperation transactions whose initCode parameters are not empty. The deployment process does not require an account with a token balance, and the gas fee can be paid by Paymaster;
• zkSync: zkSync Era belongs to the native account abstraction solution, but is also EVM-Compatible.
￮Project goals: signature abstraction (different account contracts use different signature verification schemes) and payment abstraction (different transaction payment modes and token forms)
￮ Process: The user sends the signed Transaction locally to the Operator, and the Operator sends the Transaction to the bootloader for verification. After completing the verification and obtaining the handling fee, the booteloader will call executeTransaction on the Account Contract to execute the transaction.
￮ Differences between zkSync solution and 4337:
▪ zkSync does not distinguish between EOA and contract accounts;
▪ zkSync allows the validateTransaction function to call deployed external contracts: because deployed contracts are immutable in zkSync; Ethereum prohibits verification functions from calling external contracts to prevent state changes from causing transaction verification to pass. And the transaction execution failed;
▪ zkSync allows validateTransaction and Paymaster calls to issue external storage of this transaction contract account: such as the contract accounts token balance on the external contract, which is prohibited by Ethereum.
Comparison of zkSync, Starknet and 4337 solutions
• resemblance:
￮ The AA mechanism processes of zkSync, Starknet and 4337 are all similar, which are Verification Phase → Fee mechanism (paid by Account Contract or Paymaster) → Execution Phase; the smart contract wallet interface is divided into validateTransaction and executeTransaction;
￮ Facing DoS threats: zkSyncs contract logic only allows access to its own slots, and its contract logic cannot use Global variables; Starknets Sequencer requires that transactions must be simulated locally before adding them to the mempool and broadcasting; 4337s UserOperation Gas limits are added to the validateUserOp step, and Paymaster needs to stake tokens.
• Differences:
￮ Native AA: zkSync and StarkNet are both native account abstractions, and their architecture is different from 4337;
￮ On-chain Gas consumption: zkSync and StarkNet are both layer 2, and Rollup fees need to be considered;
￮ The roles of executing AA are different: in zkSync architecture, Operator and bootloader (System Contract) cooperate to complete User operation; in StarkNet, User operation is handled by Sequencer, and there is no Bundler and Paymaster mechanism; in 4337, Bundler and EntryPoint cooperate to execute User operation;
￮ Whether a transaction can be sent before the Account Contract is deployed: In both StarkNet and zkSync, there is no initCode field like the 4337 EntryPoint that allows it to deploy the Account Contract for the user, so it is not possible to send the transaction before the account is deployed;
￮ Calling external contracts: zkSync allows the validateTransaction function to call deployed external contracts; while neither 4337 nor Starknet can;
￮ Paymaster’s verification rules:
▪ Starknet has no Paymaster;
▪ The 4337 Paymaster interface defines two functions, validatePaymasterOp and postOp. The former defines the logic of Paymasters payment transaction, and the latter ensures that Paymaster can extract gas fee compensation after the transaction is executed. Paymaster needs to deposit Ethereum on the entry point contract (to pay for gas) and pledge Ethereum (to prevent malicious batch creation by robots);
▪ zkSync is similar to 4337. The interface defines two functions, validatePaymasterOp and postOp. The logic is the same as 4337, but this part of the function has not been implemented yet. And zkSyncs Paymaster will not start execution until it calls postTransaction when the gas is sufficient. This part is different from 4337. 4337 will not call postOp if validatePaymasterUserOp does not return context, and vice versa.
3. Development data
• Summarize:
• Ethereum, Arbitrum, Optimism and Polygon have deployed more than 520,000 ERC-4337 accounts, more than 80% of which were created just in July;
• Polygon and Optimism achieved substantial growth from July to August through the launch of AA products: Polygon saw a wave of traffic brought by the launch of the CyberConnect network, and Optimism saw growth brought by Beam wallet and ZeroDev;
• Arbitrum and Ethereum are less popular, with only a few hundred to a few thousand userops;
• Bundler and Paymasters are currently making fewer agreements, and each chain is currently monopolized by projects such as Pimlico and StackUp.
summarize data
• The popularity of 4337 began to soar in July 2023, and its narrative was first launched in Polygon and Optimism. Cyberconnect is the main driver of this AA craze. Paymaster and Bundler gas and transaction volume have increased significantly, and currently StackUp, Pimlico and Biconomy have formed a monopoly.
• The ERC-4337 EntryPoint contract was officially deployed on March 1, 2023. As of August 30, 2023, the total number of users on the account abstract chain was approximately 616,000, and the total number of User Ops reached 1.3 million. Compared to the first quarter of 2023, quarterly user operations increased by 11,837% and user growth exceeded 27,000% in the second quarter of 2023;
￮ Currently, 4337 accounts have been deployed on Ethereum, Arbitrum, Optimism and Polygon, of which more than 80% were created on Polygon and Optimism from July to August. Polygon is far ahead with a user operation rate of 43.9%, and among account wallet users, Polygon is far ahead with a 47% share. In addition, Stackup sponsored more than $140,000 in gas fees.
• Paymaster: There are currently 96 Paymasters in total, and the total gas cost is approximately $414,200. Compared with the first quarter of 2023, the second quarterPaymaster transaction volume increased by 5182%. The growth in total gas volume and transaction volume indicates that the demand for these intermediary services is growing significantly;
• Bundler: There are currently 1,300 Bundlers in total, with total revenue of approximately $33,800. There were approximately 1,000 Ethereum bundlers in August, of whichStackup accounts for 94% (940+), forming a monopoly on this component.
Polygon data
• There are currently 340,000 accounts and a total of 560,000 userops. Mainly due to a surge in usage in July this year, there were 440,000 userops.
• Mainly due to the launch of the CyberConnect social network, all accounts on the network are ERC-4337 wallets. Followed by Biconomy, which provides nearly 30,000 account deployments;
• Bundler and Paymasters in July and August are mainly provided by Pimlico.
• Pimlico is a cryptographic infrastructure designed to increase the adoption of account abstraction. Pimlico will focus on providing comprehensive infrastructure for Bundlers and Paymasters.
Optimism data
• There are currently 150,000 accounts and 400,000 userops. The ERC-4337 usage rate and the number of UserOps in August have greatly increased compared to July, mainly due to the launch of the Beam wallet (which allows users to pay with the coins used in transfers fees instead of the blockchain’s native token) and ZeroDev (an SDK built on top of ERC-4337 for building Web3 applications powered by the account abstraction).
• Bundler and Paymasters are mainly provided by Pimlico, alchemy and StackUp;
• StackUps SDK can use ERC-4337 to build custom Web3 transaction processes and wallets.
Arbitrum data
• Currently there are 2,200 accounts and 18,000 userops. The growth in July and August mainly came from Zerodev and Biconomy, and the rest were mostly user tests.
• Bundler and Paymasters are basically built with StackUp.
Ethereum data
• There are currently only 339 accounts and 2100 userops. The account part is basically contributed by Zerodev. There are very few userops generated by projects such as Safe and Biconomy. Most of the remaining UserOps are generated by users minting and transferring stETH, cbETH and rETH. .
• Bundler and Paymasters are basically built with StackUp.
4. Opportunities brought by AA
Paymaster
• Paymaster is a smart contract deployed by dApp, which triggers Paymaster through Bundler to pay gas for the specified UserOperation; its service is relatively centralized (compared to the bundler service), and the contract is open source, but the backend is closed.
• Paymaster is a standardized service and is difficult to constitute an independent project. Only web2 traffic can be used as a functional integration to serve web3 business. Business opportunities for payers: payment traffic portals, automatic redemption, integration with DeFi game projects, and macroscopically similar innovations in the payment industry.
• Paymasters innovation direction is relatively single, but it is the most stable part of value capture and lowers the threshold for web2 users to enter web3. A large number of web2 organizations may deploy Paymaster services.
Application scenarios
• Fiat deposits: Provides gas abstractions that require off-chain transactions (such as fiat deposits and withdrawals). For example, users can choose to use a credit card to subscribe to the Paymaster service to pay gas fees.
￮ Biconomy and 0x Pass partner with Transak to provide fiat currency access;
￮ Argent Vault partners with Moonpay, Transak and Wyre to provide fiat currency channels and has a built-in DeFi protocol aggregator;
￮ Etherspot, UniPass and Braavos support fiat currency channels;
• Swap: To prevent gas fluctuations, Paymaster can be integrated with the swap function to pay at an agreed gas fee at a specific time;
• Bridging: For example, MetaMask has integrated cross-chain bridges in the wallet through cooperation with third-party providers. These cross-chain bridges can be further integrated with the payment contract (Paymaster) in the gas abstraction.
￮Biconomy provides cross-chain bridge and cross-chain communication services;
￮ Etherspot, UniPass and Braavos support swap and cross-chain bridge.
• Session: Session keys can be integrated in Paymaster, that is, users pre-approve transactions for an application based on a set of parameters, such as a given duration, a maximum Gas, the maximum transaction volume of a specific token, or a specific contract Specific functions, etc. Use examples are as follows
￮ Achieve user-friendliness in the full-chain game, that is, play the game without interruption, without requiring signature confirmation for every operation;
￮ Ability to set multiple DeFi positions before confirmation;
￮ Fill in multiple forms on the chain without confirming each time;
￮ Rearrange assets in wallet/inventory without having to confirm each change.
• Multi-form payment: Through various forms of integration, Gas can even be completely invisible on the user side.
￮ Developer pay: App developers can easily subsidize fees for their users, for example as a means of acquiring customers;
▪ UniPass uses its own Relayer node to pay gas, and plans to add a gas-free transaction for watching ads mode in the future and support the use of cross-chain bridges to pay gas.
￮ Sponsorship fee/advertising fee: Can be integrated with some advertisers to allow users to do tasks without gas, such as liking a video, forwarding a tweet, etc.;
￮ Centralized institution: For example, integrating with the OKX exchange and binding the OKX web3 account and the exchange account, the paymaster can help the on-chain address make gas payment by deducting the exchange account balance;
￮Multi-currency/method payment: paymaster provides gas abstraction associated with off-chain processes. Users can pay for gas using ERC-20 tokens or off-chain payment methods such as credit cards or other subscription services;
▪ Biconomy not only implements its own Paymaster that is compatible with EIP 4337, but also has a Relayer network that supports any ERC 20 token for gas payment.
￮Automated payments: Visa implements a delegated account solution on StarkNet to enable automated payments for self-hosted wallets;
￮ Customized payment logic: For example, Stackup users can also customize gas payment logic, and Stackup will charge users through the pay as you go model.
• Combination with Entry point: Paymaster needs to deposit Ethereum on the Entry point contract to pay for UserOperation gas, and additional Ethereum needs to be pledged on the Entry point contract to prevent malicious robots from creating Paymaster in batches. There are a series of integration opportunities with Defi protocols due to its staking behavior, such as loans and liquidity pools.
Bundler and upstream and downstream
• Bundler package transactions generate multiple profit opportunities:
￮ Earn gas price difference: Bundler charges the gas fee for multiple transactions and the gas price difference for submitted transactions. RPC and Relayer protocols can quickly build the Bundler network. Contract scanning tools and security audit protocols can protect the security of the mempool submitted by bundler; but bundler selects transactions Improper packaging will result in unsuccessful packaging, which will result in bundler losses:
￮ Bundler participates in MEV distribution: Bundlers mempool will allow a structure similar to MEV market participants, and may be combined with existing MEV market players in the long term to form a longer bribery chain for MEV shares. Bundler shares MEV and PEV income with Searcher, Bundler, Sequncer and even Prover.
￮ Privacy Pool: Submit transactions to the privacy mempool for packaging. Some institutions and whale users have needs, but they face regulatory pressure.
• Future challenges for Bundler:
￮ Bundler is a public good that is difficult to make a profit but is very necessary for ecology: there is currently no mature solution for public goods; if it is used as a commercial project, most project parties will prefer to privatize it for profit considerations. Will lead to centralization threats;
￮ Nonce collision: If a UserOperation is submitted by different Bundlers at the same time, only one transaction will be successful, and other Bundlers will lose Gas due to failure to upload to the chain. Before the large-scale adoption of AA, there is no good transition plan other than actively disabling suspicious accounts. After large-scale adoption, some p2p networks can optimize such problems by marking and deleting;
￮ Modifying the contract storage will cause the bundler to be unable to obtain adequate compensation: During the verification and on-chain process, if the contract storage is modified due to market changes, the bundler will not be able to obtain adequate compensation. This problem is too detailed and there is currently no good solution. It needs to be optimized through proposals.
Bundlers related opportunities
• Earn gas fee difference: Bundler charges the gas fee for multiple transactions and the gas price difference for submitted transactions. RPC and Relayer protocols can quickly build the Bundler network. Contract scanning tools and security audit protocols can protect the security of the mempool submitted by bundler; but bundler chooses Improper transactions lead to unsuccessful packaging, which will result in bundler losses:
￮ Derivatives of the Relayer service: The underlying logic of the bundler is similar to that of the relayer. This type of project has established cases, so it has a first-mover advantage. For example, while Chainlink provides price feeds, it can also build its own bundler p2p network; Layer Zero, as a multi-chain contract, may build a multi-chain UserOp flow pool in the future; The Graphs indexer also has the utility of indexing (searching) profitable UserOps; uniswap also A version of UserOp fillers for Defi business can be launched;
￮ Blockchain RPC service: Rpc is a decentralized facility that connects dapps to the blockchain and can help bundlers decentralize. For example, the RPC service provided by the public chain itself, centralized service providers such as Alchemy and Infura, decentralized service provider Pocket Network, etc.;
￮ Bundler security: Bundler can theoretically participate in any number of memory pools, but ERC only guarantees the security of the standardized memory pool, and the security of any other memory pool is evaluated individually by its participants. If it is added to the malicious memory pool, it will affect the security of the entire UserOp package, so the bundler project should add an anti-attack/security scanning mechanism. Projects such as CertiK and SlowMist can launch security audit services and also provide opportunities for contract address scanning tools such as Cyberscan;
• Bundler participates in MEV allocation: Bundlers mempool will form a structure similar to MEV market participants, and may combine with existing MEV market players in the long term to form a longer MEV share bribery chain. Bundler shares MEV, PEV (Prover Extractable Value) income with Searcher, Builder, Sequncer and even Prover.
￮ Bundler data service: Provides MEV or memory pool data analysis services, refer to Eigenphi;
￮Private order pool: The new dapp can build a protocol-specific block relay layer while establishing transaction services. All transactions generated by users using this protocol will enter an exclusive private pool, and searchers need to pay fees to obtain exclusive order flow for arbitrage. The protocol layer can feed back the fees paid by searchers to users (such as Gas-free services) to attract more users to enter protocol transactions.
￮ Transaction auction service: Such as Suaves auction mechanism: participants can express their interest and willingness to pay for a certain user intent through bidding; or Cowswaps aggregator mechanism: it provides users with MEV protection through batch auctions. When two traders each hold an asset that the other wants, orders can be settled directly between them without the need for an external market maker or liquidity provider.
￮ Form a Bundler consensus: If a consensus is formed, the possibility of extracting MEV from AA will be completely eliminated. However, the Gas and detailed mechanisms of 4337 have not yet been established, and the implementation complexity of UserOp is greater, so this solution is ideal;
￮ Integrate upstream: Referring to the solutions of Starkware and flashbot, Bundler cooperates with Searcher and sequencer to package a series of services on the chain and share transaction revenue;
￮ Bundler solver: UserOp brings different Gas profit expectations and on-chain execution complexity, and Bundlers need to formulate their own transaction Gas parameters and transaction plans, which will affect the priority of block builders to execute transactions. Under different market gas prices and gas volatility conditions, Bundlers may have different MEV packaging strategies. These verification and strategy calculations require the consumption of local hardware computing resources and blockchain node resources. So there may be solver solutions for Bundlers;
￮ Form a new anti-censorship mechanism: 4337 is not applicable to the crLists anti-censorship mechanism, because currently UserOperation mempool cannot be combined with crLists (a mechanism that forces validators to add transactions to mempools blocks). This mechanism is only for transactions and will be missed. User operations.
￮ RPC service: It can provide users with private RPC, and promises that transactions broadcast through this RPC will not be preempted, such as Flashbot Protect RPC and OpenMEV RPC;
￮ PEV: Provers try to make more profits on the data. They will use the data on Ethereum or other protocols, or even some Rollups, to make profits instead of for proof.
• Privacy pool: Submit transactions to the privacy mempool for packaging. Some institutions and whale users have needs, but they face regulatory pressure.
￮Anonymous privacy pool service: Portal Gate allows users to use different wallets to enter and exit the privacy pool, maintaining anonymity and compliance on the chain, but only if they need to pass KYC outside the chain;
￮ Dark pool trading: Renegade has developed a decentralized dark pool trading based on multi-party computation (MPC) and zero-knowledge proof.
Bundler Future Challenges
• The Bundler protocol is a permissionless and modular public good. The open source software itself does not have a clear profit model and cannot draw revenue directly from Bundler. Bundler operators have no incentive to make the Operation pool public, and the privacy mempool has centralization risks:
￮ The Bundler protocol itself is difficult to make money: The open source Bundler protocol is non-exclusive and non-competitive. Any RPC endpoint copies the open source code to run a Bundler. As a typical public good, Bundler cannot obtain corresponding economic incentives, which is very similar to the current situation of Flashbots. The Bundler protocol is still in its early stages and needs continuous optimization, because the verification and execution of UserOperation requires the participation of as many Bundlers as possible for better decentralization.
￮ Bundler centralization: Currently, only a few projects provide application program interface services for running bundled programs, which has also led to the centralization of 4337. In the future, Bundler may form a monopoly due to its first-mover advantage, which will also intensify the threat of centralization;
￮ Bundler does not make the Op pool public: There is currently no mechanism for returning revenue from the Bundler public pool. Bundler relies on transactions in its private pool to obtain service fees and has no incentive to make the transaction pool public; and the performance of the public pool cannot be guaranteed, and it will face DDoS attacks and MEV attacks. risk. From the technical architecture, economic benefits, distribution model and other aspects, the open Op pool is not ready.
• Nonce collision causes transaction failure:
￮ If a UserOperation is submitted by different Bundlers at the same time. Then only one transaction will succeed, that is, only one Bundler will receive the Gas fee from the EntryPoint, and all other Bundlers will lose Gas due to on-chain failure;
￮ Before AA is adopted on a large scale, the sender or IP address of the UserOperation can be actively disabled, but this will cause accidental injury to users and treat the symptoms rather than the root cause. A better transition plan is still needed;
￮ After the large-scale adoption of AA, one solution is to adopt a p2p network. For example, Etherspot, which developed the Skandha bundler client, is developing the mempool p2p network.
￮ UserOperations waiting to be bundled will be transmitted within this p2p network, and once bundled and processed on-chain, they will be marked and removed from the list.
• Modifying contract storage causes bundler to lose money:
￮ During the process of verification and execution on-chain, users may modify the storage of the contract or the storage of the associated contract, causing the bundler to be unable to obtain sufficient compensation.
￮ For example, if a UserOp sent by a user consumes 1 eth of gas, and the price of eth is 1000 u at this time, and there is 1000 u in the users account, Paymaster is going to deduct 1000 u as gas payment, and then the bundler will execute the on-chain process. During the process, 1 eth was paid on behalf of the user. However, just after the transaction was verified, in the gap between the completion of the chaining, eth suddenly surged to 2000 u. The bundler still paid an eth gas, but since the verification has been passed, the user only needs Just pay 1000u according to the previous logic, and the bundler will have a net loss of 1000u. The oracle contract is the related contract mentioned above, and the price change is the storage modification.
AA and NFT
• AA improves the user experience, attracts users to enter the NFT market, and makes market monitoring and transactions more automated;
• ERC-6551, NFT integrates full-chain games, DID and middleware: ERC-6551 is similar to the underlying logic of 4337, and NFT serves as a wallet to integrate and manage other NFTs. Full-chain games require the composable version of ERC-6551 to complete the gaming experience of multi-chain + tradable equipment accounts.
• Functions: Wallet recovery, support for Gas-free transactions, account transactions.
• Market monitoring and data analysis: implement tracking indicators, time coin minting, analyze floor prices, etc., and automatically trade when certain conditions are met;
• The integration of full-chain games and NFTs can be closer: multi-chain open worlds become possible, user accounts are no longer limited to one game or one chain, and game accounts can also be transferred, which may also create a game NFT account trading market;
• Integration with DID and middleware: ERC 721 tokens can serve as user accounts and are transferable. At the same time, NFT can also be integrated with the middleware architecture and customized.
￮ For example, Cyberconnects CyberID is an ERC-721 token, which represents a unique account Handle in the CyberConnect network. CyberID does not imply permanent ownership, but operates on a demand-based fee model, and if a user forgets to renew, their CyberID is auctioned;
￮ CyberGraph also provides developers with space to customize logic through a middleware architecture. For example, if a DApp wants to build a social network for the BAYC community, it can set that only BAYC holders can mint their specific content NFT.
• Introduction: ERC-6551 will provide a smart contract account for all ERC-721 Tokens. These accounts will not only enable ERC-721 Tokens to own various assets such as ERC-20, ERC-721, ERC-1155, but also enable ERC- 721 Token can interact with various applications.
• Realizes the transferability of DID: All users DID or related assets can be transferred to an NFT. At the same time, the transferability of assets and identities can be realized. It is a protocol that allows NFT to hold assets. That is, NFT is an ID of yours, and then you can own some assets on this ID;
• Utility: ERC 6551 is a protocol that has greatly contributed to the popularity of AA, and the underlying logic is similar.
￮ Similar to implementing an NFT-related authentication method in an AA account, if the Key that initiates the transfer request is an Ethereum address, and the address has a pre-registered NFT, then the authentication is passed and the account can be unlocked. The logic of wearing NFT game equipment can be changed to transfer the equipment NFT to the binding address of the character NFT.
AA and social and gaming
• The social track was once considered a ghost town due to the number of users and operational complexity. However, through the abstraction of 4337, it will bring a large number of new users, and the optimization of the identity infrastructure will greatly improve the product. Ease of use, lowering the threshold for full-chain game operations + account model optimization make it possible to buy and sell accounts that were once difficult (such as ERC 6551). Moreover, the multi-chain account system will help create a larger multi-chain world view, and social networking and full-chain gaming will be one of the future trends.
• Identity infrastructure:
￮ Social recovery: As the most basic function, it will be integrated into the accounts of each 4337 social protocol;
￮Identity registration: Allows you to register smart contract wallets by email or phone number, such as the V3 version launched by CyberConnect.
• Multi-chain account system: For example, CyberConnects identity account has multi-chain versatility, using account abstraction to eliminate the complexity of network switching and lower the user threshold;
• Optimize gaming experience:
￮ Batch operations: Session keys can be used to achieve batch transaction processing and entrusted signatures, etc., lowering the operating threshold and achieving a scenario where you can hang up and play games with just one signature;
￮ More game forms: Strategy games with more steps will not be troubled by multiple signatures, a larger multi-chain worldview will be possible, and the complexity and interest of full-chain games will be further improved.
5.The relationship between AA and Intent
Intent essence and classification
• In essence, intent has no necessary binding relationship with AA. Intent is essentially innovation in the user experience layer, better and faster understanding and decomposition of user needs, turning them into one or more UserOperations; AA is back-end optimization, better execution of user instructions.
• Intent is the process of finding the optimal op route for a specific goal. In the past, Intent tended to be simple requirements, but in the future, it may form complex problems with multiple conditions, multiple steps, multiple execution environments, and even the introduction of AI agents.
• Example 1: Telegram bot is a typical Intent innovation, but the backend still uses the EOA wallet, which does not affect the user experience.
• Example 2: I want to buy Ethereum for $1,000. The solver needs to calculate which chain, which dex, slippage block time and other parameters to set, and generate a corresponding UserOperation; the backend can be EOA, MPC or AA wallet.
• Example 3: There are already some projects that are the predecessors of the intention narrative, such as 1inchs DEX aggregator: users only need to specify the input amount and slippage tolerance, and then let the contract find the best operation; the searcher pairs the transaction in the Flashbots auction Sequential preference is also a form of searcher intent. Future intentions will take more forms.
• Classification of Intents:
￮Conditional Intent: perform an operation when one or more conditions are met; it can be understood as an if statement. When a certain condition is met, a certain behavior is implemented, such as stop-loss behavior in finance;
￮ Continuous Intent: expresses the need for repetitive operations; whenever a certain continuous cycle time period or scene is reached, a certain behavior is implemented, such as monthly fixed investment;
￮ Multi-step Intent: After one intention is resolved, one or more new intentions are opened; it can be regarded as a state machine. When each transaction transitions from the previous state to a new state, a certain behavior is implemented. The new state you transition to depends on the conditions defined by the previous state. For example, If you want to buy Ethereum, when the price is lower than xx, buy it and transfer it to a wallet. If the price is higher than xx, automatically look for arbitrage opportunities;
￮Intent graph: a path formed by a set of related intentions; the relationship between intentions can form a nested intent graph, such as a user expressing the intention to buy and sell a certain token under various conditions, such as the results of a governance proposal , mining of specific blocks, increases and decreases in market prices.
AA makes intent more efficient
• Intent opportunities: The operator can reduce the number of signatures and improve user experience. The application side can form new infrastructure, new languages and new solution forms based on intention narrative, which is one of the most potential use cases in the future. Opportunities mainly include the following aspects:
• 1) Intermediary intent pool or intent public chain: Intent-based applications involve not only new message formats for interacting with smart contracts, but also dissemination and counterparty discovery mechanisms in the form of alternative memory pools. 2) Diversified implementation paths of Solver: Various Super Smart Contracts that are already relatively mature in the short term will be integrated first. In the long term, AI with a higher degree of freedom will be the most ideal form, but it is very difficult to implement; Solver will bring the first chain The new paradigm of pre-processing and then uploading to the chain is beneficial to some automated protocols (such as Uniswap X); currently the ZK co-processor Axiom can be used as a demo of privacy solve. 3) New language to express intentions: Juvix and Essential already exist. It is important for such projects to be launched first and users need to build trust in them in advance. 4) Wallet unified entrance: As the purpose layer construction end, its strategic position has been greatly increased, and its integration with various protocols makes it possible to become the largest traffic entrance.
• Intermediary intent pools: Intents flow from users to permissioned/permissionless and public/private intent pools, converted into transactions by matchmakers, and ultimately into public mempools or directly on-chain via MEV Boost-style auctions. These intent pools can be private or public, with customizable permissions, and intent resolvers compete for the best order execution and value extraction for profit.
￮ Permissionless intent pool: It allows intents to be propagated among various nodes in the system, providing executors with permissionless access. But it may bring DoS threats and MEV problems.
￮ Permissioned intent pool: A trusted centralized intent pool is more resistant to DoS. A high-trust model can also alleviate MEV concerns and provide some incentives to ensure good execution. However, the strong trust assumption has certain contradictions with the spirit of blockchain;
￮Hybrid intent pooling: Permission propagation is possible, but permission is not required for execution (assuming the trust assumption holds), a common example of this scenario isOrder flow auction。
• Intent public chain: Building an independent intent layer will further concentrate the hidden dangers of MEV;
￮ Anoma and Flashbots SUAVE are building an intent propagation layer where users can broadcast signed intents to propagation nodes;
• Diversified implementation of Solver: Super Smart Contract, AI, privacy and new paradigm of off-chain pre-processing.
￮ Contract integration smart contract: It has been implemented in the short term. This solution is easier to integrate and is similar to the current smart contract wallet path; CoW Protocol builds a network for traders and solvers to achieve trustless and efficient point-to-point transactions; Zerion, Bprotocol and Instadpp are doing similar integration.
￮ A new paradigm that combines off-chain preprocessing with on-chain: After the off-chain preprocessing environment matures and stabilizes, automatic DeFi protocols similar to Uniswap X may become the DeFi transaction hub. Off-chain preprocessing is a set of Solver preprocessing mechanism, which can be regarded as an extension of the structured intention of the existing smart contract framework, and is the same idea as Rollup.
￮ Privacy needs:
▪ To prevent malicious attacks, users may wish to hide some intended information. Currently, the ZK coprocessor Axiom can be used as a use case for privacy solve, but this track still lacks mature solutions;
▪ It is technically difficult to keep computable information private on the chain: TEE, ZKP and other solutions are immature/insufficient in adaptability;
▪ The current ZK coprocessor Coprocessor can be considered a demo of ZK solve, migrating complex calculations from Ethereum to off-chain, while using ZK to verify the calculation results. Representative projects are Axiom and hyperoracle, which can currently verify historical block information or historical information in account storage.
• AI automated execution is divided into two ideas: AI integrated wallet entry, and AI directly coupled with UserOp.
￮AI integrated wallet entrance, common AI optimized financial management and AI personal assistant.
￮AI is directly coupled to UserOp. After AI solves the requirements and generates the optimal UserOp, AA is responsible for executing the UserOp.
￮ All of the above require high-level development of AI. The corresponding requirements behind it are: prompt semantic understanding capabilities, real-time computing capabilities, reasoning capabilities, on-chain information updates and multi-chain communication specifications.
￮ Competitors may be Siri, GoogleAssist, ChatGpt client, etc. (the assumption behind it is that Apple mobile phones will be the most important wallets in the future);
• New languages to express intentions: such as designing an intention expression language that allows for privacy.
￮ Juvix is an open source, evolving functional language for creating privacy-focused decentralized applications. It allows developers to write high-level programs that can be compiled to WASM, or passed throughVampIRCompiled as a circuit for use on EthereumTaigaperform privately;
￮ Essential is creating a domain-specific language (DSL) for expressing intents, an Ethereum standard for intent-oriented account abstractions, and a modular intent layer.
• The wallet may become a real front-end entrance: Intent is essentially an off-chain pre-processing black box. The wallet can be used as the intent layer construction end. Its strategic position is greatly increased. It can become the drainage infrastructure and entrance of the DeFi protocol, attracting various ecosystems. Users can also charge part of the handling fee to make profits;
Wallet and entry opportunities
• Intent backend can integrate traditional EOA and MPC wallets;
• The smart contract wallet and supporting SDK can integrate backwards with components such as Bundler and Paymaster, which is a red ocean, but as a wallet combined with intent, there are many opportunities for innovation. Both transaction and cross-chain applications will improve their experience with the diversification of entry points (such as automation, multiple solutions);
• Integrate traditional wallet: Telegram bot is a typical Intent innovation, but the backend still uses EOA wallet, which does not affect the user experience. Now it needs to hand over the private key to the bot, which has a certain risk of account theft. AA can be used in the future to achieve more intelligence Management; users put forward requirements, and the solver calculates which chain, which dex, slippage block time and other parameters, and generates a corresponding UserOperation. The backend can be EOA, MPC and other wallets.
• Smart contract wallets and supporting SDKs: They usually build their own components such as Bundler, Paymaster, and Wallet Factory. This track is a red ocean market. For example, social recovery or modularization are currently existing functions of most contract wallets, but in the future this will Tracks can be combined with intents and have a variety of innovation opportunities.
￮ Social recovery: There are a variety of roles to choose from.
▪ Web2 service provider: For example, wallet users’ social media accounts, usually implemented by implementing the OAuth (Open Authorization) standard. For example, Argent can perform recovery based on trusted contacts or another device;
▪ User devices: such as browser storage and mobile storage;
▪ Email: Authorization, for example, by clicking on an email link that sends a signature. For example, UniPass can use email for social recovery and can also use zero-knowledge proof to desensitize user information on the chain. Soul Wallet can verify the guardians email address on the chain for social recovery.
▪ Multi-signature: Users can set up multiple personally owned EOA or smart contract wallets as guardians. For example, BLS Wallet and Argent use multi-signature technology (multisig) to perform key recovery through multiple EOA addresses specified by the user.
▪ MPC: Users can split a private key into multiple shares, with each share controlled by a node in the MPC network without revealing the complete key. For example, Web3 Auths MPC service splits the user key into multiple shares for guardians such as social login, user equipment, and its MPC node network. The product logic is implemented completely off-chain, and no guardian will store the complete private key.
￮ Modularity: Argent, Candide, Soul Wallet, Gnosis Safe and zeroDev all have modular functions and can be added to the 4337 interface
