Gen2 WaaS : Navigating the Shift to Smart Accounts
A Deep Dive into Account Abstraction
The concept of Smart Account, or Account Abstraction (AA), was created primarily to enhance the user experience beyond what is possible with a “traditional” account, Externally Owned Accounts (EOAs), thereby making the web3 more accessible. Although is not a new concept is the ecosystem, its gained some important traction following the recent implementation of the ERC-4337 standard.
In my previous article, I explored the challenges of traditionally onboarding a decentralized application, and how the first generation of Wallet-as-a-Service (WaaS) significantly enhances this user experience.
As you can see, most issues have been addressed. However, one significant problem remains: users must hold native tokens (e.g., ETH, MATIC, etc.) to pay for gas (network) fees to interact with a decentralized application.
As you might have guessed, Account Abstraction resolves this issue.
Account Abstraction sets a standard that allows users to transact on the blockchain without initiating a transaction themselves. In this new model, a user signals an intent (e.g., buying an NFT), while the actual gas fees and on-chain settlement are managed by a third party. This way, user interactions can be sponsored or paid for with any ERC-20 token.
The advantages of this AA model extend beyond this, but as always, let's delve a little deeper into what's actually happening.
What Exactly is Account Abstraction?
Before we dive into account abstraction (AA), it’s important to review the basic types of accounts within the Ethereum ecosystem.
An account on the Ethereum blockchain is essentially a user’s representation that can send and receive transactions and interact with other on-chain accounts. There are two main types of accounts:
Externally Owned Accounts (EOAs): These are what most people think of as their "wallet." Created using wallet software like Metamask or the Wallet-as-a-Service (WaaS) platforms mentioned in my previous article, EOAs are managed through a cryptographic pair of public and private keys. EOAs are "active" in that they can initiate transactions and pay gas fees. However, their functionality is primarily limited to transferring assets and interacting with smart contracts.
Contract Accounts: Also known as smart-contracts, these accounts are not managed by private keys but are instead deployed on the blockchain and controlled by the code within them. Contract accounts are "passive," meaning they can only execute transactions in response to those initiated by an EOA and cannot themselves pay gas fees.
With these fundamentals in mind, let’s get into the concept of account abstraction.
In simple terms, Account Abstraction is a technology that allows users to operate smart-contracts as their personal accounts, referred to as "Smart Accounts." This capability enables users to establish custom rules for spending and transferring assets, thereby broadening the scope of possible use cases for web3 applications.
Account abstraction also introduces the concept of "signature abstraction." Traditionally, transactions from EOAs require a signature generated by the private key using the Elliptic Curve Digital Signature Algorithm (ECDSA) for validation. While first-generation WaaS providers have simplified private key management through methods such as social logins, they still depend on a basic security model.
Signature abstraction addresses this by eliminating the need for ECDSA signatures as the sole method of authorization. Instead, users can set their own rules for how their Smart Accounts initiate transactions. This innovation not only simplifies the user experience but also enhances security, opening up new possibilities for managing digital assets on the blockchain.
How Does Account Abstraction Work & What is ERC-4337?
At this point, we understand that users can use smart-contracts as personal accounts. This setup allows for the addition of custom functionality and authorization policies. But how does this work behind the scenes ?
Before the adoption of the ERC-4337 standard, there were two primary methods proposed for achieving AA: 1) Allowing "traditional" externally owned accounts (EOAs) to execute code, and 2) Enabling smart-contracts to initiate transactions. The ERC-4337 standard, which was accepted last year, adopts the latter approach and has since been embraced by the ecosystem.
To understand ERC-4337, we need to delve into its technical components, although I'll keep this explanation at a high level. For those interested in more detailed information, I recommend checking the official documentation.
ERC-4337 introduces a new protocol layer that changes the basic transaction type without altering the underlying consensus-layer protocol. It defines a concept called UserOperation (UserOp), which acts like a pseudo-transaction. Additionally, ERC-4337 introduces the role of the paymaster, which enables decentralized "sponsored transactions" in two main ways:
Payment with ERC-20 Tokens: Users can pay gas fees using ERC-20 tokens instead of native tokens like ETH or MATIC. A paymaster fronts the cost of the transaction in a native token and is reimbursed with an ERC-20 token, such as USDC.
Gasless Transactions: A decentralized application (dApp) can sponsor user transactions by directly compensating the paymaster.
Users initiate an interaction by signing a UserOp with their chosen authorization method and sending this to an alternative mempool. Special nodes, known as Bundlers, collect these UserOps and package them into a single transaction known as a bundle transaction. These bundle transactions are then sent to a unique global smart-contract on Ethereum called the EntryPoint.
The EntryPoint smart-contract ensures that the Smart Account has sufficient funds to cover the gas costs or verifies with the Paymaster if the UserOp’s gas fees are being sponsored. It also manages the payment of gas fees owed to the Bundler. If everything checks out, the transaction is executed on the blockchain with validation and execution handled by the smart account.
New Use Cases Enabled by AA
Let's move away from the technical details and explore the new use cases enabled by Account Abstraction.
Enhancing Gas Fee Payments
A key advantage of AA is the elimination of the need for users to hold the blockchain's native tokens in their externally owned accounts (EOAs) to cover gas fees. With the introduction of paymasters, as previously discussed, transactions can either be sponsored by dApps or paid for in ERC-20 tokens. Users no longer need to pre-fund their smart accounts; instead, a sponsoring dApp can link the user’s smart account to a paymaster, covering the cost of account creation and future transactions, either at no cost to the user or by using tokens like USDC.
Flexible Authorization Schemes
AA allows for complex and customized authorization rules through "signature abstraction" and the programmability of smart contracts. Users can configure various settings including:
Multi-signature: Specify the required number of signatories to validate transactions.
Time Period: Set a validity period for keys approvals.
Spending Limits: Establish limits on the amount of ERC-20 or native tokens that can be spent.
Contract Restrictions: Limit interactions to specific contracts or specific functions within those contracts.
Payment Automations
Traditionally, blockchain transactions were "push" transactions, where the account owner needed to actively initiate transfers. AA introduces the ability to set up "pull" transactions, where a third party is authorized to automatically withdraw funds from a Smart Account at specified intervals. This mimics web2 functionalities like automatic payments and subscriptions, enhancing the user experience in web3 applications.
Batch Transactions
Batching transactions can significantly improve user experience. For example, consider the process of selling an NFT on Bloom:
Traditionally, a user must approve the transfer of their NFT to the marketplace smart-contract and then create the selling offer—two separate steps.
With AA, this can be streamlined into a single action.
Moreover, when a user adds multiple NFTs to their cart in a marketplace, AA can consolidate all required signatures into a single confirmation at checkout, simplifying the process considerably.
Improved recovery mechanisms
Account Abstraction (AA) introduces more adaptable and user-centric recovery options. A key feature of this advancement is social recovery. This method allows users to recover their accounts through designated recoverers—be it personal backup devices, family members, friends, or collaborators. Such flexibility significantly enhances security and user trust by diversifying recovery methods beyond traditional secret phrases or keys. Furthermore, trusted third-party service providers like CoinCover can also serve as recoverers, adding an extra layer of reliability.
How can you implement AA ?
To effectively integrate AA and benefit from its new possible use cases, you will need to integrate the following key components:
Smart-Account implementation including robust authentication options to ensure secure user interactions.
Paymaster service
Bundler service
There are various providers in the market offering these services. Some offer comprehensive solutions that include all three components, while others allow for a more customized approach, letting you mix and match Smart-Account, Paymaster, and Bundler services according to your specific needs.
Account Abstraction Adoption & Retention Overview
All data coming from BundleBear : https://www.bundlebear.com/overview/all/month
As of April 2024, there are 4,558,663 total ERC-4337 Smart-Accounts, with 15,999,087 UserOps having been performed.
To better understand the adoption and retention rates of these accounts, let's examine the Monthly Active Smart Accounts — the number of accounts that made at least one UserOp, including deployment, within a month.
Since November of last year, at least 400,000 accounts have performed one pseudo-transaction every month. February saw a record high, with over 900,000 accounts active. Although there has been a slight decline since that peak, the activity still remains robust with more than 400,000 accounts monthly.
Polygon dominates this ecosystem, hosting 93% of these accounts. This popularity likely stems from its cost-effectiveness for operating ERC-4337 accounts, as detailed in BundleBear’s analysis of gas costs.
The introduction of Ethereum’s EIP-4844 in March this year brought a new transaction type known as a blob, primarily used by rollups to post data to Layer 1 (L1). This upgrade was expected to significantly boost AA adoption through reduced costs for Ethereum rollups and Smart Accounts. Even though successful UserOps on Base, an Ethereum roll-up, have doubled after the update, as we can see from the numbers above, the anticipated surge in adoption has not fully materialized.
Moreover, the 4-week retention rate for the latest cohort of ERC-4337 accounts is only 0.26%. This indicates that four weeks after creation, just 0.26% of accounts continue to perform at least one UserOp per week.
To finish up, a significant portion of UserOps (52%) are associated with NFT drops, suggesting that many accounts are being used as "disposable" options. This pattern might point to a lack of compelling applications that drive long-term user engagement and retention.
In this manner, I would conclude that AA adoption is starting but there is no breakout success case yet, product-market-fit still needs to happen.
In conclusion, while AA is seeing initial adoption, a definitive success story has yet to emerge. The quest for a strong product-market fit (PMF) continues.
The Big Question : Should You Implement Account Abstraction ?
First, as I mentioned in my initial article on wallet infrastructure, consider your users. If your application is already live and users are used to a certain type of wallet, transitioning to an AA solution will require user action—at least 2-3 clicks—and possibly a financial investment. It's essential to weigh the benefits and the perceived value it brings to your users against the potential burden.
Another crucial point to consider is the promise of sponsored transactions for seamless user experiences. Remember, nothing is free. Absorbing the gas fees means incurring costs on your side. When using AA to boost user acquisition, factor in these costs to calculate your Customer Acquisition Cost (CAC). Once a user is onboarded, their Lifetime Value (LTV) begins to accrue. Financially, it makes sense as long as LTV exceeds CAC. A common model involves the dApp sponsoring the deployment of the Smart-Account plus the first few transactions up to the point where the return on investment (ROI) breaks even.
Lastly, consider adoption trends. Although there is significant excitement around AA and ERC-4337, as discussed previously, the product-market fit isn't quite there yet, and the market could shift direction. With ongoing Ethereum Improvement Proposals (EIPs) like EIP-3074—a modification of the protocol allowing externally owned accounts (EOAs) to delegate transaction capabilities to smart-contracts, the landscape remains dynamic. Note that the Ethereum Core Developers plan to include EIP-3074 in the upcoming Prague/Electra hard fork, targeted for Q4 2024/early 2025.
In my view, the future will likely see a shift towards smart accounts, but as this article outlines, it's still too early to confirm definitively. If you're considering making the switch, carefully assess the risks and benefits it may offer.
At Bloom, we are deeply invested in exploring wallet infrastructure, a critical aspect of building in the web3 space. We'll continue to delve into this topic, so stay tuned for more insights!