Original Title: "Wallet Infrastructure: Empowering the Next Generation of Dapps"

Author: Nichanan Kesonpat, 1kx

Translation: Elvin, ChainCatcher

Wallet infrastructure plays a crucial role in unlocking the next generation of dapp web3 experiences.

So far, in order to interact with web3 for the first time, users still have to install additional software, find and purchase cryptocurrencies, and even deal with unfamiliar screen confirmation operations. Despite improvements in the experience and the increasing reliance on mnemonic phrases, these obstacles remain key factors driving customer churn for decentralized applications.

The innovation environment has matured, allowing for the abstraction of technical complexity and the natural integration of new financial, social, and gaming experiences without compromising self-custody and the original spirit of decentralization.

2023 is a critical year for the wallet ecosystem, with account abstraction at all levels and development activities reshaping the market structure and our understanding of the relationship between users, dapps, and wallets.

The main content of this article is as follows:

• Introduction and benefits of account abstraction
• Overview of wallet infrastructure and AA stack
• Emerging dapp/wallet development patterns and their impact
• Ongoing challenges and further exploration of solutions

I. Introduction and Principles of Account Abstraction

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

For traditional Externally Owned Accounts (EOAs), the private key retains unique and complete control over its associated account. The strict one-to-one mapping between the private key and the account means that:

• Users are limited to using dedicated key management solutions (e.g., Metamask, Ledger) when interacting with the blockchain.
• If the private key is lost, it cannot be recovered, and the key controlling the account cannot be replaced.
• All operations initiated by the private key, whether it's minting a free NFT or transferring millions of dollars, are considered equal.

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

We can further understand the benefits by examining the abstracted content.

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

ERC-4337, introduced in 2021, is a standardized approach to achieving this goal without altering the core protocol. However, some projects have already implemented the advantages of AA long before the AA standard was fully matured.

• Safe multisig wallets, launched in 2017, have evolved to safeguard assets worth over $50 billion for DAOs, enterprises, and individuals.
• Argent mobile wallet has been supported by smart contract accounts since 2018.
• Sequence wallet, launched in 2021, enables Skyweaver to create and log into their smart accounts via email and use non-native tokens to pay fees.

This requires each project to build and maintain custom relay infrastructure.

Enter 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 through a shared account abstraction transaction ("User Operations") in a spare memory pool with third-party relayer relays.

Relayer bundlers bundle multiple UserOps into a transaction, send it to an independent EntryPoint contract, which then verifies the fee payment (paid by the account or through the paymaster) and executes on the UserOps corresponding to the smart account.

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

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

This has brought a wave of new infrastructure and service providers to the wallet ecosystem and has driven existing projects to ensure their business strategies and products continue to meet the needs of application developers aiming to provide seamless web3 experiences for users using AA.

II. Wallet Infrastructure and AA Stack

(1) Signers and Key Management

Signers and key management infrastructure are responsible for generating and protecting public 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, enabling alternative authentication methods such as social and email for mnemonic-free login and wallet management.

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

Lit has improved this server-side key storage design with decentralized key management. Each node in the network stores a portion of ECDSA private keys generated through DKG algorithms, and all operations are conducted in an encrypted virtual environment. Arbitrary authentication rules can be assigned to key pairs, allowing applications or users to fully control permitted interactions and impose spending limits. The network can further be used as a backup and recovery option by 2/n MPC wallets.

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

• Hardware signers utilize separate subsystems such as the iPhone Secure Enclave and Android Titan HSM to generate keys and sign messages, ensuring hardware-level security. As keys cannot be extracted from the device, they are very powerful when used in conjunction with other recovery methods or as part of a 2FA system.

• Passkeys is a passwordless authentication standard built on WebAuthn. In this, key pairs are generated in the device's operating system and can be synchronized between devices through services like iCloud, so it is possible to recover if the user chooses to do so.

One limitation here is that the passwords and signatures generated by hardware signers cannot be recognized by native chains such as 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 verification, some products supporting Passkey are using services like Lit and Turnkey, which generate K1 signatures once the user authenticates with their keys.

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

