This article by Ryan Yi has been edited and was first published on March 5, 2024, on Coinbase.
Summary
- Account abstraction defines a standard for meta-transactions such that users can transact and have them executed by a third party.
- In terms of adoption, the wider ecosystem is picking up and mindshare is growing.
- Value proposition is still a “nice to have”, but with technology and cost improvements, new use cases, and onboarding education, account abstraction may become a table-stakes’ “must have” infrastructure offering for users.
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. Here, we explain the value proposition, adoption inflection, and implications for the broader ecosystem.
What is account abstraction?
Account abstraction (or ERC-4337) launched in Q1 2023 to the ETH/ Ethereum Virtual Machine (EVM) ecosystem. It 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: a user signals an intent to purchase an NFT by creating a transaction request, but the actual gas plus onchain settlement is handled by a third party.
Why is account abstraction important?
There are self-custodial wallets and MPC/embedded wallets (managed keys). To date, smart contract wallets (SCWs) have had interesting security features (multi-signature, spending limits) and non-security features (batch transactions) mostly targeted at onchain decentralized autonomous organization (DAO) treasury use cases, but had limited consumer adoption due to gas cost.
With account abstraction, 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 account abstraction features will help usher in a 10x in user experience for dApps because of the following attributes:
- Sponsored gas: users do not need to incur gas cost to “load their wallet” for the first few transactions.
- Passkeys: users can utilize their Apple/Google device security to sign transactions. This will also require improvements on the ETH protocol level (EIP-7212).
- One-click transactions: one transaction sometimes takes multiple clicks – this can all be bundled.
- Security: users do not need to save one seed phrase, it can split across multiple keys/hosts.
What is account abstraction flow?
DApp/wallet creates a UserOp, a data structure that can have any signer and describes the transaction plus gas logic. This UserOp can be sent to an offchain set of nodes/networks/relayers. Example: “I want to swap for this NFT.”
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.
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 and 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 account abstraction?
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 plus 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 account abstraction product is basically a form of an All-In-One developer offering that spans the lifecycle of offchain (nodes, signatures) and onchain (contracts, gas, keys).
The go to market for an account abstraction provider is to offer the full suite of “bundler plus paymaster plus SCW” as a single toolkit.
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 account abstraction toolkit or their partner’s.
From the account abstraction provider’s point of view, they will likely begin with their core competency and then branch out to offer other services.
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-signature wallets. They now offer an account abstraction SDK, which allows integration with other providers on the bundler plus 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 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: Wser pays gas cost in the UserOp – Bundler handles the operation plus charges a fee
- Bundled SaaS: Company will charge a month-end total product fee to the developer team based on % per bundler API call plus 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.
How is account abstraction useful and how is it 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 third-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 (as opposed to 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 (versus 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 state of account abstraction adoption?
Total Accounts: 1.3 million
Total Accounts are the number of account abstraction-compatible SCWs created. They can be auto-created within the wallet interface or created indirectly through a partner app.
Total UserOps: 6.5 million
Total UserOps are the number of transactions powered by account abstraction.
Total Gas by Paymasters: $655,000.
Total Gas by Paymasters are the total lifetime dollars of gas paid by third parties.
Mindshare: Large developer players (ex. Alchemy*, ThirdWeb*, Circle*) as well as new start-ups have emerged to tackle the account abstraction segment.
What is constraining account abstraction?
- Cost-Benefit Analysis
Smart account value proposition: The gas sponsor plus 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 user experience (UX) will have been raised to match those standards.
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 and signed by the user, but users pay the gas per transaction. For SCWs, interacting through account abstraction (via a bundler) is a bit slower (anecdotally two to five seconds slower), and also the cost-to-deploy at scale is another limiting factor.
- Passkey adoption
Passkeys are growing in popularity and becoming normalized as part of crypto user UX, but the cost of validation remains 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, it 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 account abstraction offerings 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. MPC wallet providers are expected to eventually add support for account abstraction in their developer offerings, assuming gas costs come down.
- Developer/product education
The conversation about 4337 is highly technical and the marketing of SCW/account abstraction needs to be product/UX-forward in terms of the benefits. There are already account abstraction-powered wallets that can connect to any dApp, which aligns it to the existing crowd of self-custody and MPC wallets. Self-custody wallets are expected to add more support for SCW over time.
The outlook for the smart account ecosystem
There are six key facets of the current account abstraction ecosystem.
Key point one
AA adoption is beginning but there is no breakout success case yet.
The two biggest issues for onboarding a new user onto a dApp are that users typically do not have a pre-configured wallet or an ability to pay for initial transactions.
A breakout moment for the first of these issues happened last year with mobile in-app onboarding with simple social login/verification (no Connect Wallet button) powered by application embedded MPC wallets.
The demand for a preconfigured wallet is still developing.
But account abstraction’s time is coming. The biggest barrier to SCW adoption was gas cost (on ETH L1). With L2s the cost has come down significantly and 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 and 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 (versus 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.
Key point two
Account abstraction 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, and as such, the cost of transactions gas has significantly improved. The next step is for developers to enable AA because users now want seamless transactions.
Once a user is onboarded, they will use the app and initiate the concept of lifetime value (LTV). So long as the LTV is greater than the CAC, it is worth it for the developer to explore the CAC enabled by account abstraction. 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 and sponsored gas/dust for the first five transactions, knowing that the dApp will make a break-even ROI on the sixth 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.
Key point three
Account abstraction is a first-mover advantage game and not uniquely differentiated from a technology perspective, but rather a GTM/use case perspective.
Because the technology 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 account abstraction 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 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.
Key point four
Account abstraction may help bridge the prevailing narratives around One Wallet per dApp versus 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.
On the off 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 and tx orchestration across different wallets, assuming there is a safe, secure and 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 account abstraction 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, account abstraction 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, account abstraction development and adoption is mostly EVM focused, but other networks like Solana are also investing into account abstraction adoption (ex. Squads Protocol).
Key point five
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.
The norm for dApps is still to use self-custodial or MPC wallets, which are good enough and 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. The top three consumer self-custodial wallets do not implement account abstraction yet.
Key point six
Standards are useful in bolstering account abstraction adoption by making sure the ecosystem is aligned.
Historically, many sponsored gas programs were achieved 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 and infrastructure providers that handle it (e.g. a developer can choose between 10 different bundlers).
What’s the outlook for smart accounts?
Smart accounts will continue to be a top-of-mind trend as wallet infrastructure improves to achieve a Web2-like user experience.
A version of this article first appeared on Coinbase.
