Estimated time: 7 minutes read

The main infrastructure providers for ERC-4337 account abstraction on EVM-compatible networks are analyzed, including smart account wallets, bundlers, and paymasters, enabling the integration of these technologies into DApps with scalable and cost-effective solutions.

What Is an Account Abstraction Infrastructure Provider?

The account abstraction standard, ERC-4337, defines the protocol and core building blocks to implement account abstraction mechanisms on EVM-compatible blockchain networks.

While it is an open standard that any developer can adopt, in practice, integrating account abstraction into a DApp is more convenient through the features offered by infrastructure providers.

An account abstraction infrastructure provider is usually a company contributing to the evolution of the technology, often participating in various Web3 working groups involved in the development and implementation of the standard.

You can find providers across all functional components defined in the ERC-4337 standard, from Smart Account factory developers to bundlers and paymasters.

These two platforms are excellent resources to explore the main players, monitor adoption trends, and track usage over time:

For more details on this technology, feel free to check out my article on account abstraction in EVM-compatible networks.

Smart Account Factory Providers

In the ERC-4337 ecosystem, the smart account is the contract that executes the transaction on-chain, acting as the user’s wallet while also implementing the additional logic that improves the user experience through account abstraction.

There is a wide range of Smart Account providers. Since the release of the reference implementation of the SimpleSmartAccount, many new versions have emerged with varying levels of maturity and features.

Criteria for choosing a particular implementation may include:

  1. Adoption rate: Number of deployed accounts across different blockchains. This metric can fluctuate: the popularity of a high-traffic DApp may significantly impact market share. As user adoption of account abstraction grows, these numbers may offer more stable insights over time.
  2. Gas efficiency: A complex metric that ideally should be benchmarked in the context of the smart contracts of the project in which the account abstraction is being integrated. As an example, check an earlier study that compared leading Smart Account implementations based on operations such as native token transfers, ERC-20 transfers, and DEX-like token swaps.
  3. Supported Entrypoint version: The latest version is 0.8, though not all Smart Account factories support it.
  4. Support for modularization standards such as EIP-7579 or EIP-6900.
  5. Additional features: Such as social recovery, passkey login, multi-signature support, etc.
  6. Security audits: Audits that ensure the factory smart contract is secure and reliable.

Bundler Service Providers

Bundlers collect user operations from an alternative mempool and submit them to the EntryPoint contract.

From the many available options, we’ll focus on providers offering public endpoints with no dependency on proprietary SDKs, and pricing plans favorable for early-stage development.

In general, using a bundler involves two standard RPC API calls:

  1. eth_estimateUserOperationGas to estimate gas costs.
  2. eth_sendUserOperation to send the UserOperation to the mempool.

Other alternatives exist but are excluded here due to higher costs or requiring proprietary SDK installation.

For example, this compatibility list shows which bundlers support which Entrypoint versions.

Etherspot

The bundler is called Skandha, supporting Entrypoint versions 0.6 and 0.7, and a beta for 0.8. Both a public permissionless version and a private setup are available.

API access is configured through the user dashboard, where multiple API keys can be defined to restrict usage per environment.

The pricing plan starts at $49/month for 20M monthly credits, with credit costs per operation listed here.

Initial tests can be performed on testnets with the free plan, at no cost.

Thirdweb

Thirdweb offers a bundler compatible with Entrypoint versions 0.6 and 0.7. API keys are configured from the user dashboard, with flexible security settings.

Its pricing plan is very accessible: $5/month for 3M requests across endpoints. Bundler usage itself incurs no extra cost beyond the gas fees of the transaction.

A free account is available for use on testnets.

Biconomy

One of the first infrastructures to support Entrypoint 0.7, using Nexus, its own Smart Account factory.

The bundler exposes standard methods through its public endpoint. API keys can be obtained via the user dashboard.

Biconomy offers the most advantageous pricing: no fixed monthly fees or request limits. Bundler usage is paid only via the transaction’s gas fees.

Paymaster Service Providers

A paymaster is a smart contract that, among other things, allows covering a user’s gas fees. This section focuses on that specific feature.

We analyze the same three providers as above since they support standard ERC-7677 RPC methods:

  1. pm_getPaymasterStubData: Returns gas estimates needed to then invoke eth_estimateUserOperationGas.
  2. pm_getPaymasterData: Returns paymaster values to include in a signed UserOperation.

In most cases, it is possible to mix bundlers and paymasters from different providers, offering vendor flexibility.

Etherspot

The paymaster is Arka, sharing the same compatibility (EntryPoint versions 0.6, 0.7, and beta 0.8) and pricing plan as its paired bundler.

Each API key must be associated with a sponsorship policy in the user dashboard. This policy can disable the paymaster entirely, choose the supported Entrypoint version and select which blockchains are allowed.

To activate the paymaster, native tokens must be transferred to the sponsor address defined in the dashboard. These funds are used to deploy and fund the paymaster smart contract for gas sponsorships.

Security-wise, a list of allowed sender addresses can be defined per paymaster.

Thirdweb

Same pricing plan as the paired bundler.

The sponsorship policy configuration includes:

  • Max USD amount to sponsor per month.
  • Restricting smart contracts eligible for sponsorship.
  • Allow/block specific sender addresses.
  • External webhook integration to allow/deny sponsorships in real time

There is a 10% surcharge over the gas cost when using the paymaster.

Total sponsored volume (plus 10%) is billed monthly using the billing info set up in the user dashboard, mandatory for mainnet usage.

Biconomy

The paymaster is created and configured from the user dashboard. The compatible Entrypoint version and blockchain must be choosen. After that, connect a wallet to deposit native tokens for sponsorship is mandatory.

Security options include:

  • Setting global or per-sender sponsorship limits.
  • Restricting sponsorship to specific smart contracts or methods.
  • Adding external webhook controls.

Again, Biconomy offers the most cost-effective option: no API usage fees or gas surcharges.

Conclusion: Enabling Account Abstraction Integration

Account abstraction is a key innovation driving broader DApp adoption. However, integrating ERC-4337 functionality remains a non-trivial task.

Previous articles in this series have covered topics such as user wallet connection, the account abstraction model, and gas sponsorship, all aimed at improving the Web3 user experience.

This final article explores some of the leading players in the Web3 ecosystem enabling developers to test and implement Smart Account Wallets, bundlers, and paymasters, the three pillars of account abstraction, at a reasonable cost.

Since the standard is evolving rapidly (Entrypoint v0.8 was just launched as of writing), some information here may become outdated. However, the core ideas will likely remain relevant and useful for other developers adopting account abstraction.


Have you integrated account abstraction into your DApps? Do you use any providers not mentioned in this article? What criteria guide your selection among the many available options?

If you’d like advice on this or other blockchain development topics, feel free to reach out and explore ways we can collaborate. Thanks for reading!