1KX: How Wallet Infrastructure Empowers the Next Generation of dApps

I. Introduction to Account Abstraction and Principles

We can view account abstraction as the decoupling of account management from key management. An account is an entity on the blockchain that can hold assets and has a transaction history. A signer (key) is an entity authorized to perform operations on behalf of the account.

For traditional accounts (EOA), the private key retains sole and complete control over its associated account. The strict one-to-one mapping between the private key and the account means:

Users are limited to using dedicated key management solutions (e.g., Metamask, Ledger) when interacting with the blockchain.
Loss of the private key results in irretrievability, and the key controlling the account cannot be replaced.
Whether minting a free NFT or transferring millions of dollars, all operations initiated by that private key are treated equally.

Account abstraction transforms the account into a smart contract, with dynamic logic indicating which keys can represent it in operations and their scope of permissions, further balancing based on use cases.

We can further understand the benefits by looking at what is abstracted.

Since the Ethereum protocol only recognizes transactions originating from EOAs, account abstraction requires off-chain infrastructure to forward transactions originating from smart contracts onto the chain.

ERC-4337, launched in 2021, is a standardized approach to achieve this goal without changing the core protocol. However, some projects had already realized the advantages of AA before the standard was fully matured.

The Safe multi-signature wallet was launched in 2017 and has since evolved to safeguard over $50 billion in assets for DAOs, enterprises, and individuals.
The Argent mobile wallet has been supported by smart contract accounts since 2018.
The Sequnce wallet, launched in 2021, allows Skyweaver users to create and log into their smart accounts via email and pay fees using non-native tokens.

This requires various projects to build and maintain custom relay infrastructure.

Let’s look at ERC-4337. This standard provides a decentralized and censorship-resistant alternative for the relay layer, defining an interface for accounts, paymasters, and signature aggregators to interact with third-party relayers through a shared account abstraction transaction ("User Operations") memory pool.

Relayer ("bundler") aggregates multiple UserOps into a single transaction and sends it to an independent EntryPoint contract, which then verifies that the fees will be paid (either by the account or through the paymaster) and executes on the UserOps corresponding to the smart account.

We can compare this with the on-chain validation and execution methods that provide native account abstraction (without requiring additional relay operations, such as zkSync and Starknet), as well as the recently released RIP-7560 proposal for native AA for Ethereum and its rollups.

In March 2023, the 4337 EntryPoint contract was deployed to the mainnet. Its community has achieved great success in engaging developers in the account abstraction movement.

This has brought a wave of new infrastructure and service providers to the wallet ecosystem and pushed existing projects to ensure their business strategies and products can continuously meet the needs of application developers aiming to leverage AA for a seamless web3 experience for users.

II. Wallet Infrastructure and the AA Stack

(1) Signers and Key Management

Signers and key management infrastructure are responsible for generating and protecting the public-private key pairs used to sign messages, transactions, and UserOps. The most direct example here is traditional EOA wallets, but wallet-as-a-service providers have emerged that enable passwordless login and wallet management through alternative authentication methods such as social media and email.

At the core, these services either store critical data content in HSMs (like AWS KMS), accessible only to users via authentication credentials (Magic, Turnkey), or adopt certain SSS/MPC solutions (Privy, Web3Auth, Portal, Capsule) to secure this content.

Lit improves this server-side key storage design through decentralized key management. Each node in the network stores a part of the ECDSA private key generated through DKG algorithms, with all operations conducted in an encrypted virtual environment. Any authentication rules can be assigned to the key pair, allowing applications or users to fully control the allowed interaction operations and impose spending limits. The network can further be used as a backup and recovery option for 2/n MPC wallets.

This year, there has been rapid experimental progress in utilizing hardware signers and passkeys as account signers, providing users with out-of-the-box key management on modern mobile or desktop devices. These signers use biometric authentication (e.g., FaceID, TouchID) to offer additional security for a familiar user experience.

Hardware signers utilize separate subsystems, such as iPhone Secure Enclave and Android Titan HSM, to generate keys and sign messages, ensuring hardware-level security. Since keys cannot be extracted from the device, this is very powerful when used alongside other recovery methods or as part of a 2FA system.
Passkeys are a passwordless authentication standard built on WebAuthn. Here, the key pairs are generated within the device's operating system and can be synchronized across devices via services like iCloud, making recovery possible if the user chooses.

