Author: Steve Wang, current student @UPenn Wharton, frontend and smart contract developer, prev. @Foresight Ventures
Account abstraction, as defined in Ethereum Improvement Proposal 4337 (EIP 4337), is a set of protocol interfaces that not only integrate web2-familiar user interactions such as multi factor authentication, but also address web3-specific user pain points such as gasless transactions. Alternatively termed as the protocol that onboards the next billion users, account abstraction focuses on smooth user experience at the forefront.
Although many existing articles explain account abstraction very well, they are either entirely introductory or too focused on the technicals. This article aims to provide both a high level understanding of account abstraction concepts and a deep dive into existing applications. In part 1, we will explore the origins of EIP 4337 and delve into its technical details, including
UserOperation, Bundler, Paymaster, Wallet Factory, and Signature Aggregator. In part 2, we will profile and analyze existing market players in the space. In part 3, we will discuss the way forward for account abstraction, including innovations that are still lacking in the space.
Part 1: EIP 4337 and Technical Review
To very briefly go through the basics, there are two types of accounts in Ethereum: externally owned accounts (EOA) and contract accounts.
EOAs are user controlled accounts that can send transactions. EOA defines the ownership of an account through its private key, which can sign and execute transactions to change the EOA’s internal state or external smart contracts’ states. Because private key (or its alternative form, seed phrases) is everything, EOA isn’t good for defining complex ownership or transaction logics such login with social media accounts and multi-party signed transactions. The limitations of EOA translate into poor user experience, where counterintuitive things like private key and seed phrase management deters Web2 users from entering Web3. The most popular wallets, such as MetaMask, are based on this model.
Contract accounts host arbitrary Solidity codes and therefore can access all the Turing-complete functionalities of EVM. Because they cannot send transactions, their functions must be triggered by EOAs. Smart contract wallet is a contract account which is indirectly triggered by its user through the wallet provider’s EOA network, whether Relayers or Bundlers.
Figure: EOA vs contract accounts (credit to Bitcoin Insider)
Smart contract wallets exist before EIP 4337, which was only later proposed to codify the common functionalities of a smart contract wallet and its related infrastructures. EIP 4337 follows a few design principles:
Overall, all implementations should be on a high level (smart contract level) and shouldn’t touch lower level infrastructures such as the consensus and execution engines, due to the constraint on developer resource, most of which had been focused on the Merge.
The protocol design should be modular, so that users can customize options including transaction processing (Bundler), gas payment (Paymaster), signature scheme (Aggregator).
Ideally, each service will become a competitive open market, where users select the best service based on providers’ price and reputation.
EIP 4337 defines six contract interfaces for standardized smart contract wallets:
First, the smart contract wallet itself, which allows Bundler to validate a transaction off-chain and then process it on chain.
Second, the Bundler, which validates and executes smart contract wallet transactions (called
UserOperation) in batch.
Third, the Entry Point contract, a global singleton contract which standardizes transaction execution and insulates the bundler from potentially malicious transactions.
Fourth, the Paymaster, which handles gas payment on behalf of the wallet user.
Fifth, the Wallet Factory, which standardizes wallet creation.
Sixth, the signature Aggregator, which aggregates the signatures of multiple transactions to bytes for faster validation and execution.
Now, I will elaborate on
UserOperation and the six contract interfaces defined above. I drew my inspiration from the official EIP 4337 doc and a series of technical reviews by David Philipson @Alchemy.
UserOperation is essentially a transaction with additional account abstraction specifications. Recall that a regular ethereum transaction, which can only be triggered by an EOA, has fields such as recipient address, ethereum amount, gas amount, and gas price.
Besides, given the highly customizable nature of account abstraction,
UserOperation include the following important fields:
calldata: defines the signature and input parameters of the function to call on the smart contract wallet (also in a regular transaction)
signature: verifies that the transaction is indeed from the smart contract wallet (also in a regular transaction)
nonce: prevents replay attacks (also in a regular transaction)
sender: specifies which smart contract wallet should execute the
paymasterAndData: used for gas abstraction, containing Paymaster address and specifications for gas payment
initCode: used for wallet creation, containing Wallet Factory address and parameters for the smart contract wallet
Other than the additional fields,
UserOperation works similarly to a regular transaction, such that they are both broadcast to a mempool for validation, execution, and inclusion in a block. Validation and execution of
UserOperation is handled by Bundlers, which we explain next.
UserOperation parameter definition by official EIP 4337 doc
Bundler validates and executes
UserOperation transactions on the smart contract wallet on behalf of its user and acts like an EOA, because all transactions must be triggered by an EOA on Ethereum. Bundler saves the user from creating and remembering the private key of an EOA in order to trigger smart contract wallet transactions, which defeats the very purpose of having a smart contract wallet.
Despite the public good they contribute to, Bundlers are economically self-interested, because:
Bundlers can pocket the difference between the maximum priority fee and the actual gas spent after executing a
Same as relayers of regular transactions, Bundlers can extract MEV by ordering transactions in a bundle
Despite the cost, Bundlers are good for gas savings, because executing each transaction costs a fixed overhead of 21,000 gas, so that executing a bundled transaction spread the fixed cost over multiple transactions, thereby saving gas cost. Besides, modifying storage in the same transaction is incrementally cheaper for each additional operation.
Note that although transactions are executed linearly (non-parallel) on Ethereum to avoid state conflicts,
UserOperations can be executed as a bundle, because Bundlers will try to include at most one transaction for each smart contract wallet address, so that
UserOperations don’t clash with each other when modifying the state.
Apart from these differences, Bundlers are similar to block builders because both broadcast validated
UserOperation transactions to a public or private mempool.
Next, we introduce the Entry Point Contract, which the Bundler has to interact with in order to execute a
3. Entry Point Contract
Entry Point Contract is a global singleton contract that all Bundlers need to call to execute a
UserOperation. It acts as the middleman between Bundler and smart contract wallets:
On one hand, Bundlers calls the Entry Point Contract’s
handleOpfunction, which takes a
handleopis responsible for validating and executing a smart contract wallet function according to the
handleOpfirst validates the
UserOperationon chain, by checking that it’s signed by the designated smart contract wallet and that the wallet has enough gas to pay the Bundler
If validation is successful,
handleOpexecutes the smart contract wallet function according to the function’s signature and inputs defined in the
On the other hand, smart contract wallets are required to deposit tokens to the Entry Point Contract to pay gas to Bundlers. Gas is incurred when Bundler triggers
handleOpfunction using an EOA.
Alternatively, smart contract wallet can pay gas to Bundler using its own balance, or ask a Paymaster to handle the payment, which we will elaborate later
UserOperationwithout enough gas held by its destination smart contract wallet won’t pass the validation step, thereby failing before execution
Even with enough gas, a
UserOperationcan still fail at the execution step, for example, due to a runtime error
Whether the execution is successful or not, the Entry Point Contract will pay gas to the Bundler for triggering the
The Entry Point Contract provides methods for smart contract wallets to add or withdraw stakes
Figure: Entry Point Contract workflow by official EIP 4337 doc
4. Smart Contract Wallet
The smart contract wallet separates the validation and execution steps of a
Validation is defined in the
validateOpfunction. It’s called twice: once off chain by the Bundler to validate the signature of the
UserOperationand gas balance of the smart contract wallet as a simulation; then again on chain by the Entry Point Contract to validate the
Execution is defined in the
UserOperation, which specifies the signature and inputs of a smart contract wallet function
Therefore, validation and execution are separated, so that the Bundler can validate
UserOperation off chain and filter out malicious transactions without paying gas. The
validateOp function is similar to an off chain debugging API.
Paymaster defines the gas abstraction logics of a smart contract wallet. Gas abstraction means gas payment in alternative ERC20 tokens or gasless transaction, which requires gas sponsorship from a Paymaster. The modular design of ERC-4337 means that a
UserOperation can choose an arbitrary Paymaster by specifying its address and input parameters using the
paymasterAndData field. Paymaster has the following features and requirements:
It is essentially a smart contract deployed by a dApp to selectively pay gas for
UserOperationusing arbitrary logic defined an exposed
validatePaymasterOpfunction that the Bundler triggers
Paymaster is required to deposit ETH on the Entry Point Contract to pay gas for
In addition to the gas deposit, Paymaster also need to deposit an ETH stake on the Entry Point Contract; this stake won’t be slashed, but acts as a barrier to prevent Paymaster creation spam
The open market nature of Paymasters (anyone can implement the interface) encourages competition. There’s no centralized or on chain reputation system, but Paymasters are incentivized to reliably serve
UserOperations, as Bundlers can keep a track record of their operations and stop using lower quality Paymasters.
Paymaster interface exposes two functions:
validatePaymasterOp: defines the gas abstraction logic. For example, in a scenario where the smart contract wallet pays gas in a ERC20 token, this function will make sure that the wallet has enough balance.
validatePaymasterOpis called before a
UserOperationis executed. The same design logic that separates validation and execution applies here
postOp: is called at the last step of a smart contract wallet function call, and will revert the function call if the wallet doesn’t have enough ERC20 balance to reimburse gas to the Paymaster.
postOpdouble checks that gas is still sufficient after executing a function. Gas is still extracted if a function call fails at this step
Figure: workflow with Paymaster by official EIP 4337 doc
Figure: Paymaster interface by official EIP 4337 doc
6. Wallet Factory
Wallet Factory is a contract that creates smart contract wallets. Recall that
UserOperation has an optional
initCode field. When
initCode is empty, the
UserOperation simply triggers a smart contract wallet function. When
initCode is filled with a Wallet Factory address and the parameters for the new smart contract wallet, the Bundler will trigger the corresponding Wallet Factory to create a smart contract with specified parameters.
Wallet Factory helps achieve account abstraction in the following aspects:
User can ask a Bundler to create a smart contract wallet without ever owning an EOA, by submitting a
User can customize their smart contract wallet by selecting a specific Wallet Factory with predefined customization options and passing in their own parameters. Besides, because Wallet Factory contracts are public and well known ones are likely thoroughly audited, creating new wallets using factories is safe for users
User can choose to have a Paymaster sponsor gasless wallet creation or pay gas in alternative ERC20 tokens, without even owning ETH. On the other hand, Paymasters can choose to pay gas for smart contract wallets deployed by approved Wallet Factories
User can know their smart contract wallet address before creating the wallet by calling the
CREATE2function, which generates a smart contract address deterministically using the EOA address that triggered the smart contract creation, a salt, and the
initCode. This delays gas payment for wallet creation until the user conducts their first transaction, thereby improving user experience.
Wallet Factories have additional responsibilities as well. Similar to Paymaster, they need to stake ETH on the Entry Point Contract and keep a good track record of serving
UserOperations, in order to generate more traffic from Bundlers.
7. Signature Aggregator
Because different smart contract wallets use different signature schemes, it’s essential to aggregate
UserOperations with the same scheme for separate validations. Besides, because on chain cryptographic arithmetic can be gas intensive, signature schemes that support aggregation such as BLS can help save gas during on chain validation. These considerations require another EIP 4337 interface called Signature Aggregator, which is essentially a smart contract that supports a specific signature scheme by implementing two functions:
aggregateSignatures: takes an array of
UserOperationsand returns an aggregated signature using a specific scheme
validateSignatures: takes an array of
UserOperationsand the aggregated signatures
Instead of validating one
UserOperation at a time, Bundlers will first generate multiple aggregated signatures (one for each signature scheme) using multiple Aggregator contracts (one for each signature scheme). Then, the Bundler passes
UserOperation arrays, aggregated signatures, and Aggregator addresses to the Entry Point Contract, which calls each Aggregator’s
validateSignature function. Once validated, the Bundler executes
UserOperations on smart contract wallets.
Similar to Paymasters and Wallet Factories, Aggregators need to stake on the Entry Point Contract as well and keep a good track record of serving
Figure: Signature Aggregator interface by official EIP 4337 doc
8. Overall Workflow Summary
The modular design of EIP 4337 splits the account abstraction features of smart contract wallets to multiple interfaces. However, they are simply moving pieces in one giant work flow summarized below:
User sends a
initCodefield, Bundler triggers Wallet Factory (through the Entry Point Contract) to create a new wallet deterministically
paymasterAndDatafield, Bundler collects gas payment from Paymaster’s stake on Entry Point Contract. If not, Bundler collects gas payment from smart contract wallet’s stake on Entry Point Contract
Bundler can elect to aggregate signatures
Bundler will simulate
UserOperationoff chain using a combination of
If off chain simulation passes, Bundler validates
UserOperationon chain using a combination of the functions above
If on chain validation passes, Bundler executes
UserOperationon chain, and collects gas payment whether execution succeeds or not
Figure: account abstraction workflow without Signature Aggregator (credit to Alchemy)
Figure: account abstraction workflow with Signature Aggregator (credit to Alchemy)
9. Other Considerations
UserOperation is validated both off chain and on chain, to prevent inconsistent validation results due to changing contexts, EIP 4337 restricts access to storage and OpCodes that read the global state such as the timestamp. This restriction applies to
Part 2: Account Abstraction Market Players
1. Smart Contract Wallet with SDK
Smart contract wallets are the most obvious players in the account abstraction wallet. To be compatible with EIP 4337, they often implement their own Bundler, Paymaster, Wallet Factory, and Signature Aggregator. These wallets also come with SDKs for dApp integration. The market is relatively crowded, with existing players such as Gnosis Safe implementing additional account abstraction features, and new players such as Candide building a new smart contract wallet. This section will introduce the common features of these wallets and minor differentiating points within each feature.
a. Social Login and Social Recovery
Social login provides a very familiar Web2 feel for smart contract wallets, such as creating and logging in a wallet with an existing Google account. The same extends to social recovery as well, such as resetting the password of a smart contract wallet using a recovery email. Social login and social recovery logics are defined in the wallet’s main contract.
Here we introduce the concept of Guardian, which refers to the entities that grant access to or helps recover an account, whether a Web2 login or an email address. This concept was well developed in Web2 and now comes to smart contract wallets as well thanks to account abstraction.
There can be multiple Guardians for one smart contract wallet. User needs to set up the Guardians during or after wallet creation and reach a certain threshold of Guardian authentications, such as 2 out of 3 Guardians, in order to login or recover a wallet. This process is familiarly termed as multi factor authentication. Here are the common types of smart contract wallet Guardians:
Web2 service provider: such as your social media account, usually achieved by implementing the OAuth (Open Authorization) standard, which allows the wallet to access login information hosted by another Web2 app on behalf of the user
User device: such as browser storage and mobile storage
Email: such as sending a signature by clicking an authorization email link
Multisig: user can set up multiple EOA or smart contract wallet controlled by trusted individuals as Guardians
MPC: user can split private key into shares, each controlled by a node in an MPC network without revealing the full key
SWIE (Sign-In With Ethereum)
Let’s see a few market players’ implementations:
Web3Auth is a social login and MPC service used by many notable smart contract wallets including Biconomy, Etherspot, and 0xPass. Web3Auth splits and secures user key shares under social login, user device, and their MPC node network. The implementation is entirely off-chain, and no party stores the full private key. (See figure below.)
BLS Wallet and Argent allow social key recovery with nominated EOA addresses using Multisig.
UniPass implemented an innovative approach that uses email for social recovery. Guardian’s email is submitted on-chain and its DKIM signature is verified on chain using a smart contract. DKIM, or Domain Keys Identified Mail, is an email authentication protocol that creates a digital signature that mailbox providers use to verify the identity of an email sender. UniPass also uses zk proofs to desensitize user information on chain. Other non-email social recovery methods are also supported.
Soul Wallet verifies Guardian’s email on chain for social recovery.
Figure: social login and social recovery by Web3Auth with multiple guardians
b. Gas Abstraction
Gas abstraction refers to sponsored gasless transaction or gas payment in arbitrary ERC20 tokens. The logics can be implemented in a Paymaster contract or through Relayers.
Many smart contract wallets implement their own EIP 4337 compatible Paymaster contract and stake tokens on the Entry Point Contract to handle gas payments on behalf of users.
Relayer is another gas abstraction solution that exists before EIP 4337. Relayers are trusted forwarders that execute a special type of gasless transactions called “meta transactions”. A meta transaction is an Ethereum transaction that inserts another transaction in the original one. The user signs it using their private key and sends it to the Relayer, which verifies it, submits it to the blockchain, and handles the fee. The Relayer only executes the transaction without changing it. Relayers are economically incentivized, as they charge the transaction’s recipient contract the gas payment plus a small fee. For example, Relayer can charge a dApp which sponsors gas fees for its users. Relayers can be centralized trusted parties, or a decentralized network. Relayers are different from Paymasters in the following ways:
Besides paying gas, Relayers also sign transactions, similar to what a Bundler does in EIP 4337
Relayers don’t exclusively handle
Relayers don’t stake gas payments on Entry Point Contract
Let’s see a few market players’ implementations:
Biconomy has not only its own EIP 4337 compatible Paymaster, but also a Relayer network that handles ERC20 gas payments.
Argent uses third party Relayer to pay gas fees in the form of meta transactions.
Candide has its own Paymaster implementation
UniPass uses its own Relayer node to pay gas fees. It plans to add a “watch ad for free transaction” mode and to support gas payment using bridge in the future.
So far, most ERC20 gas abstraction solutions, such as Candide and Soul Wallet, only support very limited token types, mostly stablecoins, though I foresee that this will change in the future.
Figure: Biconomy supporting gasless transactions using Paymaster (EIP 4337 implementation)
Figure: Biconomy paying gas in ERC20 token using Relayer (non-EIP 4337 implementation)
c. Ramps and Bridges
Fiat on and off ramps and bridges are already natively integrated in many existing wallets such as MetaMask, through third party partnerships. Integrating these with gas abstraction into one click gas payment solutions is super exciting.
Let’s see a few market players’ implementations:
Biconomy and 0xPass partner with Transak to provide fiat ramps. Biconomy also offers multi-chain bridge and messaging.
Argent Vault partners with Moonpay, Transak, and Wyre for fiat ramps and also has a built-in DeFi protocol aggregator.
Etherspot, UniPass, and Braavos support fiat ramps, swaps, and bridges.
d. Transaction Batching
Transaction batching is a feature uniquely enabled by smart contract wallets, allowing wallet user to perform multiple transactions in one single on-chain transaction. One implementation is by calling a
multiCall function which takes an array of
calldata and an array of contract addresses corresponding to multiple function calls. The
multiCall function loops through the arrays and executes multiple function calls in one transaction. Transaction batching helps reduce the fixed gas cost per Ethereum transaction.
Note that transaction batching is different from signature aggregation, which takes an array of
UserOperations and returns an aggregated signature for faster validation. Here, each
UserOperation can perform a
multiCall that performs transaction batching.
In the context of EIP 4337, the Entry Point Contract will call the
handleOp function, which calls the
multiCall function defined by a smart contract wallet.
Let’s see a few market players’ implementations:
Biconomy sets up a multi-call contract which smart contract wallets will call and batch execute functions.
Argent performs transaction batching through a smart contract module called Transaction Manager that enables multi-call and user sessions.
Etherspot, Candide, Openfort, and 0xpass all support transaction batching.
Figure: example MultiCall contract (credit to Solidity by Example)
e. Modular Design of Smart Contract Wallet
One major advantage of smart contract wallet over EOA is its modular design. The wallet’s functionalities can be extended by pluggable contract modules developed by wallet provider. These modules offer features that are not defined in EIP 4337’s interfaces, and can be customized by users. The modular design makes smart contract wallets upgradeable, and is an industry standard practice before EIP 4337 came out, pioneered by products such as Gnosis Safe, a multisig wallet mainly targeting business users. Non EIP 4337 features offered by Gnosis Safe include:
Spending policies: Limit the amount that a signing account can withdraw from a Safe.
Scheduled transactions: Automatically execute transactions on a schedule.
Roles and Permissions: Set fine grain rules on what types of actions specific accounts can perform.
Hierarchies: Different permission sets based on roles within an organization.
Allow and deny lists
The same modular design has been inherited by EIP 4337 compatible wallets, including Argent, Candide, Soul Wallet, and zeroDev.
Another way of extending a smart contract wallet’s functionality is by natively integrating dApps. For example, Gnosis Safe provides an SDK for dApps to directly appear in the wallet interface, essentially providing a built-in App store for the wallet. Other similar solutions include WalletConnect. These, however, are not protocol level designs, and are therefore out of our scope.
Figure: Candide Wallet’s modular design is similar to Safe’s (prev. Gnosis Safe)
2. Infrastructure Providers
I will talk about support for account abstraction on various Layer 2s and pure-play infrastructure providers of Bundlers and Paymasters.
a. Account Abstraction on Layer 2s
Given the recent explosion of L2, many smart contract wallets have pivoted development efforts towards L2, many of which have native support for account abstraction adapted from EIP 4337 that this section will explore.
The first version of Optimism implemented account abstraction by introducing three OVM OpCodes that aren’t in EVM. In practice, the only type of account is a smart contract (no EOAs) and all user wallets are smart contract wallets. Smart contract wallets are also upgradeable by sending a transaction that calls an
Unfortunately, these features were removed in their second version in order to be identical to the EVM and due to security concerns.
Although a handful of smart contract wallets are building on Optimism, there’s no official announcement for account abstraction support yet.
Although a handful of smart contract wallets are building on Arbitrum, there’s no official announcement for account abstraction support yet.
Unlike Ethereum, Starknet doesn’t distinguish between EOA and contract account. Therefore, all Starknet accounts are smart contract accounts. Starknet’s account model is heavily influenced by EIP 4337 in the following ways:
All Starknet accounts must include
validateis required, so that only account owners can initiate transactions and that transaction executors are guaranteed gas payments. Users can implement arbitrary logics in
executefunctions for full flexibility of their account. For example, different signature schemes can be implemented in the
validatefrom calling external contracts, to prevent scenarios where a transaction passes validation but not execution.
There are notable implementation differences from Ethereum, though:
Starknet doesn’t distinguish between regular transactions and
UserOperations, because all transactions are triggered by contract accounts. In Ethereum, Bundlers execute
UserOperationtransactions, whereas in Starknet, sequencers execute all transactions.
Starknet has yet to implement a native gas abstraction protocol like Paymaster.
Starknet requires an existing funded account to call a special
deploy_accounttransaction in order to create a new contract account. In EIP 4337, contract account is deployed by executing a
UserOperationtransaction with the
initCodefield and the deployment doesn’t require a funded contract account, because gas payment can be sponsored by a Paymaster.
If a validated transaction fails at the execution step, sequencer won’t be reimbursed for gas payment. Ethereum doesn’t have this problem.
Figure: Starknet doesn’t have EOA account type, only contract accounts
zkSync also doesn’t distinguish between EOA and contract account and therefore natively supports account abstraction. zkSync’s account model is similar to EIP 4337 in the following ways:
The Account (smart contract wallet) interface separates
The Paymaster interface includes
postOpfunctions. The former defines a Paymaster’s arbitrary logic for sponsoring transactions. The latter will ensure that Paymaster is refunded with gas payment after transaction execution, though this is not implemented yet.
A transaction invokes Paymaster by filling in the
paymasteraddress field and the
paymasterInputfield, similar to EIP 4337’s
There are notable implementation differences, however:
validateTransaction, zkSync allows OpCodes for calling deployed contracts, which are immutable on zkSync. Ethereum restricts these to prevent changing contexts between transaction validation and execution
validateTransactionis allowed to access external storage associated with the contract account that calls the transaction, such as the contract account’s token balance
Paymaster has no external storage restriction during transaction validation
b. Pure Play Infrastructure Providers
As elaborated above, account abstraction infrastructures include client SDKs that can send
UserOperations, Bundlers, Paymasters, and Signature Aggregators. These infrastructures are commonly implemented by smart contract wallets themselves to achieve vertical integration, but are mostly not designed for third party use. That’s why there exists pure play third party infrastructure providers of modular and customizable Bundler and Paymaster services, including notable infrastructure players such as Alchemy. This section lists a few of them.
Stackup is a Bundler and Paymaster provider. Its Bundler is implemented in Go, passes all EIP 4377 test suite requirements, and is fully open-source and free to use. Stackup Bundler supports different modes:
UserOperationsenter a private mempool, which trades off slower transaction execution for better privacy.
UserOperationwon’t be displayed in a public mempool, thereby avoiding MEV.
Searcher mode: used by Ethereum bot operators (called searchers) and integrates with block builders like Flashbot to send
UserOperationsvia MEV-Boost, which allows searchers to bid bundles of ordered transactions for block builder to include in a block.
Stackup also supports two types of Paymasters:
Verification Paymaster: provides gas abstraction linked to an off-chain process such as fiat ramps. For example, a user can elect to pay gas fee using credit card or a subscription service. Users can define their own logics for gas sponsorship. Stackup will charge users based on a “pay as you go” model.
Deposit Paymaster: allows user to pay gas in ERC20 token.
Figure: Stackup’s infrastructure product suite
Blocknative is primarily a provider of mempool explorer and visualization tools. Consistent with its mempool expertise, Blocknative offers a Bundler service with unique features such as:
UserOperationsmoving through the mempool using a “EIP 4337 UserOps Explorer”
Blocknative’s core product, the mempool explorer, can also monitor for pending and confirmed Bundler transactions going through the Entry Point Contract
Alchemy is currently developing its Bundler and Paymaster services, which are available for early sign ups.
Figure: Alchemy’s EIP 4337 infrastructure service open for early access
eth-infinitism, an official Ethereum Foundation team, provides Bundler and Paymaster implementations. There are little documentations about the team, but they provide one of the two Bundlers (the other one being Stackup) that passed EIP 4337’s official test suites as of February 2023 according to an article by Stackup.
Part 3: What’s the way forward for account abstraction?
1. At the End of the Day, It’s a Game of Adoption, an Incredibly Early One As Well
According to a recent research article by Web3Caff Research, the total number of unique
from address in all Ethereum transaction is ~150 million. However, the total number of smart contract wallets, proxied as the sum of Gnosis Safe and Argent accounts, the two most famous products, is only 150 thousand.
Assuming that there will be an equal number of EOA and smart contract wallet at the end game, we see a 1000x market size potential for smart contract wallets. That said, the path to adoption won’t be a smooth one. Incumbent giants like MetaMask still haven’t announced plans to adopt EIP 4337. While we don’t know their intention, it’s not hard to deduce that profit from mainstream EOA wallets doesn’t justify adopting a new standard whose infrastructures are still budding.
UserOperation** still isn’t a mainstream transaction type used by dApps, though I do foresee that smart contract wallets will grow exponentially due to great user experience improvement.
2. EIP 4337 Still Isn’t Finalized
Although EIP 4337 defined the high level interfaces of infrastructures like Bundler, Paymaster, and Signature Aggregator, there are still adjacent problems not covered by official interfaces and would require implementations to battle test different solutions, such as:
Current Bundler implementations mostly work with private mempools, where
UserOperationBundlers are relayed directly to specific Block Builders. Will public or P2P mempool be possible for the Bundler network?
Can Bundler extract MEV by ordering
UserOperations? Can Block Builders extract MEV by ordering bundles? How will MEV be distributed between Bundler and Block Builders? Should we prefer separating Bundler and Block Builder?
Can Bundlers be reliable Block Builders, given the vast amount of simulation and validation work they need to do?
UserOperationsucceed at validation but fail at execution due to state conflicts with regular transactions? How would
UserOperationand regular transaction mempools coordinate to avoid conflicts?
3. L2s Are at Various Speed of EIP 4337 Adoption
Although zkSync and Starknet are already natively supporting account abstraction, they still haven’t finished implementing all EIP 4337 interfaces and have diverged from Ethereum’s implementation. While many project teams are building smart contract wallets, Bundlers, and Paymasters for Optimism and Arbitrum, these L2s haven’t announced official EIP 4337 integration roadmaps and account abstraction hasn’t been their development focus.
From a purely technical stand point, L2 account abstraction infrastructure can be more complicated to implement. For example, an L2 smart contract wallet will need to estimate and divide both L1 and L2 gas fees among a bundle of
UserOperations during the validation step.
4. Technicalities Aside, What Makes a Great Smart Contract Wallet?
Despite the great number of innovative features (gas abstraction, social recovery, MPC, and etc.), most smart contract wallets support all of the features, because their implementation aren’t technically difficult. Therefore, the business side of smart contract wallets, or wallets in general, matter as much as the user experience side. Important business factors include:
dApps partnership: partnering with the top dApps of each L1 or L2 chain, especially infrastructure-type ones such as stablecoin or DeFi protocols, is a major way to onboard users
Utility features: such as integrated NFT market place, launchpad, or quick integration of new trading pairs
External backing: such as VC or official support from Ethereum Foundation, which can help a wallet find its first batch of users
5. What Makes a Great Bundler Service Provider?
Permissionless and modular Bundler service is a public good. It’s non-excludable and non-rivalrous due to its open source nature. Any RPC end point can run the service by forking an implementation. Even if the RPC end point charges service usage using an API key, it’s harder to run a Bundler service as profitably as other infrastructures such as Paymaster, which can easily charge a fee spread by partnering with a third party fiat ramp or DeFi protocol provider. However, Bundler is an important public good that diversifies Ethereum’s
UserOperation transaction entry points. Because Stackup and eth-infinitism are the only two functional third party non-wallet Bundler service providers, we definitely need more of them.
There are many technical barriers a Bundler service provider needs to overcome:
Heavy research on multiple off chain and on chain validation steps, to make sure a
UserOperationcan get executed. One difficulty is understanding the potential state conflicts among multiple
Understanding OpCode bans:
Because reading changing external states can cause successful validation but failed execution, some OpCodes that read external contexts are banned by EIP 4337.
Different L2s can implement slightly different bans, which is hard to navigate through.
Bundler builder needs to call the
traceCallfunction to get the OpCodes that are called by each function. However, most third party RPC end points don’t support
traceCall. Therefore, Bundler builders might need to set up their own nodes, a technically intensive step.
Most Bundler services are focusing on L2, which requires the difficult step of estimating gas fee on both L1 and L2.
Implementing a P2P gossiping network for private and public mempools. The private mempool requires customization for searchers and dApps, such as whitelisting. The public
UserOperationmempool standard is still not completed.
What are the differentiating factors for Bundler service providers:
Is the service built specifically for a wallet or by a pure play infrastructure provider
Bundler is only one out of many things a wallet provider needs to build, so they are more likely to focus on building a minimal viable Bundler that’s only used by the wallet.
Pure play infrastructure providers need to focus on building permissionless and modular Bundlers that provide stellar service in all contexts.
Similar to Ethereum nodes, Bundler services are implemented in different languages, and Bundler diversity is good for the ecosystem by preventing single points of failure.
Support for private and public mempools and level of customization allowed for private mempool.
Support for L1 and L2 chains, each with slightly different interface implementation requirements.
6. Let’s Talk About Innovation
This session will list the most needed innovations in smart contract wallet and account abstraction infrastructure.
Permissionless and Modular EIP 4337 Infrastructure
To picture the end game of EIP 4337 infrastructure:
Many providers of Bundlers, Paymaster, and Signature Aggregators compete for the lowest fees in an open market
There will be a mixture of publicly exposed Bundler, Paymaster, and Signature Aggregators end points, as well as specialized ones deployed just for a single smart contract wallet or dApp
Smart contract wallets, dApps, and individual users can deploy these infrastructures in a permissionless, modular, and user friendly way, i.e. there will be infrastructure providers that allow easy and customizable deployment of Bundler, Paymaster, and Signature Aggregator from arbitrary addresses
At the current market state, many smart contract wallets have already built out their own infrastructures that are not designed for third party use. Pure play infrastructure providers such as Stackup are working on modular Bundlers and Paymasters. However, the deployment process is still far from permissionless. With EIP 4337 still in the shift, the modular features of these infrastructures are not fully defined yet. Besides, given the low volume of
UserOperation transactions, Signature Aggregator enabled wallets such as BLS Wallet are still not the mainstream.
Adjacent EIP 4337 Infrastructures
These include infrastructures not defined in EIP 4337 but are required by EIP 4337 infrastructures: for example, fiat ramp aggregators and DeFi aggregators that can be integrated to Paymasters. Because these solutions already exist, innovations will most likely happen within existing providers, by simply redefining their exposed end points.
dApp SDKs and Scaffolding
While existing smart contract wallets all built out their own client SDKs for dApp integration, there still lacks:
Standard libraries such as ether.js for dApp development, except that account abstraction features are also enabled. For example:
Wallet creation and social recovery using Web2 social media account and email
Creating, signing, sending, as well as the event handling of
Quick deployment of Paymaster and Signature Aggregator
SDKs and UI tools that aggregate all major smart contract wallets
Scaffolding tools for quick front end deployment, so that dApp developers can focus on the business logics of their products
Templates for new types of dApps empowered by account abstraction, such as gas abstracted free-to-play games
Something More Radical: Decoupling Account from Smart Contract Wallet
EIP 4337’s smart contract wallet interface only requires a
validateOp function, leaving all core logics, such as user registration, access control, and social recovery, to the wallet developer’s free will. While this grants more flexibility, different smart contract wallets can become walled gardens where one can’t easily port data from one to the other. dApps could also exacerbate this division by supporting some smart contract wallets but not others.
Besides, although users can log in smart contract wallets using familiar Web2 flow using credentials like their email, they still need to go through unfamiliar user flow like “connect wallet” to log in dApps.
One radical solution to these problems is to decouple user’s account from smart contract wallet, by creating a new account standard, such as EIP 6662 advocated by Hexlink. EIP 6662 defines an
IAccountMetadata interface, where users can customize their own authentication methods, thereby moving authentication from wallet contract logics to a separate account interface. Smart contract wallets supporting this interface can allow users to easily port their account data to another wallet. dApps supporting this interface can allow users to log in their Web3 account using Web2 credentials defined in the account layer. dApp can verify a signature from a Web2 credential, look up the Web3 account address, push a notification to the account, and get connected to the Web3 account. Users don’t need to create different wallets for different dApps. Rather, dApps are automatically connected to users’ Web3 accounts linked to their Web2 credentials. Users are no longer tied to wallets. Rather, wallets become essentially dApps that users can log in for their asset management functionalities.
EIP 4337 standardizes smart contract wallets and their related infrastructures into six standardized interfaces: the smart contract wallet itself, Bundler, Entry Point Contract, Paymaster, Wallet Factory, and Signature Aggregator.
UserOperationis the new transaction type supported by EIP 4337.
There are two types of players in the account abstraction market:
Smart contract wallets with features including social login, social recovery, gas abstraction, transaction batching, as well as integration and aggregation of third party services such as fiat ramps and DeFi protocols.
Pure play providers of infrastructures such as Bundler and Paymaster, focused on modular design.
Given similar features offered and low technical barrier, smart contract wallet is a very competitive market. Bundlers are hard-to-profit but important public goods that we need more of to diversify the execution of
UserOperation. With adoption still very low, EIP 4337 incomplete, and many L2s yet to announce any integration plans, account abstraction is still an early market, with many needed innovations such as: permissionless and modular infrastructures, integration with existing fiat and DeFi services, dApp SDKs, and a potential separate account layer.