With the growth in account abstraction transaction volume, signature aggregation using BLS signatures may lead to lower fees for smart accounts compared to EOAs on L2. The 4337 standard defines an interface for the aggregator helper contract, which verifies individual aggregated signatures, approves multiple UserOps, and does not individually verify each UserOps.

(2) Relayers

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

Similar to Ethereum having 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 able to withstand the risk of vulnerabilities in a single deployment. The 4337 specification includes a test suite to ensure bundler compatibility across the entire network. Deployments include Stackup (Golang), Pimlico, Bionomy, Etherspot (Typescript), Candide (Python), OKX (Java), and Alchemy (Rust).

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

With the growth of 4337, we can expect to see builders also becoming bundlers, as this hybrid model may be more profitable than just being a builder, allowing them to choose from both the transaction pool and UserOps pool.

(3) Paymasters

By allowing dapps to pay gas fees for users, allowing 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 Policy Manager, used for developers to define conditions for sponsoring gas fees. This can be limited to the entire project scope or based on individual contracts or wallet addresses. Developers can also define how they want to limit gas sponsorship, such as limiting gas price, requests, or monthly sponsorship amounts. Gas sponsorship fees are typically included in the service provider's developer monthly invoice, with an additional fee of about 5% charged based on the sponsorship amount.

• The Paymaster smart contract verifies whether a given transaction is eligible for payment based on on-chain status (such as account balance) or off-chain gas management policies. The Paymaster contract holds a balance of native tokens for paying gas fees and may include periodic checks of the exchange rate between payment tokens (e.g., USDC) and native tokens (e.g., ETH) using a price oracle logic.

Paymasters can be divided into on-chain and off-chain types:

• On-chain Paymasters (e.g., ERC20Paymaster, StablecoinPaymaster) rely solely on on-chain status to verify whether a transaction can be paid by the paymaster. This means that some paymasters, such as those accepting ERC-20 for gas fees, can be permissionless, but it should be noted that paymasters must be approved by the account to make token transfers. Paymaster contract administrators can withdraw tokens and exchange them back for native tokens to refill the contract, set a markup above the ERC20 price, update the price difference threshold for the next UserOp using ERC20 prices, or manually update prices.

• Off-chain Paymasters (e.g., VerifyingPaymaster) involve interaction with the service provider's paymaster API to sponsor UserOps. Off-chain services verify eligibility and sign transactions using paymaster keys. While this solution is permissionless, off-chain paymasters can save gas fees by minimizing on-chain checks. Gas policies can be more refined, and off-chain activities such as Discord events can be taken into consideration.

(4) Account Providers and Frameworks

Account providers and frameworks offer "headless" smart account deployment and SDK, on which dapp and wallet clients can build, creating self-custodial embedded accounts on behalf of users. The account itself is a smart contract wallet with its own signature verification, execution, and replay protection (nonce management) logic. Owners use key authorization to perform user operations from the smart account.

At a high level, smart account providers offer three core components:

• Core deployment of the smart contract wallet, using its own set of logic to verify, execute transactions, and perform additional operations before and after transaction execution. It also includes logic on how to add additional functionalities to the wallet through native and third-party modules.

• Factory contracts, deploying new instances of wallets implemented by the account's initial signer. Under ERC-4337, dapps can create smart accounts for their users by specifying the factory contract address of their chosen provider.

• An SDK, providing plug-and-play customization capabilities for developers creating smart accounts. This can include different signature options, fund in/out methods, and relay technologies.

Under ERC-4337, the "sender" field of the UserOp refers to the smart account conducting the transaction. If the account has not been deployed, the EntryPoint will deploy the account from the factory contract specified in the "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 identity authentication infrastructure, offering dapps the choice of how users manage smart accounts. For example, Safe's Web3Auth integration allows users to use their accounts via social or email, and Zerodev's integration with Turnkey provides the option to manage accounts using Passkeys.