One limitation here is that signatures generated by passkeys and hardware signers cannot be natively recognized by chains like Bitcoin and Ethereum. They use the secp256r1 (R1) elliptic curve, while Bitcoin and Ethereum use the K1 curve. Although work is currently underway for trustless and effective R1 validation, some passkey-supporting products are using services like Lit and Turnkey to generate K1 signatures once users authenticate with their keys.

One standard to note here is EIP-7212, which proposes adding the R1 curve directly to the EVM as a precompiled contract, allowing every modern device to natively sign transactions without third-party services or intermediaries.

As the volume of account abstraction transactions grows, the use of BLS signatures for signature aggregation may lead to lower fees for smart accounts compared to EOAs on L2. The 4337 standard defines an interface for aggregator helper contracts that verify a single aggregated signature, approving multiple UserOps instead of validating each UserOp individually.

(2) Relayers

Relayers (e.g., 4337 Bundler) forward transactions or UserOps to the memory pool. On chains with native AA, network operators and sequencers play the role of relayers, eliminating the need for external dedicated relayers.

Just as Ethereum has multiple client deployments (e.g., geth, erigon, reth), the 4337 ecosystem also has multiple bundler deployments in different languages, making the network more robust and resilient to vulnerabilities from single deployments. The 4337 specification includes a suite of test cases to ensure bundler compatibility across the network. Deployers include Stackup (Golang), Pimlico, Bionomy, Etherspot (Typescript), Candide (Python), OKX (Java), and Alchemy (Rust).

The bundler incentive model is similar to that of block builders, charging fees from bundled user operations (rather than transactions). In practice, bundlers need to include an API in the block builder to view the current block and create a package valid for that block, so it should be viewed as part of the block builder.

As 4337 grows, we expect builders to also become bundlers, as this hybrid model will be more profitable than just being a builder, allowing them to choose from both the transaction pool and the UserOps pool.

(3) Paymasters

By allowing dapps to pay gas fees for users, enabling users to pay fees with non-native tokens, or settling off-chain through traditional payment channels, paymasters achieve fee abstraction. Paymaster services have two main components:

Gas strategy managers, which allow developers to define the conditions under which gas fees are sponsored. This can be defined across the entire project or based on individual contracts or wallet addresses. Developers can also define how they wish to limit gas sponsorship, such as capping gas prices, requests, or monthly sponsorship amounts. Gas sponsorship fees are typically included in the service provider's monthly invoice, with an additional charge of about 5% based on the sponsorship amount.
Paymaster smart contracts verify whether a given transaction is eligible to be paid based on on-chain states (like account balances) or off-chain gas management strategies. Paymaster contracts hold native token balances for paying gas fees and may include price oracle logic to periodically check the exchange rate between payment tokens (e.g., USDC) and native tokens (e.g., ETH).

Paymasters can be categorized as on-chain or off-chain:

On-chain paymasters (e.g., ERC20Paymaster, StablecoinPaymaster) rely solely on on-chain states to verify whether a transaction can be paid by the paymaster. This means that certain paymasters, such as those accepting ERC-20 tokens for gas fees, can be permissionless, but it is important to note that the paymaster must obtain approval from the account to perform token transfers. The paymaster contract administrator can withdraw tokens and convert them back to native tokens to refill the contract, set a markup above the ERC20 price, establish a price difference threshold for updating the ERC20 price for the next UserOp, or manually update prices.
Off-chain paymasters (e.g., VerifyingPaymaster) involve interaction with the paymaster API of service providers to sponsor UserOps. Off-chain services verify eligibility and use paymaster keys to sign transactions. While this solution is permissionless, off-chain paymasters can save gas fees by minimizing on-chain checks. Gas strategies can be more refined and take into account off-chain activities like Discord events.

(4) Account Vendors and Frameworks

Account vendors and frameworks provide "headless" smart account deployments and SDKs, allowing dapps and wallet clients to build on top of them, creating self-custodial embedded accounts on behalf of users. The accounts themselves are smart contract wallets with their own signature verification, execution, and replay protection (nonce management) logic. Owners use keys to authorize user operations from smart accounts.

From a high-level perspective, smart account providers offer three core components:

Core deployment of smart contract wallets, using their own logic to verify and execute transactions, as well as perform additional operations before and after transaction execution. It also includes logic for adding additional features to wallets through native and third-party modules.
Vendor contracts, which deploy new instances of wallets initiated by the account's initial signer. Under ERC-4337, dapps can create smart accounts for their users by specifying the vendor contract address of their chosen provider.
An SDK that provides plug-and-play customization capabilities for the smart accounts developers are creating. This can include different signing options, deposit/withdrawal methods, and relay technologies.

