Onboarding the Next Billion Web3 Users — A Deep Dive into the Technicalities and Applications of Account Abstraction and EIP 4337

Author: Steve Wang, current student @UPenn Wharton, frontend and smart contract developer, prev. @Foresight Ventures

Twitter: @SteveIsEmployed


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.

1. UserOperation

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 UserOperation

  • 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.

Figure: UserOperation parameter definition by official EIP 4337 doc

2. Bundler

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 UserOperation

  • 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 UserOperation.

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 handleOp function, which takes a UserOperation input. handleop is responsible for validating and executing a smart contract wallet function according to the calldata of the UserOperation

    • handleOp first validates the UserOperation on 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, handleOp executes the smart contract wallet function according to the function’s signature and inputs defined in the calldata of UserOperation

  • 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 handleOp function 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

    • A UserOperation without enough gas held by its destination smart contract wallet won’t pass the validation step, thereby failing before execution

    • Even with enough gas, a UserOperation can 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 handleOp function

    • 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 UserOperation:

  • Validation is defined in the validateOp function. It’s called twice: once off chain by the Bundler to validate the signature of the UserOperation and gas balance of the smart contract wallet as a simulation; then again on chain by the Entry Point Contract to validate the UserOperation before execution

  • Execution is defined in the calldata of 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.

5. Paymaster

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 UserOperation using arbitrary logic defined an exposed validatePaymasterOp function that the Bundler triggers

  • Paymaster is required to deposit ETH on the Entry Point Contract to pay gas for UserOperation

  • 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. validatePaymasterOp is called before a UserOperation is 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. postOp double 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 UserOperation with initCode filled

  • 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 CREATE2 function, 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 UserOperations and returns an aggregated signature using a specific scheme

  • validateSignatures: takes an array of UserOperations and 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 UserOperations.

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 UserOperation to Bundler

  • If UserOperation contains an initCode field, Bundler triggers Wallet Factory (through the Entry Point Contract) to create a new wallet deterministically

  • If UserOperation contains a paymasterAndData field, 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 UserOperation off chain using a combination of validateOp, validatePaymasterOp, or validateSignatures functions

  • If off chain simulation passes, Bundler validates UserOperation on chain using a combination of the functions above

  • If on chain validation passes, Bundler executes UserOperation on 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

Because 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 validateOp, validatePaymasterOp, and validateSignatures functions.

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 UserOperations

  • 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 upgrade function.

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 validate and execution functions. validate is required, so that only account owners can initiate transactions and that transaction executors are guaranteed gas payments. Users can implement arbitrary logics in validate and execute functions for full flexibility of their account. For example, different signature schemes can be implemented in the validate function.

  • Starknet restricts validate from 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 UserOperation transactions, 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_account transaction in order to create a new contract account. In EIP 4337, contract account is deployed by executing a UserOperation transaction with the initCode field 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 validateTransaction and executeTransaction functions.

  • The Paymaster interface includes validateAndPayForPaymasterTransaction and postOp functions. 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 paymaster address field and the paymasterInput field, similar to EIP 4337’s UserOperation.

There are notable implementation differences, however:

  • In 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

  • validateTransaction is 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:

  • Private mode: UserOperations enter a private mempool, which trades off slower transaction execution for better privacy. UserOperation won’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 UserOperations via 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:

  • Visualize UserOperations moving 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 UserOperation Bundlers 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?

  • Will UserOperation succeed at validation but fail at execution due to state conflicts with regular transactions? How would UserOperation and 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 UserOperation can get executed. One difficulty is understanding the potential state conflicts among multiple UserOperations.

  • 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 traceCall function 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 UserOperation mempool 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 UserOperations

    • 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. UserOperation is 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.


Image credit to Wealth Nation
Image credit to Wealth Nation
Subscribe to SteveIsEmployed
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
This entry has been permanently stored onchain and signed by its creator.