Safe is 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 on at least 12 blockchains, executing over 22 million transactions. Prior to v1.4.1 (released in July 2023), developers were able to use the Gelato relay for gas abstraction transactions. This integration currently supports encrypted debit card products like Gnosis Pay and BasedApp, allowing users to make purchases from any Visa-accepting vendor 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 exposed a gas manager dashboard where developers can define scopes and restriction logic to provide fee sponsorship for users. ZeroDev and Bionomy (which also operates its own bundler network) currently dominate the 4337 account market.

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

(5) Account Modules

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

• Developers: Embedded smart accounts can come with "pre-installed" modules chosen by dapp developers, building entry wallets with customized functionalities tailored to specific use cases.

• End users: Wallet interfaces can display a "module store" interface where users can discover new features and add them to their wallets.

By formally separating UserOp verification and execution through AA, modules can contain logic for validation only or execution only.

• Validators: Called during the validation phase of UserOperation. Their primary function is to verify the signature of the UserOperation and determine its validity and whether it should be executed. Examples include multisig, ECDSA, passkeys, multi-chain verification, and session keys. Session keys allow dapps to sign on behalf of users to simplify 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 more diverse operations that can be executed locally, such as automatic operations triggered outside the regular ERC-4337 execution flow, such as automatic token exchange when a price reaches a certain threshold.

• Hooks: Run before/after execution and enforce 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 already developed modules that users can directly install, we expect to see a rich third-party module ecosystem that can be found in the wallet's app store interface or integrated by dapp developers into an embedded "entry" wallet.

Smart account frameworks have been designed with module considerations in mind. Safe's core contract handles module management logic for adding and removing modules from the account, but confines the actual module-related logic and storage entirely to a separate contract. This separation reduces the risk of third-party modules covering 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, aiming to foster a composable smart account ecosystem inspired by the Safe wallet product.

ZeroDev explicitly categorizes their modules ("plugins") into 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" feature only allows NFT transfers through 2FA.

Building a robust modular smart account ecosystem has some considerations:

1. Interoperability: As multiple smart account providers have their own methods for allowing third parties to add new functionalities to accounts, module developers are moving towards vendor lock-in or have to deal with the technical overhead of developing the same functionality to be compatible with multiple account deployments. There are some solutions to mitigate this situation:

• ERC-6900, which is aimed at modular smart contract accounts (MSCA), defines an interface for modular smart contract accounts and plugins to allow interoperability.

• Rhinestone's ModuleKit is used to build and test smart account modules, providing templates and frameworks for testing modules for different account deployments, integration libraries (e.g., DeFi protocols), pre-built execution conditions, and security automation for parsing module code and flagging security vulnerabilities.

1. Security: Granting users the ability to install third-party software in wallets poses a significant issue of how the interface should manage and display information related to modules.

EIP-7484 provides a means to verify the legitimacy and security of independently built smart account modules. Here, a 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 safely used.

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 information about audits, performers, and verified standards.

3. Discoverability: Registries can be displayed and queried through smart account platforms and wallet interfaces, and can be installed by developers or end users.

The ability to extend wallet functionality makes accounts a developer platform for web3 products and services and a new distribution channel. 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 (such as Starknet and Bitcoin).

The evolving wallet stack means:

• Developers can create non-custodial accounts for users in their apps and seek SDK connectors and other tools to provide end-to-end login building options.

• Embedded wallets are a new category of wallets, each with its own features and trade-offs in account portability, customization, and trust assumptions.

If you operated an Ethereum dapp in 2018, you may remember a Metamask popup when loading a website. This was due to a lack of good user experience practices in connecting wallets and dapps, with developers often using hard-coded checks to see if users had the browser's "window.ethereum" object installed with the extension wallet. If users installed multiple extension wallets, it would lead to unpredictable behavior, and users would have to choose one wallet, creating a smaller wallet market competition.

The emergence of the WalletConnect communication protocol allows users to connect any wallet to any dapp, along with the introduction of Web3Modal, a library containing buttons and module components that allow users to choose which wallet they want to use with a dapp.

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

