Coinbase: The Current State of Smart Account Wallets

Author: Ryan Yi, head of investment at Coinbase Ventures; Translation: Golden Finance xiaozou

This article is for Coinbase Ventures Part 2 of the series of articles "State of Wallets" published by investment leader Ryan Yi: Smart Accounts. Part 1 is Wallet Technologies, please refer to Jinse’s previous article "Overview of the Development Status of Wallet Technology" .

< /p>

"Smart account" (also called "smart wallet") - we define it as a smart contract wallet (SCW) with the function of "account abstraction" - has become a top concern among crypto developers. Account Abstraction (“AA”) was launched in the EVM ecosystem in the first quarter of 2023, and adoption rates are beginning to trend upward. This article will address Account Abstraction’s value proposition, adoption changes, and its impact on the broader ecosystem.

Key points of this article:

• AA defines standards for meta-transactions so that users can conduct transactions and have transactions executed by third parties.

• AA may bring 10x user experience through sponsored gas, packaged transactions and the adoption of Passkey.

• AA enables developers to try to acquire customer (new user) sponsorship.

• Ecosystem adoption is rising and attention is growing. The value proposition is still “nice to have” (but not required), but as technology/cost optimizations, new use cases emerge, and introductory education campaigns – AA may become a “must have” infrastructure for users.

1, Smart Account Overview

(1)AABasics strong>

What isAA? The "Account Abstraction" (or ERC-4337) will be released within the ETH/EVM ecosystem in Q1 2023. AA defines a standard so that users can transact on Ethereum without initiating ETH transactions themselves (and having them executed by a third party).

Application example: The user expresses the intention to purchase an NFT by creating a transaction request, but the actual gas and on-chain settlement are handled by a third party.

WhyAAis important? Today we have self-hosted wallets (like Coinbase wallets) and MPC/embedded wallets. To date, SCW (smart contract wallet) has interesting security features (multisig, spending limits) and non-security features (batch transactions), mainly targeting on-chain DAO treasury use cases, but consumer adoption is limited by gas costs. limited. With AA, smart contract wallets have a new value proposition because there is a path to gas-free transactions, which makes sense for many applications, and L2 alleviates the gas cost issue of SCW. These SCWs are also called "Smart Accounts". The community believes thatAAfeatures will help bring10X user experience due to the following features:

*Gas< strong>Sponsorship:Users do not need to pay gas fees to "load wallets" for the first few transactions.

*Passkey:Users can securely sign transactions using their Apple/Google devices. This will require improvements to the ETH protocol level (EIP-7212).

*One-click transaction: A transaction sometimes requires multiple times"Click”However, these actions can all be bundled together.

*Security:Users do not need to save a complete set of mnemonics, which can be stored in multiple Split between keys/hosts.

(2)AA< strong>Process

Dapp/wallet creates a UserOp, a data structure that can support any signer, describing transaction and gas logic. This UserOp can be sent to a set of off-chain nodes/networks/relayers. For example, "I want to redeem this NFT."

Bundler is a node that handles UserOps and its function is similar to an off-chain block builder. They are viewed on-chain as a wallet where transactions are made, as these transaction packages are sent to a global smart contract called the EntryPoint contract, which is responsible for coordinating execution and payments.

EntryPoint ensures that the wallet has sufficient funds to pay the gas fee, and/or verifies the Paymaster (if UserOps gas wants to be sponsored). It also supports paying unpaid gas to Bundler from the account. If all logic checks are correct, the transaction will be executed on the chain and verified + executed on the SCW contract. There are other optional add-ons such as signature aggregation.

ERC-4337 defines the above-mentioned UserOp structure and EntryPoint interface. In addition, before ERC, there were some non-standardized implementations, but they effectively promoted similar product experiences. Effectively, this is an off-chain account with a trusted relayer setup.

(3) How to adoptAA?