Under ERC-4337, the "sender" field of UserOps refers to the smart account involved in the transaction. If the account has not yet been deployed, the EntryPoint will deploy the account from the vendor contract specified in "initCode." The user's key can be used to claim the smart account for subsequent dapp interactions.

Account providers like Safe, Zerodev, and Bionomy integrate with key managers and authentication infrastructure to offer dapps choices on how users manage smart accounts. For example, Safe's Web3Auth integration allows users to use their accounts via social media or email, while Zerodev's integration with Turnkey provides an option for managing accounts using passkeys.

Safe is well-known for its proven smart wallet product, widely used by individual users, teams, and DAOs. To date, over 5 million Safe accounts have been deployed across at least 12 blockchains, executing over 22 million transactions. Before v1.4.1 (released in July 2023), developers were already able to use Gelato relay for gas abstracted transactions. This integration currently supports crypto debit card products like Gnosis Pay and BasedApp, allowing users to make purchases from any vendor accepting Visa payments using funds from their Safe accounts. v1.4.1 supports ERC-4337 through modules, providing more options for relay providers.

ZeroDev is a smart account provider launched earlier this year, initially built for ERC-4337. Zerodev aggregates multiple bundler providers to abstract UserOp relay services and has publicly released a gas manager dashboard where developers can define scope and limit logic to provide fee sponsorship for users. Zerodev and Bionomy (which also runs its own bundler network) currently dominate the 4337 account market.

Alchemy's AccountKit features 4337-compatible smart account deployment "LightAccount," which is based on EF deployment and adds EIP-1271 support (validating signatures from smart contracts) as well as ownership transfer, key rotation, and namespace storage.

(5) Account Modules

Account modules are smart contracts that act as installable components for smart accounts. While the module infrastructure is still in its early stages, we believe modules will be discovered and installed in the following ways:

Developers: Embedded smart accounts can be equipped with "pre-installed" modules chosen by dapp developers, building entry-level wallets with customized features for specific use cases.
End users: Wallet interfaces can showcase a "module store" interface where users can discover new features and add them to their wallets.

By formally separating UserOp validation and execution through AA, modules can contain logic that is solely for validation or solely for execution.

Validators. Called during the validation phase of UserOperation. Their primary function is to validate the signature of the UserOperation and determine its validity and whether it should be executed. Examples include multisig, ECDSA, passkeys, multi-chain validation, and session keys. Session keys allow dapps to sign on behalf of users to streamline the user experience, similar to temporary private keys with custom permissions and expiration.
Executors. Called during the execution phase of UserOperation. They extend the account's execution logic and support a more diverse range of locally executable operations, such as automated actions triggered outside the regular ERC-4337 execution flow, like automatically swapping tokens when a price reaches a certain threshold.
Hooks. Run before/after execution and impose controls on the account. For example, a Hook can run after execution and revert any transactions that meet specific criteria, enhancing user security.

While some wallets like Candide have developed modules that users can install directly, we expect a rich ecosystem of third-party modules to emerge, which can be found in the wallet's app store interface or integrated by dapp developers into an embedded "starter" wallet.

The smart account framework has already considered modules in its design. Safe's core contract handles module management logic for adding and removing modules from accounts, but the actual module-related logic and storage are fully confined to a separate contract. This separation reduces the risk of third-party modules overwriting the same state, compromising the account's security and expected behavior.

The Safe{Core} protocol introduces an open framework with modules, hooks, managers, and registries, aimed at nurturing a composable smart account ecosystem inspired by Safe wallet products.

ZeroDev explicitly categorizes their modules ("plugins") into two types: validation or execution. Executor modules are designed to pair with Validator modules, allowing custom functions to be routed through different validators. For example, the "NFT transfer" function only allows NFT transfers through 2FA.

Building a robust modular smart account ecosystem involves several considerations:

① Interoperability. As multiple smart account providers have their own methods for allowing third parties to add new features to accounts, module developers are moving towards vendor lock-in or facing the technical overhead of developing the same functionality to be compatible with multiple account deployments. Some solutions can alleviate this situation:

The ERC-6900 standard for modular smart contract accounts and plugins defines an interface for Modular Smart Contract Accounts (MSCA), allowing modules ("plugins") to interoperate with any compliant account deployment and plugin.
Rhinestone's *ModuleKit is used to build and test smart account modules, providing templates and frameworks for testing modules against different account deployments, integration libraries (e.g., DeFi protocols), pre-built execution conditions, and security automation for parsing module code and flagging security vulnerabilities.

Security. Empowering users to install third-party software in wallets raises a significant issue regarding how the interface should manage and present information related to modules.