Recently, EIP-6963 has been finalized as an alternative wallet discovery mechanism to "window.ethereum," allowing dapps and extensions to communicate with injected scripts in a predictable manner. Thanks to this standard, users now have more choices when selecting an extension wallet to connect to a dapp, 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 seen the future of dapp login user experience, with the next generation of wallet libraries (referred to here as fully mature "Onboarding SDKs") gaining more attention. In addition to wallet-based authentication, these SDKs also provide other registration and login options, such as email, social, and SMS, and create embedded wallets for users without the need to install additional software or exit the dapp.

Developers can directly integrate connectors provided by identity providers (such as Magic, Privy, Web3Auth), or use connectors that bundle multiple services (such as Dynamic, Thirdweb, 0xPass) to provide plug-and-play options for the identity verification options they want to expose and the types of wallets they want to create, thus achieving a fully customized login process. Onboarding SDKs can also integrate with smart account providers to create embedded smart wallets, providing further user experience enhancements such as gasless transactions and deposit/withdrawal methods.

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

(1) Independent Wallets, Embedded Wallets, and Specific Application Wallets

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

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

While specific application wallets may be desirable for certain use cases (such as games), in many cases, users may log into their first dapp, create an embedded wallet using their web2 signers or Passkey, and hope to use the same signer to log into another dapp and access the assets accumulated in their account.

• Capsule is an MPC-based embedded wallet provider that emphasizes the portability of wallets across dapps using its services, allowing users to access existing wallets with the same email. We can expect this to become a must-have product across WaaS providers.

• Moonchute helps users manage multiple smart accounts during this time. Their unified account manager is an app and API used to discover 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 applications to discover user accounts created using other signing schemes. Here, applications redirect users to a URI for a given provider (which can be a self-hosted domain) and parse the response for the signer and associated smart account address.

(2) Migration from EOA

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

EIP-7377 proposes an on-chain mechanism that allows EOAs to send a one-time transaction to deploy code on their account, effectively "upgrading" the EOA to a smart wallet.

Aarc aims to address the asset migration issue for dapps and end users. Their UI and SDK index assets and permissions from specific source addresses, allowing users to select the assets they want 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 that are accustomed to the independent wallet process, Aarc provides a solution to simplify the migration process when they want to add embedded wallet or AA functionality to their products.

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

Considering the momentum of AA and L2 activities, we can foresee that smart accounts will become the mainstream for EOAs, and users will have 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 the inability to change the key controlling a given address, and the risk of losing all funds if the user loses the private key.

As account abstraction separates key storage from asset storage for a given account, it is possible to rotate keys for a given account without having to migrate funds while maintaining the same address. Smart accounts can use CREATE2 to maintain the same address across chains, even if the contract has not been deployed on a given chain, allowing users to access the account with the same initial verification key and account deployment.

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 the multi-chain world of zk-Rollup (such as zkSync), this approach is insufficient.

• We can expect that the keys required to access various accounts will change over time, and wallets will display more signing and key rotation features. In the current setup, this could quickly lead to a drift in the account permission state across chains, as a change in the signer of an on-chain account does not automatically pass the 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 is still an active research area. The ultimate goal of the research is to allow users to change the keys to access multiple accounts on different chains without conducting a large number of transactions.

(4) Conclusion

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

• ERC-4337, as the standard for relaying smart account-initiated transactions, has driven 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, providing developers with choices to customize the end-user experience. This brings additional overhead to evaluate each provider in terms of gas expenses, resistance to censorship, vendor lock-in, and interoperability.

• The migration path from EOA and account abstraction in a multi-chain context is still an ongoing research area. We expect to see the implementation of the first proposed solutions next year.

We believe that these developments have a significant impact on the entire ecosystem:

• For new users, wallets are no longer the sole entry point into web3. Applications will significantly improve the login experience through embedded wallets, gasless transactions, and in-wallet deposit methods.

• For current users, as applications leverage features such as session keys, the on-chain experience will become smoother. Advanced users can have more granular control over account permissions and other wallet features through modules.

• For developers, modular account infrastructure turns wallets into an operating system. The module market is a new permissionless distribution channel for web3 products and services.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。