By Ryan Yi. Input from Nick Prince, Wilson Cusack, Justin Brower, Yuga Cohler, Eli Haims, Daryl Xu.
Disclosures and footnotes: Coinbase Ventures portfolio company backed projects are denoted with an asterisk (*) when first referenced in the article below.
"Smart Accounts" (or “Smart Wallets”) – which we define as smart contract wallets (SCW) with “Account Abstraction” features – have become a top-of-mind conversation among crypto developers. Account Abstraction (“AA”) launched in the EVM ecosystem in Q1-2023 and is beginning to see an uptick in adoption. This document explains the value proposition, adoption inflection, and implications for the broader ecosystem.
TL;DR
AA defines a standard for meta-transactions such that users can transact and have them executed by a 3rd-party.
AA may help usher in a 10x in user experience through sponsored gas + bundled transactions + Passkey adoption.
AA enables the ability for developers to experiment with sponsored onboarding for a net new user – customer acquisition cost (CAC).
Ecosystem adoption is picking up and mindshare is growing. Value proposition is still “nice to have” but with tech/cost improvements, new use-cases, and onboarding education – AA may become a table-stakes “must have” infrastructure offering for users.
Smart Account Summary
AA 101
What is AA? “Account Abstraction” (or ERC-4337) launched in Q1-2023 to the ETH / EVM ecosystem. AA defines a standard such that users can transact on Ethereum without initiating an ETH transaction themselves (and have it executed by a third-party).
Example in practice: a user signals an intent to purchase an NFT by creating a transaction request, but the actual gas + onchain settlement is handled by a 3rd-party.
Why is AA important? Today we have self-custodial wallets (like Coinbase Wallet) and MPC/embedded wallets (managed keys). To date, SCWs (smart contract wallets) have had interesting security features (multi-sig, spending limits) and non-security features (batch transactions) mostly targeted at onchain DAO treasury use-cases – but had limited consumer adoption due to gas cost. With AA, smart contract wallets have a new value proposition because there is a path for gasless transactions that is interesting to a lot of apps, and the gas-cost downside of SCW has been mitigated by L2s. These SCWs are also described as “Smart Accounts.” The community believes that AA features will help usher in a 10x in user experience for dapps because of the following attributes:
[1] Sponsored Gas: users do not need to incur gas cost to “load their wallet” for the first few transactions.
[2] Passkeys: users can utilize their Apple / Google device security to sign transactions. This will also require improvements on the ETH protocol level (EIP-7212).
[3] One-Click Transactions: one transaction sometimes takes multiple “clicks” – this can all be bundled.
[4] Security: users do not need to save one seed phrase, it can split across multiple keys / hosts.
AA Flow
[0] Dapp / Wallet creates a UserOp, a data structure that can have any signer and describes the transaction + gas logic. This UserOp can be sent to an offchain set of nodes / networks / relayers. E.g., “I want to swap for this NFT”.
[1] Bundlers are Nodes that handle the UserOps, and functions similarly to an offchain block builder. They look onchain as a wallet making a transaction because the bundles are sent to the global smart contract known as the EntryPoint contract, which orchestrates the execution and payment.
[2] EntryPoint ensures that a wallet has funds to pay gas cost, and/or it validates against the Paymaster if the UserOps’ gas wants to be sponsored. It also facilitates paying the Bundler the gas owed from the account. If all the logic checks out, the transaction is executed onchain with validation + execution on the SCW contract. There are other optional add-ons like signature aggregation.
The ERC-4337 defines the UserOp structure and the EntryPoint interfaces mentioned above. Alternatively, prior to the ERC, there were implementations that were non-standardized but effectively resulted in similar product experiences. Under-the-hood, it was an offchain account with a trusted relayer set-up.
How do you adopt AA?
A dapp has to enable the flow in their application and with their contracts. Generally, whoever owns the developer relationship begins at the Smart Account level, and then specifies the Bundler + Paymaster. Some options allow for mix/match on Bundler/Paymaster; some options offer the entire solution.
Practically, the dapp developer will likely want the full-suite. An “AA” product is basically a form of an “All-In-One” developer offering that spans across the lifecycle of offchain (nodes, signatures) and onchain (contracts, gas, keys). The go to market for an “AA” provider is to offer the full-suite of “Bundler + Paymaster + SCW” as a single tool-kit. As a result, if you are a dapp and you have lock-in with an existing developer product, chances are you will likely be upsold into their AA toolkit or their partner’s.
From the AA provider’s point of view, they will likely begin with their “core competency” and then branch to offer other services:
Coinbase offers various products in this area such as an Account Abstraction Kit, embedded Wallet-As-A-Service, and Smart Wallets.
Bundler/Paymaster: developer platforms that provide node services may lean into Bundlers first as it is a node-adjacent product. They can then support Paymasters and “Smart Wallet SDK” which offers the suite of Bundler/Paymaster/SCW.
SCW: Safe* (formerly Gnosis Safe) is the leading provider of multi-sig wallets. They now offer an “AA SDK” which allows integration with other providers on the Bundler + Paymaster side.
MPC Wallets: Companies like Privy may offer Smart Account Kits via partners.
The economics will depend on the positioning of the provider – though generally speaking the user is paying the gas cost of UserOps (which is collected / broadcasted to the Bundler) and the Paymaster can sponsor the gas which is pre-loaded with a budget by a client. Some examples of business models today include:
% Fee: user pays gas cost in the UserOp – Bundler handles the operation + charges a fee
Bundled SaaS: company will charge a month-end total “product fee” to the developer team based on % per Bundler API call + up-front gas sponsorship.
To date, most of the “sponsored gas” programs are being achieved by custom offchain relayers. While this is popular in the short-term, this leads to a less composable path to adoption because each developer would need to adjust per use-case – and we expect them to transition to an open-source variant.
Smart Account Adoption
What is AA actually useful for? How is AA being adopted?
Sponsored Gas: The model enables a network participant besides the end user to pay for a gas fee. The transaction of a Smart Account may be slightly more expensive than with a self-custodial wallet but it is able to be subsidized by a 3rd-party. User transactions like onboarding / bridging over their funds can be covered by the interested stakeholder and result in a user “getting” to the dapp.
One-Click Tx: A user can “sign-in once” via session keys (vs multiple signature approvals), make multiple calls with a single transaction via batching, onboard various signature schemes allowing different devices to “sign” transactions via arbitrary verification logic (vs wallets which only support ECDSA signatures)
Passkeys: With a SCW, a Passkey (on an Apple or Google device) can sign a transaction for a user. Users benefit from the Apple security model (e.g., biometric, physical device-specific authentication)
“What is the current state of AA adoption?”
Total Accounts: 3.2M, Total UserOps: 12.7M, Total Gas by Paymasters: $1.7M [Source]
Total Accounts are the number of AA-compatible SCWs created – they can be auto-created within the wallet interface or created indirectly through a partner app.
Total UserOps are the number of transactions powered by AA.
Total Gas by Paymasters are the total lifetime dollars of gas paid by 3rd-parties.
Mindshare: Large developer players (ex. Alchemy*, ThirdWeb*, Circle*) as well as new startups have emerged to tackle the AA segment.
What is holding AA back?
Cost-Benefit Analysis:
[1] Smart Account value proposition: The gas sponsor + transaction batching are currently “nice-to-haves.” Over time, as this becomes more normal and web3 consumer apps go more mainstream, this should transition to “must have” as a status quo because the bar for consumer “UX” will have been raised to match those standards.
[2] Costs relative to existing options at scale: The current norm for consumers is through a self-custodial wallet or an MPC wallet – where creating a wallet is free and tx are submitted + signed by the user, but users pay the gas per transaction. For SCWs, interacting thru AA (via a Bundler) is a bit slower (anecdotally 2~5 seconds slower) – and also the cost-to-deploy at scale is another limiting factor.
Anecdotal datapoints include anywhere between ~$0.15-0.45 per account on an L2 (ex. Base). Therefore, for a dapp with 1M users this can come out to ~$150K-450K (and $7~$10 per account on ETH mainnet). These costs may go down with future EIPs (4844).
Passkey Adoption: Passkeys are becoming more popular and becoming more normalized as part of crypto user UX – but the cost of validation is still expensive at the ETH protocol layer. EIP-7212 attempts to address this issue.
“Chicken and Egg” Cold Start: If a dapp wants to offer sponsored transactions, they will likely opt for an MPC wallet → create account for users → manage keys, and then optionally create a private relayer to cover gas cost. There is no mass AA offering (yet) but this may change once costs become more affordable. Today’s status quo is for a dapp to use an MPC wallet → create an account for users → and manage keys – which is cumbersome for dapps. We expect MPC wallet providers to eventually add support for AA in their developer offerings, assuming gas costs come down.
Developer / Product Education: The conversation around 4337 is highly technical and the marketing of SCW / AA needs to be product / UX-forward in terms of the benefits. There are already AA-powered wallets that can connect to any dapp – which aligns it into the existing crowd of self-custody and MPC wallets. We expect self-custody wallets to add more support for SCW over time.
Smart Account Ecosystem Implications
AA adoption is starting but there is no breakout success case yet. Stars are aligning for the product-market-fit to happen.
The two biggest issues for onboarding a new user onto a dapp are that users typically do not have [i] a pre-configured wallet or [ii] an ability to pay for initial transactions. A breakout moment for [i] happened last year with mobile in-app onboarding with simple social login / verification (no “Connect Wallet” button) powered by application embedded MPC wallets (ex. Privy for FriendTech). The demand for [ii] is still percolating but we believe now is the time for AA to shine for a couple of reasons.
The biggest barrier to SCW adoption was gas cost (on ETH L1). With L2s the cost has come down significantly + SCW transactions can happen a lot more cheaply – but is still expensive at scale.
Developers are building consumer apps for the non-crypto-native user. As a result, the focus on onboarding matters a lot more.
Sponsorship for gas makes sense now because the recipient of transaction fees are the L2 teams themselves. For example – an L2 may be willing to sponsor gas for select dapps because they want to drive transaction fees for their underlying sequencer.
Orthogonal tech trends like Passkeys will benefit the Smart Account adoption. Passkeys (i.e. FaceID to create a wallet + sign transactions) is an additional tailwind for consumer UX.
We expect self-custodial wallets to explore Smart Accounts.
We expect product-market fit will be achieved when costs come down (EIP-7212, EIP-4844), the industry aligns around open-source standards (vs closed relayer models), case-studies for successful gas subsidy programs emerge, and there is willingness and budget from dapp developers to target and spend to acquire users.
AA enables the ability for developers to experiment with sponsored onboarding for a net new user – customer acquisition cost (CAC).
The first step of UX has been solved with the advent of L2s – cost of transactions / gas has significantly improved. The next step is for developers to enable AA because users now want seamless transactions.
The idea is once a user is onboarded, they will use the app and initiate the concept of lifetime value (LTV). So long as the LTV > CAC, it is worth it for the developer to explore the CAC (ex. $ of sponsored gas) enabled by AA. Any stakeholders that want to sponsor an onchain transaction can opt to do that action (whether an L2 or dapp).
Dapp POV: the hurdles to onboard a user from zero-to-one have been massively improved via embedded MPC wallets. AA should help complete the “first onchain transaction” bridge and ultimately lead to an instant onboarding experience (no gas cost for first X transactions, no “click per action” UX, no wallet set-up). Early examples are concepts like “Asset Led Onboarding” – where a dapp will provide a user with a Smart Account + sponsored gas / dust for the first 5 transactions, knowing that the dapp will make a break-even ROI on the 6th transaction.
L2 POV: L2 wants to drive users / activity / sequencer fees and is willing to spend “$X” in CAC for sponsored gas powered by AA. Examples include Linea Gas Pass.
AA is a first-mover advantage game and not uniquely differentiated from a technology perspective, but rather a GTM / use-case perspective.
Because the tech configurations are all open-source, there is not much technology differentiation in the Smart Account stack (Paymaster, Bundler, SCW). The differentiation is being in the leveraged position to decide on how to route the user transactions. For example, because each transaction can only have one Paymaster – it is up to the transaction orchestrator to decide.
The goal as an “AA” provider is similar to any developer platform, which is to own the relationship and sit between the user and the dapp. The thesis is that so long as a provider owns some piece of the relationship, they can find ways to get creative around monetization (e.g., tiered SaaS for dapp or volume-based revenue)
Outside of product positioning, the way to win is to define how to structure the “CAC” story for Smart Accounts. A Smart Account pitch might be to show the LTV/CAC story – “it costs users 1 cent to transact, but your dapp makes $3 on every trade.” For example, if a dapp was built with Smart Accounts, new users could transact instantly (no keys, no gas), with higher cost associated with SCWs (deployment, function calls, etc.), that would be offset and surpassed by blended lifetime value of new users.
AA may help bridge the prevailing narratives around “One Wallet per dapp” vs “Homepage for Web3.”
To date, self-custody wallets have been built towards the “homepage for web3” direction where you have one wallet to access every dapp (collect, own, send, receive, bridge, etc.)
The recent trend of web3 consumers is pointing in the direction of “one wallet per dapp” powered by MPC wallets. A user will download a mobile app, the key is provisioned and used in that dapp only. In the chance that a user is using the same embedded wallet provider (in the background) across multiple dapps, the embedded wallet provider is able to link wallets “offchain” based on the common data identifier and consolidate them to be shown as a single interface. For example, a user using the same email log-in across multiple dapps can see the consolidated view of the wallets across those dapps.
Smart Account architecture may help unify the above two threads by allowing delegation of key signing + tx orchestration across different wallets, assuming there is a safe + secure + simple way to “link” addresses together.
Self-custody wallets will be able to “link onchain” to other wallets that the user controls, and preserve the “homepage” interface experience while allowing the user to manage more than one wallet.
Embedded wallets allow users to “link offchain” but users are only in control of wallets on a per dapp basis. A user can export the embedded wallet keys and utilize AA to link those wallets onchain. This helps transition the embedded wallet consolidation from “link offchain” to “link onchain” which results in a global embedded wallet that the user controls.
That said, AA wallets are likely best suited for single network use cases. For dapps that allow multiple networks, the pain of having to deal with SCWs deployed to multiple networks may not be worth it. Today AA development and adoption is mostly EVM focused – but other networks like Solana are also investing into AA adoption (ex. Squads Protocol).
Smart Accounts are at an early stage but maturing every week.
The pieces of the “Smart Account” infrastructure are there but market timing is still a factor.
Standardization (ERC-4337) only happened earlier this year and L2s only started picking up mindshare in Q2-2023.
Self-custodial wallets such as Coinbase Wallet and Trust Wallet have begun offering Smart Account products.
The norm for dapps is still to use self-custodial or MPC wallets (which are good enough) + the benefits are siloed by per dapp per sponsored tx per wallet. There needs to be a huge number of web3 onchain consumer apps that end up changing the consumer onboarding flow enabled by Smart Accounts from a “nice to have” to a “must have”. So far, while the concept of sponsorship enables “freemium” behavior for consumers, “freemium” behavior has not manifested en masse yet.
Passkeys still need to mature before implementing into Smart Accounts.
Standards are useful in bolstering AA adoption by making sure the ecosystem is aligned
Historically, many “sponsored gas” programs were being achieved by using custom offchain relayers. Without standards, many dapps would have followed this set-up and this would have led to a narrower path to adoption because each developer would need to adjust their set-up per use-case. Because the set-up is not generalizable, each contract would have needed to support the relayer (Relayer → Contract → User) and transactions could have broken since the contract caller is the relayer (and not the user).
Now that a standard has been set, ecosystem participants can align around how to build together. The jury is still out as to whether Smart Accounts will follow the ERC-4337 specification religiously, or if there will be modifiable plugins / specs (or even new EIPs), but the concept should follow some variant of the standard. Going forward, the main benefit is the standardized definition of the meta-transaction. This helps drive an industry-wide movement towards the benefits of Smart Accounts and creates a best practice for developers + infrastructure providers that handle it (e.g., a developer can choose between 10 different bundlers).
Where we are headed
In conclusion, Smart Accounts will continue to be a top-of-mind trend as wallet infrastructure improves to achieve a web2-like user experience.
If you are a developer exploring Smart Accounts, the Smart Wallet solution by Coinbase Wallet can be used across many apps. It’s a free, self-custodial, user-ready solution for creating a wallet in seconds directly from any dapp with just a passkey. This Smart Wallet is available on Base Sepolia testnet. Coinbase Cloud’s Account Abstraction Kit can also be used to sponsor gas and bundle transactions, available with Base Node.
Within the AA landscape, Coinbase Ventures is investing in new use-cases that emerge. If you’re building in these areas, we would love to hear from you – Ryan Yi’s DMs are open!
This material is for informational purposes only, and is not (i) an offer, or solicitation of an offer, to invest in, or to buy or sell, any interests or shares, or to participate in any investment or trading strategy, (ii) intended to provide accounting, legal, or tax advice, or investment recommendations or (iii) an official statement of Coinbase. No representation or warranty is made, expressed or implied with respect to the accuracy of the information contained herein. Coinbase may have financial interests in, or relationships with, some of the entities and/or publications discussed or referenced in the materials. Coinbase does not endorse or approve links or third-party websites that may be provided in the materials.