EIP-7484 provides a means to verify the legitimacy and security of independently built smart account modules. Here, the registry allows auditors to certify the security of these modules. Frontends and smart accounts can query the registry for certification data to verify whether modules can be used safely.

More broadly, EIP-7512 aims to create a standard for on-chain expression of audit reports, which can be parsed by smart contracts to extract relevant information about audits for executors and verified standards.

② Discoverability. Registries can be showcased and queried through smart account platforms and wallet interfaces, allowing developers or end users to install them.

The ability to extend wallet functionality makes accounts a developer platform and new distribution channel for web3 products and services. We have already seen this with Metamask Snaps, which allows users to customize their browser extension wallets with security alerts (WalletGuard), privacy features (Nocturne), and interoperability with non-EVM chains (like Starknet and Bitcoin).

When Chrome provided developers with an ecosystem to extend browser functionality through extensions, it propelled their market dominance, even though they arrived a decade late. While most of us find it hard to imagine what the wallet experience will be like when modular accounts become mainstream, permissionless innovation has already begun to take shape.

III. Emerging Development Models and Their Impact

The evolving wallet stack means:

Developers can create non-custodial accounts for users in their applications and will seek tools like SDK connectors to provide end-to-end login building options.
Embedded wallets represent a new category of wallets, with each provider having its own capabilities and trade-offs regarding account portability, customizability, and trust assumptions.

If you interacted with Ethereum dapps in 2018, you might remember a Metamask popup when loading websites. This was due to a lack of good user experience practices in connecting wallets and dapps, where developers often hard-coded checks to see if users had installed the extension wallet using the browser's "window.ethereum" object. If users installed multiple extension wallets, it led to unpredictable behavior, forcing users to choose one wallet and creating a less competitive wallet market.

The emergence of the WalletConnect communication protocol allowed users to connect any wallet to any dapp, alongside the introduction of Web3Modal, a library containing button and module components that let users choose which wallet they want to use with the dapp.

Today, Web3Modal is one of several wallet connector libraries (like RainbowKit, Web3Onboard, and ConnectKit) that simplify the wallet detection and wallet-based authentication process for dapp developers. These libraries provide out-of-the-box theme options, wallet search functionality, and screens that can guide users to install wallets if they haven't done so yet.

Recently, EIP-6963 was finalized as an alternative wallet discovery mechanism to replace "window.ethereum," allowing dapps and injected scripts provided by extensions to communicate in a predictable manner. Thanks to this standard, users now have more options when choosing which extension wallet to connect to dapps, opening up a more competitive market for wallets.

While connector libraries have significantly improved developer and user experiences, the expectation that users have already installed or will install additional software to interact with dapps remains a significant adoption barrier.

We have already seen the future of dapp login user experiences, with the next generation of wallet libraries (which we will refer to as fully matured "Onboarding SDKs") gaining more attention. In addition to wallet-based authentication, these SDKs offer other registration and login options, such as email, social media, and SMS, creating embedded wallets for users without requiring them to install additional software or exit the dapp.

Developers can directly integrate connectors provided by key providers (e.g., Magic, Privy, Web3Auth) or use connectors that bundle multiple services (e.g., Dynamic, Thirdweb, 0xPass) to provide plug-and-play options for the authentication options they wish to expose and the types of wallets they want to create, enabling fully customized login flows. Onboarding SDKs can also integrate with smart account providers to create embedded smart wallets, offering further user experience enhancements like gasless transactions and deposit/withdrawal methods.

As more people adopt "headless" wallets and the wallet space shifts towards embedded wallets, the once-clear boundaries between wallets and dapps are beginning to blur.

(1) Standalone Wallets, Embedded Wallets, and Application-Specific Wallets

Today's Web3 users are accustomed to interacting with dapps through standalone wallets (like those provided by Metamask or WalletConnect), accumulating their assets and on-chain footprints in one or a few accounts.

As more dapps attract users through embedded wallets and multiple providers, account management is quickly becoming complex for both dapp developers and end users. Dapp developers will have to evaluate and manage multiple providers while trying to avoid locking into a single provider. For end users, creating a new wallet for each dapp will lead to a disjointed experience in managing assets and identities.

While application-specific wallets may be desirable for certain use cases (like gaming), in many cases, users may log into their first dapp, create an embedded wallet using their web2 signers or passkeys, and wish to log into another dapp using the same signer, utilizing the assets they have accumulated in their accounts.