Dapps must enable this process in their applications and contracts. Typically, whoever the developer is, will start at the smart account level and then specify the Bundler and Paymaster. Some options support a hybrid combination of Bundler and Paymaster, and some provide a complete solution.

In fact, dapp developers may need the complete suite. The "AA" product is basically an "All-In-One" integrated developer product that spans the off-chain (node, signature) and on-chain (contract, gas, key) life cycles. The market strategy of “AA” providers is to offer the complete “Bundler+Paymaster+ SCW” as a single tool package. So if you're a dapp and you've locked into an existing developer product, they may be selling you their AA toolkit or their partners' toolkits.

From the perspective of AA providers, they may start from their "core competencies" and then expand to other services:

The economics will depend on the supplier's positioning - although generally speaking, it is the user who pays the gas cost of UserOps ( Gas fees are collected/broadcast to the Bundler), and the Paymaster can sponsor gas within the client's budget. Just examples of today's business models are as follows:

• Percentage charges: The user pays the gas fee in UserOp—Bundler handles the operation and collects the fee

• < strong>SaaSPackage:The company will charge the development team a total end-of-month "product fee" based on a percentage of each Bundler API call plus upfront gas sponsorship.

To date, most "gas sponsorship" programs have been implemented through custom off-chain relayers. While this is popular in the short term, it will lead to less flexibility in adoption as each developer will need to adapt for all use cases - and we hope to eventually move to an open source form.

2, smart account adoption

(1)What exactly is AA used for? How was it adopted?

• GasSponsorship:This model enables network participants other than end users to pay for gas. Smart account transactions may have slightly higher fees than self-managed wallet transactions, but can be subsidized by third parties. User transactions (such as login/bridge funds) can be paid for by interested stakeholders.

• One-click transaction:Users can use session keys for "one login" (as opposed to multiple signature permission), multiple calls for a single transaction through batch processing, and various signature schemes support different devices to "sign" transactions through arbitrary verification logic (as opposed to wallets that only support ECDSA signatures).

• Passkey:Use SCW, Passkey (on Apple or Google devices Above) can sign transactions for users. Users benefit from Apple's security model (e.g., biometrics, physical device-specific authentication).

(2)< What is the current status of strong>AAadoption?

• Account total Volume: 3.2 million, total UserOps: 12.7 million, Paymaster total gas fee: 1.7 million US dollars

The total number of accounts refers to the creation The number of AA-compatible SCWs - they can be created automatically in the wallet interface or indirectly through partner applications. Total UserOps is the number of transactions powered by AA. Paymaster total gas fee is the total gas fee paid by a third party.

• Large developers (such as Alchemy , ThirdWeb, Circle) and emerging startups have begun to enter the AA field.

(3) What’s blockingAADevelopment?

• Cost-benefit analysis:

Smart account value proposition: gas sponsorship and transaction packaging The current value proposition is " It’s better to have”. As time goes on, this will become more common, web3 consumer applications will become mainstream, and the "nice to have" proposition will transform into a "must have", because the "user experience" of consumers who want to meet these standards will The bar will be raised.

Cost relative to existing scale options: Common practice among consumers today is to use self-managed wallets or MPC wallets - creating a wallet is free and user submits and sign transactions, but users pay gas fees for each transaction. For SCW, interacting via AA (via Bundler) is a bit slower (2~5 seconds slower), and the cost of large-scale deployment is another limiting factor.

Anecdotal data shows that on L2 (such as Base), the cost per account is approximately US$0.15-0.45. So for a dapp with 1 million users, that might be $150,000-$450,000 (each account costs about $7-$10 on the ETH mainnet). These costs may decrease with the arrival of future EIPs (4844).

• PasskeyAdoption:

Passkey is becoming increasingly part of the crypto user experience The more popular it becomes, the more standardized it becomes - but at the ETH protocol layer, the cost of verification is still very high. EIP-7212 attempts to solve this problem.

• "Chicken and egg”Cold start:

If a dapp wants to offer sponsored transactions, they may choose an MPC wallet, create accounts for users, manage keys, and then optionally create a private relayer to cover gas costs. There are currently no large-scale AA products and services, but that may change once costs become more affordable. The current status quo is that dapps use MPC wallets to create accounts for users and manage keys, which is very troublesome for dapps. Assuming gas costs come down, we expect MPC wallet vendors to eventually add AA support to their development products.

• Developer< /strong>/Product education:

4337’s first steps The discussion is highly technical, and SCW/AA marketing needs to benefit from a product/user experience perspective. There are already some AA-backed wallets that can connect to any dapp, which aligns it with existing self-hosted and MPC wallets. We hope that over time, self-hosted wallets will add more support for SCW.

3Influence of smart account ecosystem

(1)AAadoption is picking up, but not yet Breakthrough success story. Product-market fit is taking shape.

Two of the biggest problems in attracting new users to a dapp is that users often do not have a preconfigured wallet or the ability to pay for initial transactions. Pre-configured wallets had their moment last year, with mobile in-app login via simple social login/verification (no “connect wallet” button), powered by the in-app MPC wallet. There is still an increasing demand for the ability to pay for initial transactions, but we believe it is time for AA to shine for several reasons.

• The biggest obstacle to SCW adoption is gas cost (on ETH L1). With L2, costs have been greatly reduced, SCW transaction costs are much lower, but large-scale transaction costs are still high.

• Developers are developing consumer applications for non-crypto-native users. Therefore, engaging users becomes even more important.

• Gas sponsorship is very important now because the recipient of transaction fees is the L2 team itself. For example, an L2 might be willing to sponsor gas fees for selected dapps because they want to bring more transaction fees to their underlying orderer.

• Technology trends like Passkey will benefit the adoption of smart accounts. Passkey (i.e. FaceID creates wallet + signs transaction) is an additional boost to the consumer user experience.

• We look forward to the exploration of smart accounts by self-custody wallets.

