Account Abstraction Landscape

In this article we are going to dive deeper into the ecosystem being built on top of the AA, analyzing products for developers that solve complex problems in that area.

Account Abstraction is a paradigm shift in blockchain that proposes a unified account model, blending the capabilities of externally owned accounts (EOAs) with the versatility of smart contracts. It opens a simplification window for those who are not deeply familiar with the blockchain (and they don’t need to now) and a flexibility door for the developers.

Why AA is a game-changer?

• Web2 UX is now available in Web3. 2FA, login & account recovery via email, social media accounts, phone, biometrics, etc. There is no need to write 12 words on a piece of paper your mom can accidentally throw away while cleaning the desktop. Everything we are used to but with the security and decentralization of Web3.
• Gasless experience. Paymaster functionality enables dApps to cover the gas fees for its customers based on any rules that can be coded. There’s also no more pain for blockchain newbies getting the native currency for their first transaction. Gas can be fully covered or paid in ERC-20 tokens.
• Transaction batching offers the ability to perform several operations within one transaction (e.g., approve() and transferFrom()). This leads to reduced transaction costs and network efficiency improvement.
• Custom wallet logic. Subscriptions, spending limitations, multisignatures, and many other options can be a part of the smart account.
• Post-quantum signatures can now be used for the verification of transactions.

This and many other advantages show us that AA adopts a transformational approach, combining the ease of use and familiarity of traditional web applications with the revolutionary aspects of blockchain technology. It addresses some of the key issues around blockchain usability and accessibility, and lays the foundation for wider adoption and innovative applications in the blockchain space.

ERC-4337

The heart of the AA concept is ERC-4337. This proposal completely avoids the need for consensus-layer protocol changes via Entry Point Contract specification and Alt Mempool. If you are not familiar with a mechanism that makes the magic behind ERC-4337 happen, the 4-part technical article from Alchemy or Vitalik Buterin’s Medium post is recommended.

Let’s refresh on the main principle behind the AA specification. ERC-4337 doesn’t modify the consensus layer thanks to combining on-chain and off-chain operations.

All the bricks we will talk about below are glued together with the help of UserOps. They are like usual transactions but with a slightly different structure. Users package up the action they want their account to take in a struct named UserOperation which is further sent to the Alt Mempool before being added to the blockchain.

Off-chain part is represented by 2 main entities:

• Bundlers play the role of aggregators and executors. They collect UserOps submitted by users into the Alt Mempool and bundle them into a single transaction. This aggregation is critical to efficiency, reduced gas costs, and optimized network throughput. After the bundling, they execute the transaction acting like a proxy EOA account.
• Alt Mempool is similar to Ethereum’s main Mempool. This is a separate holding area for UserOps waiting to be incorporated into the blockchain. Managed by a bundler, it acts as a buffer zone, smoothing the flow of operations to EntryPoint contracts.

On-chain part consists of 5 main contracts:

• EntryPoint contract plays the role of the coordinator. It serves as the universal receiver of all user operations (UserOps) and is responsible for their validation and execution. The contract standardizes the way operations are handled and ensures consistency and reliability across different implementations.
• Smart Account (Wallet) contract is a place where your wallet is programmed in any convenient way. This is a core business logic component.
• Account Factory contract is needed to deploy the specific wallet contracts. It’s important to mention that the smart account address is not random, it is determined using the CREATE2 opcode which can be extremely useful for multi-chain support.
• Paymaster contract is optional and can pay for the transaction, instead of the sender, thereby expanding accessibility and facilitating user onboarding. Thanks to that users don’t have to care where to get native currency in the first place.
• Aggregator contract is also optional and is used for signature aggregation. It significantly improves efficiency and saves a lot of gas by introducing the ability to validate many ops at the same time with just one signature instead of many.

The workflow of the AA as an orchestra of all the components mentioned above is perfectly summarised in this diagram from Alchemy:

ERC-4337 transaction flow

Modularity in Smart Accounts

Though ERC-4337 is quite detailed and proposes a great standardized solution there’s always some space for improvement left. One of the most important components missed is flexible modularity. ERC-6900 is the first proposal focused on the AA modularity, developed by Alchemy in April 2023.