Capsule is an MPC-based embedded wallet provider that emphasizes wallet portability across dapps using its services, allowing users to log in with the same email to access existing wallets. We can expect this to become a must-have product across WaaS providers soon.
Moonchute helps users manage multiple smart accounts in the meantime. Their unified account manager is an app and API for discovering smart wallets created by a given signer, allowing users to manage assets across multiple accounts in one place.
ERC-7555 proposes a standardized interface and request/response pattern inspired by SSO for application discovery of user accounts created using other signing schemes. Here, applications redirect users to a given provider's URI (which can be a self-hosted domain) and parse the response of the signer and associated smart account address.

(2) Migrating Away from EOAs

Another prominent challenge of AA is providing existing users with a seamless experience to migrate to smart accounts, who have already accumulated assets and on-chain history across multiple EOAs.

EIP-7377 proposes an in-protocol mechanism allowing EOAs to send a one-time transaction that deploys code on their account, effectively "upgrading" the EOA to a smart wallet.

Aarc aims to address the asset migration issues for dapps and end users. Their UI and SDK index the assets and permissions of specific source addresses, allowing users to select the assets they wish to move to a target address, which could be a smart account, another EOA, or an embedded MPC wallet created using social login. For dapps where existing users are accustomed to standalone wallet processes, Aarc provides a solution to simplify the migration process when they wish to add embedded wallet or AA features to their products.

(3) The Impact of AA on Multi-Chain Account Management

Given the momentum of AA and L2 activities, we can foresee that smart accounts will become mainstream over EOAs, with users holding assets across multiple chains.

One user experience advantage of EOAs is that users can automatically access the same address on different EVM chains using the same private key. The downside is that the keys controlling a given address cannot be changed, and if users lose their private keys, all funds may be lost.

Since account abstraction separates key storage from asset storage, keys can be rotated for a given account without needing to migrate funds while maintaining the same address. Smart accounts can maintain the same address across chains using CREATE2, allowing users to access accounts with the same initial verification keys and account deployments even if the contract has not been deployed on a given chain.

However, in the long run, maintaining the same address across chains may be an anti-pattern.

CREATE2 can only be used on chains with EVM bytecode equivalence. In a multi-chain world with zk-Rollups (like zkSync), this approach is insufficient.
We can expect that the keys required to access various accounts will change over time, as wallets showcase more signing and key rotation capabilities. Under the current setup, this could quickly lead to a drift in account permission states across chains, as changes to the signers of an account on one chain do not automatically pass new permissions to signers on other chains.

Long-term solutions proposed for multi-chain AA include:

A dedicated key storage contract that cross-chain user accounts read when checking permissions.
Using ENS multi-chain resolvers as an abstraction layer for different addresses.

Cross-chain account and signer management remains an active area of research. The ultimate goal of the research is to enable users to change keys for accessing multiple accounts across different chains without conducting numerous transactions.

IV. Conclusion

Account abstraction is an activity that separates signers from accounts, providing users with flexibility in key management and account permissions by treating contract-based accounts (rather than EOAs) as first-class entities on the blockchain.

ERC-4337 serves as the standard for relaying transactions initiated by smart accounts, facilitating the development of wallet infrastructure adapted to AA, resulting in new market structures, wallet categories, dapp development, and user login patterns.
The wallet stack is divided into signers, relayers, account providers, and account modules, offering developers choices for customizing the end-user experience. This brings additional overhead to evaluate each provider's trade-offs regarding gas costs, censorship resistance, vendor lock-in, and interoperability.
The migration path from EOAs and account abstraction in the context of multi-chain remains an ongoing area of research. We expect to see the implementation of the first proposed solutions next year.

We believe these developments will have significant implications for the entire ecosystem:

For new users, wallets are no longer the only entry point into web3. Applications will significantly improve login experiences through embedded wallets, gasless transactions, and in-wallet deposit methods.
For current users, on-chain experiences will become smoother as applications leverage features like session keys. Advanced users will have more granular control over account permissions and other wallet functionalities through modules.
For developers, modular account infrastructure turns wallets into operating systems. The module marketplace represents a new permissionless distribution channel for web3 products and services.

Cryptocurrency Market Infrastructure

Tracking the development status and trends of payment, escrow, wallet, data analysis, and other cryptocurrency market infrastructure.

Topic or theme

Related tags

Account abstraction wallet

ChainCatcher reminds readers to view blockchain rationally, enhance risk awareness, and be cautious of various virtual token issuances and speculations. All content on this site is solely market information or related party opinions, and does not constitute any form of investment advice. If you find sensitive information in the content, please click "Report", and we will handle it promptly.