We expect that when costs drop (EIP-7212, EIP-4844) and the industry moves towards open source standards (relative to closed relayers Product market fit will finally be achieved when case studies of successful gas subsidy programs emerge and dapp developers have the willingness and budget to pay for user acquisition.

(2)AA< strong>Allow developers to try to acquire customer (new user) sponsorship.

With the advent of L2, the first step of the user experience has been solved - transaction/gas costs have been significantly improved. The next step is for developers to enable AA, as users now want seamless transactions.

The idea is that once the user logs into the app, they are using the app and start enabling the concept of lifetime value (LTV). As long as the LTV is greater than the CAC (customer acquisition cost), it is worthwhile for developers to explore AA-backed CAC (such as gas sponsorship). Any stakeholder who wants to sponsor on-chain transactions can do so (whether L2 or dapp).

Dapp POV: Thanks to the embedded MPC wallet, the barriers to acquiring users from 0 to 1 have been greatly improved. AA should help build the bridge to the “first on-chain transaction” and ultimately bring about an instant login experience (no gas cost for the first X transactions, no “per click” user experience, no wallet setup required). An early example is a concept like "Asset Guided Login" - a dapp will provide the user with a smart account and gas/dust sponsorship for the first 5 transactions, because the dapp knows it will break even on the investment by the 6th transaction response rate.

(3)AA< strong>It is a first-mover advantage game, and technical differences are not the only differences, but the differences should be viewed from aGTM/use case perspective.

Because the technical configurations are all open source, there is not much technical difference in smart accounts (Paymaster, Bundler, SCW). The difference is that we decide how to route the transaction. For example, since there can only be one Paymaster per transaction, it is up to the transaction coordinator to decide.

The goal of "AA" suppliers is similar to that of all development platforms, that is, to have relationships and be a bridge between users and dapps. The point is that as long as AA providers have some relationships, they can find creative ways to monetize (e.g., tiered SaaS for dapps or revenue based on transaction volume).

In addition to product positioning, the winning formula is to define the "CAC" story of how to build smart accounts. The selling point of a "smart account" might be to show the LTV/CAC story - "Users spend 1 cent per transaction, but your dapp will make $3 per transaction." For example, if a dapp is created with a smart account , new users can transact immediately (no keys, no gas), the costs associated with SCW (deployments, function calls, etc.) are higher, but this will be offset and exceeded by the combined lifetime value of new users.

(4)AA< strong>It may be helpful to connect“eachdappa wallet”< Popular narratives related to /strong>and“Web3Home Page” .

So far, self-hosted wallets have been developed and constructed in the direction of "web3 homepage", where users can use one wallet to access all dapps (Collect, own, send, receive, bridge, etc.).

Recent trends among web3 consumers point in the direction of “one wallet per dapp” powered by MPC wallets. The user will download a mobile app and the key is only provided and used within that dapp. If a user uses the same embedded wallet provider (in the background) across multiple dapps, that embedded wallet provider is able to link wallets "off-chain" based on common data identifiers and merge them into a single interface . For example, users who log in with the same email in multiple dapps can see the wallets in these dapps uniformly.

Assuming there is a safe, reliable, and simple way to "link" addresses together, a smart account architecture can be implemented by allowing cross-wallet key signing and The transaction coordination delegate helps unify the above two threads.

• Self-hosted wallets will be able to work with Other wallets controlled by users are "connected on the chain" and retain the "homepage" interface experience, while supporting users to manage multiple wallets.

• Embedded wallets support users "off-chain connections", but users can only control the wallet on a per-dapp basis. Users can export embedded wallet keys and leverage AA to connect these wallets to the chain. This helps transition embedded wallets from “off-chain connectivity” to “on-chain connectivity”, resulting in a user-controlled global embedded wallet.

That said, AA wallets may be best suited for single network use cases. For dapps that allow multiple networks, the hassle of having to deal with SCW deployed to multiple networks may not be worth it. Today, AA development and adoption is primarily focused on EVM, but other networks (like Solana) are also investing in AA adoption (like Squads Protocol).

(5) Smart accounts are still in their early stages, but maturing.

The pieces of the Smart Account infrastructure are in place, but market timing remains an important factor.

Standardization (ERC-4337) only began to be implemented at the beginning of this year, and L2 only began to gain attention in the second quarter of 2023.

Self-hosted wallets such as Coinbase Wallet and Trust Wallet have begun to offer smart account products.

The common practice for Dapps is still to use self-hosted or MPC wallets (which are good enough), and the separation between wallets, sponsored transactions and dapps makes the benefits It has to be isolated and not obvious. A large number of consumer applications on the web3 chain are needed, ultimately changing the consumer login process supported by smart accounts from a "nice to have" to a "must have". So far, while the concept of sponsorship has brought "freemium" behavior to consumers, it has yet to fully materialize.

Passkey still needs to mature and improve before being deployed to smart accounts.

(6)Standards promote by ensuring ecosystem consistencyAAIt plays a big role in adoption.

Many "gas-sponsored" projects have historically been implemented through the use of custom off-chain relayers. Without a standard, many dapps will follow this setup, which will lead to a narrower path to adoption as each developer will need to adjust their setup based on the use case. Since this setting is not universal, each contract needs to support relayer (relayer→contract→user), and since the contract caller is a relayer rather than a user, the transaction may be interrupted.

Now that the standards are set, ecosystem participants can agree on how to build together. The jury is still out on whether smart accounts will strictly follow the ERC-4337 specification, or if there will be modifiable plugins/specs (or even new EIPs), but the concept should follow some variation of the standard. Going forward, the main benefit is the standardized definition of meta-transactions. This will help drive the industry toward the benefits of smart accounts and create best practices for developers and infrastructure providers who deal with it (e.g., developers can choose between 10 different bundlers).