As an alternative, there’s also ERC-7579 which aims to standardize the same thing but in a less opinionated way, offering developers more room for experimentation (you can read about the reasons why ERC-7579 was created as a new standard instead of sticking to ERC-6900 here. It was proposed by Rhinestone, Biconomy, ZeroDev, and OKX in December 2023. Recently Etherspot has also been added to the “Supported by” list.

Both of them introduce a standard way to broaden the functionality of the smart account while maintaining things modular. It is possible due to the plugins/modules system that gets especially handy for verification and execution.

As an addition to ERC-7579, you can also find ERC-7484 useful. It standardizes the interface and functionality of Module Registries, allowing modular smart accounts to verify the security of modules using a Registry Adapter. In other words, Module Registries are needed to keep audited and trusted ERC-7579 modules in one place.

Cornerstone of the AA implementation

The Infinitism team shared a repository with the standard implementation of the AA contracts relied upon by most solutions (from SDKs to brand wallets) in this area. It includes core contracts, all the needed interfaces, and some samples for reference.

Landscape

The market of Account Abstraction solutions is full of different projects that offer a lot of similar utilities and it’s easy to get lost among all of them looking for the product that suits your needs the best. Here is the landscape relevant for April 2024.

Even though after some investigation the account abstraction concept may seem clear, things become more complicated once you dive deeper into the AA landscape and see how diverse it is. Every solution is a brick in a huge building that is still under construction. One product uses others, and different utilities are linked together more than it may seem at first glance.

All of the products are unique in some way but almost all of them include key features that bring a new web3 milestone closer:

• social logins & account recovery
• transaction batching
• custom validation logic
• multisigs
• gas abstraction

Taking into consideration the fact that the AA is still fairly new and the market is constantly evolving we will take a closer technical look at the most mature solutions that include most of the functionality needed for bringing the idea of account abstraction to life. Let’s see what the market can offer us.

1. Full-stack Solutions

The development process is extremely important to make the decentralized Internet a more user-friendly place. There’s a great bunch of SDKs & APIs for wallet creation and interaction, Bundlers, Paymasters, and Auth Providers as services created to make the life of developers easy and let them fully concentrate on the new ideas of how to improve the AA ecosystem rather than reinventing the wheel.

Some of these solutions are the whales in the world of dev toolkits that capture the entire development cycle including ERC-4337 wallet operations and providing services like bundlers and paymasters. All in one place.

1.1 Biconomy

The Biconomy SDK is an Account Abstraction toolkit built with TypeScript on top of ERC-4337. It relies on a modular architecture according to the ERC-7579.

Biconomy Account Abstraction SDC structure

From the above scheme, we can see that the Modular Smart Contract Wallet (ERC 4337-compliant signer agnostic contract) can be enriched with the functionality from the programmable modules (those provided by the Biconomy or custom ones).

Modules are divided into 2 categories: Validation Modules and Execution Modules.

Biconomy provides such validation modules:

• ECDSA Ownership Module: This is the default module that relies on an EOA to sign and verify messages. It can seamlessly integrate with MPC providers such as Web3Auth, abstracting EOA private key storage and enabling a web2-like experience such as email login. If the module is used the Smart Account’s address is generated based on the signer’s public key, which is the owner’s address used in the ECDSA Module. This module is EIP-1271 Compliant.
• Multichain ECDSA Validator Module: This module significantly improves UX for deploying and setting up Smart Accounts on several chains. It is an extension of the ECDSA Module enabling to dispatch multiple UserOps on different chains using a single signature. It is possible since the user signs the Merkle Root (of a tree where every UserOpHash is a leaf) instead of signing individual hashes. This way, signed Merkle Root serves as on-chain evidence, proving any UserOp within the tree is authorized.
• Session key Manager Validation Module: This module enables the use of sessions to execute transactions. It verifies whether a given user operation adheres to the permissions defined within the session key and confirms that the operation has been signed by that session key. The smart contract is designed in a way that session key data has a specific layout including permissions and additional data. Those permissions are further verified by the Session Key module. After the successful verification, the module validates that the provided signature matches the session key using ECDSA.
• Batched Session Validation Module allows batching of several session key signed operations which should be validated by different Session Key Manager Validation modules into one User Operation and execute them atomically. From the smart account point of view, every operation in the batch is expected to be an action managed by a specific Session Validation Module. SmartAccount.executeBatch() method is used to execute atomic operations: calldata from this method is parsed and routed to be validated to the specific SVMs based on the actions in the batch.
• MultiOwnedECDSAModule: This is an alteration of the ECDSA Module which allows multiple signers to be set up, and any one of the enabled owners can authorize a transaction using the ECDSA signature.
• Custom Validation Module can be developed by anyone and must extend the abstract contract BaseAuthorizationModule. It ensures your custom validation module operates securely and efficiently.

Biconomy Smart Accounts are flexible in allowing you to use any signer from an EIP-1193 provider, (or simply an ethers signer) to create a Smart Account. It supports such Auth providers as Dynamic, Particle Network, Privy, Magic, DFNS, Capsule, Turnkey, and Web3Auth.

In terms of infrastructure, Biconomy is also widely useful because of its Paymaster-as-a-service (Sponsorship Paymaster & Token Paymaster are available) and Bundler-as-a-service. The Biconomy dashboard is your gateway to accessing those services. Additionally, this is where you can top up and configure your Paymasters for sponsoring transactions. This is how the majority of similar solutions work — via dashboard and API keys.

We can’t also pass by the fact that on top of all the blockchain experience, Biconomy offers the ability to integrate with fiat On-Ramp & Off-Ramp service providers and aggregators. One of the easiest examples is Transak. Biconomy SDK’s Transak library is made for developers who just want on-ramp solutions and don’t want to go through with all the steps to integrate the SDK.

1.2 ZeroDev

ZeroDev is one of the most used solutions providing AA SDK and meta infrastructure.

It is built on top of their own smart account — Kernel. Like most other SDKs ZeroDev is modular but unlike Safe{Core} the moduleness is standardized in ERC-7579 (same as in Biconomy). This allows expanding the Kernel with the help of plugins. Here is the list of plugins introduced:

• Passkeys are supported as signers in 2 ways. The first one is native passkeys using the ERC-7212 precompile. Though it is the best option due to its gas efficiency, a small number of chains currently support it. That is why if ERC-7212 is unavailable ZeroDev automatically falls back to smart contract passkeys using either the Daimo or FCL implementation. This option is much more expensive but for sure works on all EVM networks. The trade-off here is that in order to use passkeys you need to use the passkey server. It can be ZeroDev’s one or for the sake of decentralization your own one. This server stores only public information, users’ keys are stored on their devices only.
• ECDSA validator validates signatures produced with an ECDSA private key, providing an experience similar to usual EOAs.
• Weighted ECDSA. While the ECDSA plugin allows users to create multiple accounts from the same EOA signer using an index, Weighted ECDSA is used to associate multiple signers with the Kernel account, each having a different weight. Enabling it can be useful in case you want your account to be multisig or setting up guardians for the account.
• Session keys. There are 2 patterns in the session key creation available: owner-created and agent-created. But what are those entities? The owner is someone who controls the master key of the account, this person is able to create session keys. The agent is whoever using the session key. So, in the first approach, the owner just creates the session key and shares it with the agent. In the case of agent-created session keys, the agent creates a public-private key pair and shares the public key with the owner. The owner authorizes the public key (by signing it), and shares the signed data with the agent. Finally, the agent creates the full session key by combining the signed data with the private key. This pattern is powerful because the agent never had to share the private part of the session key with anyone.
• The Recovery plugin is just a special case of the guardian plugin (which is itself a special case of the Weighted ECDSA plugin).

In terms of signers, ZeroDev is compatible with EOA signers and many different third-party “wallet services” like Dynamic, Privy, Portal, JoyID, etc.

Things become a little unusual when we come closer to the infrastructure provided by ZeroDev. It works with major AA infra providers to deliver a “meta infrastructure.” In other words, traffic is proxied to the bundlers and paymasters of the supported infra providers (Alchemy, Gelato, Pimlico, StackUp). The idea of meta infra makes bundler access more reliable by working with multiple bundler providers. If one fails, another takes over.

Or you can use your own infrastructure.

1.3 Alchemy Account Kit

Account Kit is a toolkit to build embedded accounts with AA. According to the Alchemy account gas benchmarks the Account Kit appears to be the most gas-efficient among similar solutions including Biconomy, Kernel, and Safe.

Let’s take a look at the tools available:

• AA SDK is a TypeScript library built on top of viem and fully compatible with ethers.js. It is responsible for embedded account integration into your app and orchestrating all the processes.
• Signer API. Embedded Accounts are powered by the non-custodial Alchemy Signer API which uses Turnkey to securely store key material in a Secure Enclave so that only the user can access it. Alchemy signer is a nice option for a quick start because all you need is an Alchemy API key. Along with that Account Kit is compatible with any EIP-1193 provider.
• Smart Contract Accounts are the core of the toolkit. You can use your own ERC-4337 account, or utilize out-of-the-box Alchemy solutions. There are 2 types of accounts in the Account Kit: light one and modular one. A light account is simply an ERC-4337 SimpleAccount from Infinitism with some key improvements added (namespaced storage usage to avoid clashes when switching implementations, some event renaming, and use of custom errors). It is ERC-1271 compliant and in addition, supports ownership transfer and transaction batching. A modular account can be thought of as an extension of a light account that can be customized with ERC-6900 plugins. Modular Account uses the UUPSUpgradeable proxy pattern, and plugins are singleton contracts. This is how all this is structured:

• Gas Manager API is responsible for sponsoring gas for UserOps. Programmable gas policies can be created to specify exactly which transactions should be sponsored, set strict spending limits per wallet or globally, and allow/blocklist particular wallet addresses.
• Bundler API. Alchemy has developed an efficient Rundler — bundler written in Rust. Rundler is implemented in a modular manner, allowing its components to be run as a single integrated binary, or as a distributed system.

For now, modular Smart Accounts are introduced with 2 plugins:

• Multi Owner Plugin supports one or more EOA accounts or ERC-1271 compliant contracts as owners of the account.
• Session Key Plugin supports the following types of permissions for each key: time range, access control lists, pending limits for ERC-20 token, native token, and gas. Also, key rotation is possible.

As an additional useful feature Account Kit provides React Hooks to interact with your Smart Contract Accounts.

Aside from the Account Kit Alchemy has some enhanced APIs, and Alchemy Smart Account can be used with 2 of them: NFT API and Token API. They are useful for querying NFT and token info related to the account.

1.4 Particle Network

Particle Network is focused on creating the modular L1 chain abstraction, and wallet abstraction along with liquidity and gas abstractions is a part of this huge plan. There are several products implemented, but what interests us the most is their Modular Smart Wallet-as-a-service.

From the scheme, we can see how the Particle Network implements Account Abstraction:

• Smart Account. Currently, there’s built-in support for Biconomy Account, Cyber Account, Alchemy Light Account, and Simple Account wallet implementations but using any other ERC-4337 smart account is also available. All of them support tx batching, session keys, and the use of verifying or ERC-20 paymaster.
• Key Management is represented by another Particle product — Particle Auth. It is a self-custodial auth infra for Web3 apps and wallets powered by SDKs for different platforms. Particle Auth enables users to log in through Google, Apple ID, Facebook, Twitter and other social methods, and can also log in with Email / Mobile number without a password. Under the hood, a crypto wallet without a private key is created for such logins. An associated wallet is secured with MPC (Multi-Party Computation)-based TSS (Threshold Signatures Scheme). Along with Web2 methods, different Ethereum and Solana wallets are supported.
• Embedded AA Wallet is an infrastructure plugged into apps or wallets (important not to think of it as of independent wallet). It also has integrated multiple On-Ramp vendors to allow users to purchase cryptocurrency directly with fiat currency, exchanges, DeFi protocols, wallets, and Web3 services.
• Infrastructure is represented by bundler and paymaster services. An innovative moment here is that Particle Network has implemented a Paymaster (Omnichain Paymaster) service that supports multiple chains. For now, you just need to recharge USDT either on Ethereum Mainnet or BNB Chain to use the Paymaster service on any chain, all the needed conversions are done automatically in the background.

After analyzing the implementation of all key aspects that make ERC-4337 so attractive, it’s finally time to move on to the most exciting part the company has introduced — BTC Connect.

BTC Connect is the first account abstraction protocol in the BTC ecosystem. It implements ERC-4337 on EVM-compatible Bitcoin Layer-2s to assign smart accounts directly to native Bitcoin wallets.

A Bitcoin wallet and a smart account on a Bitcoin EVM-compatible L2 can be linked together thanks to the usage of ECDSA (sepc256k1) for signature generation. To make things sound simpler, we can understand the basic flow in such a way: a user enters the system for the first time -> user connects a BTC native wallet, such as UniSat, OKX, TokenPocket, or Bitget (through a modal that aggregates mainstream BTC wallets) -> BTC Connect generates and assigns a smart account to a Bitcoin wallet (through the computation of an EVM EOA address based on the Bitcoin wallet’s public key) -> user can now send UserOps signing them with signatures generated directly by the Bitcoin wallet. You can find more technical details on the BTC Connect here.

To summarize, Particle Network has plenty of products useful in the AA ecosystem and all of them (Embedded Wallet, Particle Auth, Account Abstraction, BTC Connect, etc) can be used together (like they already do as some use others) or as separate products for your dApp.

Conclusion

The most popular combination of tools in the full stack solutions is SDK + Infrastructure (bundlers and ERC20 & verifying/sponsoring paymasters).

Some deliver their own smart account contract implementations as a core like Biconomy, ZeroDev, Thirdwev, etc, while still supporting other ERC-4337 accounts. The majority of the accounts are built to be modular for easy plugin integration. Those are, for example, Biconomy and ZeroDev adapted to ERC-7579 plugins, and Alchemy Account Kit with ERC-6900 modules.

In terms of auth, most of the products use other third-party auth vendors but there are those that propose such signing solutions themselves like Particle Network and Sequence.

You can use any of those solutions for general purposes, but there are specific cases when some products are better. For instance, if you are developing a web3 game Sequence and Blockus are the best option because they are game-oriented. In case you are planning to use AA on Bitcoin, Particle Network is currently your only choice.

2. SDKs and APIs

There’s a great bunch of wallet SDKs and APIs created to make the development easier. Most of the operations take only a few lines of code with the help of all these tools.

2.1 Safe{Core}

Safe{Core} is a modular account abstraction stack that provides AA tooling. It consists of 3 parts: SDK, API and Safe Smart Account.

Safe{Core} SDK can be categorized into 5 distinct function kits:

• Protocol Kit is a way to interact with the Safe Smart Account contracts including Safe accounts creation and configuration, signing, batching and executing transactions etc. Basically, it’s just a TypeScript interface for the AA contracts.
• Auth Kit enables creating EOAs and authenticates them based on an email address, a social media account, or a crypto wallet like Metamask. The authentication system behind the Auth Kit utilizes the Web3Auth MPC technology.
• Relay Kit: simply an interface to use ERC-20 paymaster powered by Gelato relay.
• Onramp Kit helps users buy cryptocurrencies with fiat money to fund a Safe account via a credit card or other payment methods. This is possible thanks to the integration with Stripe Pack for cryptocurrency purchases and Monerium Pack to make direct transfers of e-money tokens from their Safe accounts to an IBAN via the SEPA network.
• API Kit is used for interaction with the Safe Transaction Service API.

Safe{Core} API is needed to provide all Safe account-related information to interfaces and is represented by 4 services: Transaction Service, Events Service, Config Service, Client Gateway.

In general, Safe’s production setup is a mixture of several instances of the Safe Transaction Service orchestrated by the Config Service, later consumed by the Client Gateway. A simple example of its basic usage is sending a transaction as a 2 of 3 multi-sig account: the transaction is formed and signed off-chain -> signed transaction is submitted to the Safe Transaction Service which is being listened to by other signers -> second signer gets the tx from the service, signs it and submits the signed tx back to the service -> finally tx is executed.

Safe Smart Account is the core used in all smart contract-based wallets. Basically, this is a modular account framework. By default, it uses a multi-sig approach and proxy pattern.

Safe Smart Account can be extended with Safe Modules. It can also be used together with Transaction Guards. We can think of them as hooks that can make checks before and after a Safe transaction. A simple example is AllowListGuard.

The last but not least thing utilized by Safe Smart Account is Fallback Handlers. They allow to add extra functions to the core contracts. It can be useful in case a new standard is introduced that is not natively supported in the account. Then the required functions can be implemented in the fallback handler that is further plugged into the account.

As you can see the main feature — Safe Modules — is not that easy to find as they are not gathered in one place. Moreover, other issues not fully solved by usual Safe modular smart accounts are interoperability and security. But Safe{Core} Protocol is about to fix this. At the moment of creating this AA landscape the Protocol repositories are marked as “not actively developed at the moment” and seem not to be ready for production use, but the standardized solution provided within this protocol is still worth mentioning.

Safe{Core} Protocol Architecture with examples

As you can see from the scheme Safe Manager is introduced, which aims to get rid of the direct connection between the account and 3 pluggable components mentioned before (Modules, Transaction Guards, and Fallback Handlers). This Manager would have access to the registry where all the verified modules are listed, and allow the communications between accounts and those modules. Modules here are divided into categories with names that speak for themselves.

In general, this approach is similar to what ERC-7579 (Minimal Modular Smart Accounts) and ERC-7484 (Registry Extension for ERC-7579) propose. But they are not supported by Safe{Core} Protocol and are implemented in a bit another way. Though the Fallback Manager inside the Reference Implementation of ERC-7579 is stated to be inspired by the Safe Fallback Manager.

2.2 Rhinestone

Rhinestone delivers a set of tools oriented toward building smart account modules on top of any compatible smart account vendor. Rhinestone is one of the ERC-7579 (a modularity proposal) authors, so logically, account implementations supported are those compatible with ERC-7579: Biconomy and ZeroDev. Currently, the Rhinestone team is also working on the Safe accounts support.

ModuleKit is a development kit that allows you to build, test, and deploy the ERC-7579 modules. It consists of:

• Module templates and standardized interfaces. Module types are validators, executors, hooks, and fallbacks (similar to Safe{Core} types).
• 3rd party integrations: library of integrations and pre-built conditions, e.g., for Uniswap, Aave, Chainlink, Compound, dYdX, etc.
• Testing frameworks with built-in unit and integration tests.
• Helper utilities to test that your module adheres to the ERC-4337 restrictions or to calculate gas.
• Security automation to detect possible vulnerabilities in the module code.

Module Sandbox is a frontend part of the Rhinestone kit, including a set of pre-built components. It is basically a playground to build and test frontend components for smart account modules.

Module SDK is a TypeScript library created for easy interaction with modules with the help of dedicated helper utilities. Integrated modules are Ownable Validator (allows to add an ECDSA owner to an account), WebAuthn Validator, MFA Validator, Scheduled Transfers, and Scheduled Orders (for scheduling swaps).

Both Module Sandbox and Module SDK are currently under active development so have to be used with caution.

Another not-so-technical but still extremely useful thing for developers is a Notion page “Module ideas for developer inspo” by Rhinestone. If you are thinking about building upon ERC-7579 this can definitely come in handy.

2.3 UniPass

UniPass is a wallet solution offering its own smart account contracts implementation and SDKs to use inside your dApps.

UniPass Contracts are unique because they introduce the Role Based Access Control (RBAC) to be used for the keys. Each account key has a specific role and weight. A key may be given to a single role or several roles. There are 3 available roles:

• Owner holds the primary authority for managing fundamental account operations, such as deployment, upgrades, and deletion.
• Operator is the key used the most as it is the main executor. The operator is able to transfer assets, interact with smart contracts, authorize permits, etc.
• Guardian is used for account recovery in case of losing keys.

UniPass also supports multiple key types. Here is an example:

The most intriguing type here is email address because UniPass introduces an on-chain email verification technique. It is possible thanks to verifying the email’s DomainKeys Identified Mail (DKIM) signature. This signature allows the receiver to check that an email was indeed sent and authorized by the owner of the specified domain, and not modified by a third party.

During the verification process, UniPass utilizes zero-knowledge proof technology to ensure the privacy and security of the user’s email information.

UniPass provides a default UniPass Relayer Node that you can use out of the box. It accepts gas payments in the form of native tokens and mainstream stable coins.

Custom Auth SDK is a non-UI SDK based on the UniPass contract, and available for Web, Android, and iOS. The main features are:

• Basic smart wallet usage like transaction signing and verification, tx batching, gasless services, wallet ownership transfer, and social recovery.
• Smart wallet management with various key management schemes: multi-signature logic, permission management that allows setting weights on keys and performing account operations with a threshold, RBAC-based permission management that allows setting weights and roles on keys.
• EOA and EIP-1271 contract accounts integration for using them as master keys.
• Social logins through integration with wallet services like Web3Auth and Magic.
• Customized integration solution based on JWT Token (JSON Web Token) for master keys.

Plug & Play SDK is a with-UI SDK based on the UniPass contract, where the with-UI refers to the UniPass Wallet. This SDK is also available for Web, Android, and iOS.

Conclusion

Typically, AA SDKs are created to easily integrate the wallet into your dApp including the interface for the account contracts and third-party infrastructure providers to use, which usually comes together with an API.

More mature solutions like Safe or Rhinestone are covering most of the needed functionality from tx batching to complex session key management logic. But sometimes you don’t need that many features. In this case, easier-to-use solutions that focus on certain features may seem beneficial: Patch Wallet API with social airdrops using Safe contract as a core, Banana Wallet with their OTP-based two-factor authentication (ZK-powered) and touchID-based signing, etc. If your intentions are within the gaming world, Openfort is a good choice as its SDK is targeted at the gaming industry.

In terms of modularity as discussed before Rhinestone is modular according to ERC-7579 and its SDK is generally focused on module management rather than the usual smart account interactions. There are also custom module implementations, e.g. in the Funkit and Soul Wallet (inspired by Safe modules).

Most of the SDKs are designed to be compatible with any other ERC-4337 wallet provider, but some of them are mainly oriented toward their own account implementations. These are, for instance, Halliday and UniPass. Their SDKs are created specifically for their implementations and this can be explained by the fact that the focus is shifted towards their branded wallet applications. However investigating how they approach AA issues still may be useful for developers, even if not using the wallet itself.

3. Infrastructure

This section consists of 2 main blocks: Bundlers & Paymasters and Auth Providers.

The first one is already well-known to us as a key component of the ERC-4337.

Auth providers are optional but very crucial when things come to supporting not only the Web3 auth approach, but also one of the main AA advantages — social logins.

3.1 Bundlers & Paymasters

3.1.1 Stackup

Stackup is focused on providing simplified smart account infrastructure.

Stackup’s paymasters allow users to sponsor transactions or accept ERC-20 tokens for gas payment. It charges a fee of 5% of the gas price to sponsor transactions.

When we come to bundlers things become more complex because the use of Alt Mempool leads to a number of rules and restrictions. The full set of validation rules for the canonical public ERC-4337 mempool is described in ERC-7562. First and foremost, it is needed to prevent denial-of-service attacks on the mempool.

Stackup bundler endpoints combine methods for both ERC-4337 bundlers and regular blockchain nodes. They can be public or private. Public RPCs are a great way to try the service without an API key, but they tend to be slow. For more robust production cases submitting a request for dedicated (private) bundlers is preferable. It is also important to mention that Stackup bundlers are MEV-protected.

Another useful product is userop.js — a JavaScript library for building User Operations. It is vendor-agnostic and can work with any ERC-4337 compliant infrastructure, whether self-hosted or from a third-party provider. It is also compatible with any Smart Account implementation from `SimpleAccount` to ZeroDev’s `Kernel` or custom ones. Userop.js can be especially useful for calling the Paymaster RPC Methods.

3.1.2 Gelato

Gelato is a unique case in terms of Account Abstraction infrastructure. It has 2 web3 services on top of which familiar AA bundler and paymaster are built:

• Gelato Relay is responsible for executing the transaction on-chain instead of the sender. How it works: user forms a meta transaction -> user signs this transaction (still off-chain) -> user passes the signed tx to a network of decentralized Gelato Executors -> executor verifies the signature with the help of ERC-712 and validates the transaction -> executor executes the tx on-chain. Doesn’t it sound familiar? This is very similar to how ERC-4337 bundlers work. This is why the Gelato Bundler is built on top of the existing Gelato Relay service and sponsors transactions via 1Balance.
• 1Balance is a unified multi-chain payments system the Gelato Paymaster is utilizing. It allows paying for all of your gasless transactions on all EVM chains with a single balance.1Balance system has a unique approach to sponsoring transactions because it does not rely on the on-chain EntryPoint to compensate transaction costs, getting rid of the need for an EntryPoint deposit or an on-chain paymaster. Transaction fees are settled post-execution which avoids overcharging users and reduces the overall on-chain footprint. This is possible by setting `maxFeePerGas=0`, thereby eliminating the need for upfront fee payments (`requiredPrefund=0`). In order to cover your relay costs regardless of the target chain you need to fund only 1 balance with: USDC on Polygon for mainnets and SEP on Sepolia for testnets. It’s important to mention that withdrawals are not yet supported, so need to be careful when funding and stay tuned for the update.

So, by using the approach above the Gelato infrastructure is cheaper due to not incurring on-chain paymaster and fee transfer overhead, users are charged with 100% accuracy as fees are settled post-execution, and the tx inclusion is instant as there is no need to wait for other UserOps to form a bundle. In addition, MEV protection is used.

3.1.3 Pimlico

Pimlico is an account abstraction infrastructure platform. It delivers bundlers, paymasters, and a library for efficient use of the previous two (similar to the Stakup structure).

Alto Bundler is a type-safe ERC-4337 bundler written in Typescript. A real gas saver here is that Alto Bundler supports sending compressed UserOps. To do so you need to: write and deploy your inflator contract implementing the `IOpInflator` interface -> get the inflator contract address whitelisted by Pimlico -> start submitting your compressed user operations using the `pimlico_sendCompressedUserOperation` JSON-RPC method. So, you send compressed UserOps and they will be decompressed on the inflator contract on-chain before submitting through the EntryPoint.

Paymaster. As usual, verifying and ERC-20 paymasters are available.

The verifying paymaster is a combination of an on-chain paymaster contract and an API (needed to get back a signature for the contract). Such kinds of payments are charged off-chain. Pimlico calculates the maximum amount of balance your user operation could possibly spend (gas limits * max gas price) in USD terms and charges the percentage on top of that to your pre-loaded balance or attached card. After 15 minutes Pimlico checks on-chain how much your user operation actually spent and refunds the difference to your account.

Unlike the verifying paymaster, an ERC-20 one is fully permissionless meaning that there’s no need to interact with any hosted APIs. This has the trade-off however that token approvals to the paymaster cannot be done during the execution phase of the UserOperation, and must rather be done during the validation phase or in a previous UserOperation.

Another highly important trade-off here is that Pimlico’s paymaster is not decentralized. The owner of the ERC-20 Paymaster has limited admin control. They can withdraw accumulated ERC-20 tokens from the contract for the purpose of swapping them back into native tokens and depositing them back into the paymaster. Additionally, the owner can update the `priceMarkup` and `priceUpdateThreshold` configurations within predefined limits to manage operational costs and risks.

`priceMarkup` (default value is 10%) is a form of fee the owner takes for maintaining the infrastructure and covering some risks. The good news is though the owner can change this value there is a hardcoded maximum set during the constructor that is enforced by the smart contract.

Last but not least about the ERC-20 paymaster — Chainlink is leveraged as price oracles, a combination of the ERC-20 Token to USD and Native Token to USD prices is used to calculate the ERC-20 Token to Native Token price. The nice thing about it is the ability to easily deploy Paymaster on any chain for any token that has Chainlink support, but the potential problem lies in the complete trust in Chainlink because if it is compromised paymaster is not completely valid anymore.

Permissionless.js is a TypeScript library built on viem for interacting with ERC-4337 bundlers, paymasters, and user operations. It is easy to use, has a small bundle size, and provides high-level support for the major ERC-4337 smart accounts, including Safe, Kernel, Biconomy, and SimpleAccount.

Conclusion

Bundlers and Paymasters in the infrastructure delivering focused services are implemented in a similar way according to ERC-4337 specification and ERC-7562 rules. Almost all of the products along with the Bundler & Paymaster services introduced a library for easy UserOps manipulations within the infrastructure. They are actively used by the SDKs, e.g. Rhinestone Module Box is built on top of Permissionless.js introduced by Pimlico.

While bundlers are unique for each product but still comparatively similar, paymasters’ logic varies from solution to solution except for the fact that all of them provide 2 main paymaster types: verifying/sponsoring and ERC-20 ones. For example, Gelato Paymaster is based on the Gelato 1Balance service that does not rely on the on-chain EntryPoint for gas costs compensation and sets the fees post-execution allowing to charge users with 100% accuracy. On the other hand, Pimlico is utilizing a combined off-chain (with API) and on-chain approach for verifying paymasters, while making its ERC-20 paymasters fully permissionless (but unfortunately not decentralized).

Stackup infrastructure and Infinitism Universal Paymaster are closer to the basic and standardized approach familiar to the user after the ERC-4337 investigation.

3.2 Auth providers

In terms of AA, signers are separated from the account while in usual EOAs private key and public key are conjoined. Regardless of the type of authentication, we anyway get back to the private key required to sign transactions, whether they are regular EOA transactions or those packaged in UserOps. Securing a private key is a complex art and it is particularly interesting to see how different auth providers have approached the issue.

3.2.1 Web3Auth

Web3Auth is not just a signer provider but a perfect example of utilizing MPC technology in AA wallets.

The Web3Auth SDK lives solely on the user/application’s front-end client and handles the interactions between OAuth providers and the Auth Network. From the diagram below you can see how different Web3Auth products are related to other applications.

Web3Auth high-level architecture

Plug and Play SDK is like a wrapper for all other internal processes. It includes UI components like modal and facilitates the embedding of the login function. From the modal user is redirected to the login/OAuth provider, and after carrying out the authentication process there, is redirected back. After the successful authentication, Web3Auth handles the reconstruction of the user’s key.

Core Kit SDK is the backbone of the magic happening behind simple login. It can be divided into 2 types:

• Single Factor Auth. It is semi-custodial in nature, since the key is custodial to the Auth Provider and the Web3Auth Network, but neither Web3Auth, Social Login Providers, nor any other party holding a key share can claim full ownership. This can be achieved because to create a social login share, users interact with the Web3Auth Auth Network, where key generation operates via a 5/9 consensus system.
• Multi-Factor Auth. Here things become more interesting because this is where MPC comes to the game. With the Web3Auth infrastructure, your key is divided into multiple parts and stored across your devices and the Auth Network. In the traditional Web3Auth SDK, your key was dynamically reconstructed in the front end using threshold signatures. In the MF Auth case, it is never reconstructed, your key remains divided. Each part of your key on its own can sign a piece of a message or transaction. These partial signatures are collected and combined using a method called Threshold Signature Scheme (TSS) to create a complete signature. This final signature can then be used to execute transactions on the blockchain.

Auth Network is an open-source wallet management network that safely splits and secures user wallets. Current operators are Binance, Ethereum Name Service, Etherscan, Polygon (MATIC), Zilliqa, Tendermint, Ontology, SKALE, and Web3Auth (Torus).

To make things simpler we can think of the Web3Auth key management infrastructure in the following way:

• user’s private key is split into multiple shares using SSS(Shamir Secret Sharing): socials (Google, Twitter, etc), device, and backup/security question.
• OAuth (social login) share is split into 9 shares, and they are held by 9 different nodes inside the Auth Network.
• when the user is trying to log in 5 out of those 9 shares are fetched and combined with any other share. This way the key is reconstructed (2/3).

As you can see the key is never stored by 1 party this way.

The flow described above is SSS-based shallow MPC which is used by Single Factor Auth. For Multi-Factor Auth TSS (Threshold Signature Scheme) based full MPC system is used. In this case, we can replace the part where key reconstructions happen with partial signature generations. The flow remains the same, but the key is never reconstructed. Here is the scheme to visualize the logic:

SSS MPC vs TSS MPC

In the example 2 of 3 scheme is used but you can use 2 of n adding more shares.

3.2.2 Turnkey

Turnkey is a crypto private key infrastructure that lets developers securely generate private keys and sign transactions via simple APIs.

Infrastructure is built upon the concepts of organizations as a logical grouping of resources. Each organization has its root quorum, you can think of it as of group of users who can execute any action and bypass the policy engine if the threshold “n of length of users in quorum” is reached. The policy engine contains rules defining which users can take which actions within an organization.

Moving closer to private keys we need to understand the concept of wallets and accounts is Turnkey. Wallet (hierarchical deterministic (HD) Wallet is this case) is basically a collection of crypto private keys that share a common seed. Seeds are generated with a default mnemonic length of 12 words according to BIP-39, but you can use 15, 18, 21, or 24 words to enhance security. Account is used to sign with the private key, which is extended from the wallet.

Another crucial concept is Credentials. They represent ways for Users to authenticate to Turnkey. All Turnkey Credentials are held by you, the end user. Turnkey only keeps public keys.

Two types of credentials are supported:

• Authenticators. Webauthn device registered on Turnkey is what it is.
• API Keys are a P-256 key pair generated by a user (either through the CLI or through the dashboard). A private key is held by the user, public key is within the Turnkey’s control. Requests made via SDK or CLI use the private API key to sign requests. Turnkey’s public API expects all requests (e.g. to get data or to submit activities) to be signed.

Turnkey provides an opportunity to recover your access to the account via email in case access to the API keys and authenticators is lost. Email recovery is happening only through the previously attached to the account email. Unlike typical email recovery, no tokens in a ready-to-use format are sent. Instead, recovery credentials are encrypted before transferring. It is needed to protect against man-in-the-middle attacks.

Let’s see how the recovery happens:

• a user creates a target encryption key (TEK). This target encryption key is a standard P-256 key pair
• the public part of this key pair is passed as a parameter inside of a signed `INIT_USER_EMAIL_RECOVERY` activity
• Turnkey creates a “recovery credential” (a fresh P-256 key pair), and encryptes the private key with the TEK user sent when initiating the recovery.
• the user receives the encrypted private key via email and after decrypting it with the private key part of the TEK is able to use it to sign a `RECOVER_USER` activity, submitted to Turnkey.

Email Auth is another feature that can be used to authenticate the Turnkey account with email via either a one-time code or a magic link. In this process, the user is granted an expiring API key that is stored in memory within an iframe. This expiring API key can then be used by the user to access their wallet, similar to a session key.

Encrypted “auth credential” (a fresh P-256 key pair) is delivered, to the user via email according to the same procedure that is used during email recovery.

Additionally, Turnkey SDK has integrated passkey functionality.

3.2.3 Privy

Privy is a library that provides authentication flows and embedded wallets to your app. The most mature product is Privy React SDK which with the help of simple broadly customizable React components and hooks makes it easy for users to onboard. It supports multiple methods for authenticating:

• email or phone number via a one-time password (OTP)
• social accounts (Google, Apple, Twitter, Discord, Github, TikTok, LinkedIn, Spotify) via the OAuth2.0 Protocol
• verifying the user’s ownership of a wallet via the Sign In With Ethereum (SIWE) standard.

An important thing here is that one user can associate multiple login methods to his account.

The key feature is Embedded wallets. Privy allows users to connect an external Ethereum wallet to your app, or to create a secure, self-custodial embedded wallet associated with the login method. Both of them are able to do basic wallet tasks but embedded wallets do not require a separate wallet client, like a browser extension or a mobile app, and can be accessed directly from your product (that is why they are embedded). Another difference is some extra customization in terms of how signature and transaction prompts are presented to users.

The embedded wallet consists of 3 parts:

• SDK — a high-level interface for the apps to integrate.
• API for storing wallet metadata for a given user, such as their wallet address.
• Isolated iframe — entity for private key management and wallet operations handling.

Along with that simplicity goes a responsible approach to security. It’s important to know that Neither Privy nor integrated applications ever access embedded wallet private keys.

According to the official documentation when a user creates an embedded wallet, the isolated iframe securely generates a keypair for the user by choosing 128 bits of entropy, and converting the bits to a mnemonic via BIP-39. From this mnemonic, the iframe then derives the wallet’s public key (and by extension, the wallet address) and private key.

The iframe then splits the private key into three shares using Shamir’s secret sharing:

1. Device share, which is stored in the iframe’s local storage.

2. Auth share, which is encrypted and stored by Privy.

3. Recovery share, which is encrypted either by user-provided entropy (a strong password) or by Privy. Recovery shares are only ever encrypted or decrypted on the user’s device.

The full private key is only ever assembled in memory and is never persisted anywhere. The threshold to constitute the full private key is at least two of three shares.

Conclusion

The market of signer vendors is very diverse compared to the previous blocks. Most of the solutions are good at providing basic signing methods like email, social accounts, passkeys, SIWE, 2FA, biometrics, etc. However, the difference is how they approach the key management problem. We can roughly categorize their approaches to wallets into the following types:

• Non-custodial wallets: Turnkey, Magic.
• MPC wallets (non-custodial): Privy, Fireblocks MPC, Portal, Capsule, Walletkit.
• Decentralized MPC Network (non-custodial): Lit Protocol, Web3Auth (Torus Network), 0xpass.

Future of the AA technology

The ERC-4337 is not the endgame, it’s more like a staging area, a migrating path to the RIP-7560— Native Account Abstraction. It would be an extremely risky decision to modify the protocol in such a significant way right away. That is why ERC-4337, which requires no protocol changes, is a great candidate to test how the community will accept it and see the growth potential of such an ecosystem. And the fact that we were not able to include the analysis of the products built upon ERC-4337 in this article speaks for itself.

Ethereum is already moving towards implementing native changes. A new hot topic recently included in the upcoming Pectra upgrade is EIP-3074. It allows externally owned accounts to delegate control to a contract by introducing 2 new opcodes: AUTH and AUTHCALL. It is expected to dramatically improve the UX and be a part of the gradual onboarding to AA, but still not a full solution. ERC-4337 and therefore RIP-7560 are able to cover more functionality and use cases. For instance, EIP-3074 does not provide the key rotation feature, missing the key point of typical user behavior: we all make mistakes and can lose things, especially secret keys. So, this proposal is a highly important step, one of many, on a long path to abstracting our accounts.

If you want to get to know more about EIP-3074 compared to other AA proposals, this Ambire Wallet article is recommended.

Conclusion

Now, having an understanding of what tools are currently powering the account abstraction ecosystem we can see how far the idea of expanding the usual EOA has come.

We’ve looked through the main blocks that can be used to build a smart account: core smart contracts, smart account modules, SDKs & APIs, Bundlers & Paymasters, and Auth Providers. There are also full-stack solutions including some or even all of them in one place, but most of the tools are built to be compatible with others. Like a Lego constructor, you can build your own Smart Account with different blocks depending on your needs and requirements. Moreover, you can find the implementations for almost any platform: Web, mobile, game engines, etc.

The AA ecosystem is quite a broad topic and there are much more products than it is described in this article. Unfortunately, we cannot cover all of them here because that would be too much. But it’s good to keep in mind that there’s already a plenty of tools to help with your needs. And if there’s some functionality missing it’s a high time to create something amazing and be a part of the community that is helping to onboard millions of users to web3.