Erc-4337 Wallet

[Onfroi Baird]

Smartcontract wallets that use Account Abstraction (ERC-4337) create a wallet that is managed using a smart contract instead of a wallet that is managed by a single private key like EOA wallets (Externally Owned Address).

The programmable nature of smart contract wallets allows for the development of a wide range of new use cases. By reducing complexity without compromising security or anonymity, smart contract wallets will help facilitate onboarding of the next wave of blockchain users.

Want to add embedded smart contract wallets to your app? Use our enterprise-grade Embedded Accounts and vertically integrated AA infrastructure to onboard users with no seed phrases, gas, or friction.

Also known as smart contracts, contract accounts contain code which manages the exchange of information between parties. Contract accounts are used in every DeFi protocol, NFT collection, or ERC-20 token.

All of the contract's business logic and state variables are stored on-chain. Because the state and code of a smart contract is stored on-chain, the externally-owned account deploying it must pay a fee.

The main difference between smart contract accounts and EOA accounts is that smart contract accounts can contain logic. Because only EOA accounts can initiate transactions smart contract accounts rely on Bundlers' EOA account to bundle user operations into a single transaction that is posted on the blockchain.

Because Smart Contract wallets can not initiate a transaction, they must be called by an EOA wallet. This process is supported by multiple Account Abstraction infrastructure providers (e.g. Bundlers) and smart contracts (e.g. EntryPoint)

While understanding how smart contract wallets work from a technical perspective may be difficult to understand, for end users, smart contract wallets provide many improvements compared to EOA wallets such as programmability and the ability for features like social recovery.

For more information on how each component of Account Abstraction works read our series, "You Could Have Invented Account Abstraction," which was written by David Philipson, on Alchemy's Account Abstraction Infrastructure engineering team.

But before diving deeper, we first need to take a step back and understand what Ethereum accounts are, and the two main types: externally-owned accounts (EOAs), and contract accounts.

An externally-owned account (or EOA) is an account created by generating a public-private key pair. The account owner (individual or organization) can then use the key pair to access and manage the funds associated with the account.

Most of the popular web3 wallets on Ethereum (such as MetaMask, Coinbase Wallet, and Rainbow) are EOAs. You can use them to initiate transactions with other EOAs or smart contracts and even send transactions to contract accounts.

For a user to interact with the blockchain through an EOA, they must: create a wallet, store their private keys, purchase & transfer funds, pay gas fees, and sign every single action that they take on a dApp.

For example, you can set a daily transaction limit, whitelist and blacklist addresses, set a time when you do not need your guardians to sign multi-sig transactions, bundle multiple transactions into one, and more.

ERC-4337 is a newly deployed Ethereum standard that introduces account abstraction, or smart accounts, to all EVM-compatible blockchains. Despite how similar smart accounts and smart contract wallets sound, they have some contrasting differences.

Account abstraction simply refers to separating (abstracting) an account from the blockchain, without making any changes to the underlying blockchain. The contract accounts created using account abstraction are called smart accounts.

So, for every transaction users had to pay extra gas from the EOA to send the transaction to the contract. As a result, smart contract wallet owners also had to maintain an ETH balance in a separate EOA. Or, they could use third-party relay systems, which are mostly centralized.

Account abstracted wallets or smart accounts get rid of the need for EOAs. Instead, smart accounts can send a UserOperation object that defines the purpose of the transaction and has the relevant data for verification.

To prioritize transactions, bundlers use a similar logic to how miners or validators prioritize transactions in the mempool based on the fee associated with each of them. Bundlers earn the combined fee paid within all UserOperation they bundled.

Smart contract wallets existed before ERC-4337 standardized account abstraction for all EVM chains. Account abstracted wallets or smart accounts add on top of the benefits of smart contract wallet benefits. See sections How Smart Accounts Work and Use Cases of Smart Accounts.

In conclusion, smart accounts significantly increase the potential of previously existing smart contract wallets. They standardize account abstraction across EVMs and remove the need for EOAs and seed phrases for end-users.

Existing SC wallets still rely on EOAs to initiate transactions and pay for gas. While certain SC wallet providers built their own custom infrastructure to deal with this, it required a lot of effort and resulted in fragmented implementations.

The idea behind ERC-4337 is simple: level the playing field for developers building SC wallets by standardizing some of the off-chain and on-chain infrastructure required by SC wallets to operate. In short, ERC-4337 will make it easier for developers to build SC wallets.

As a solution to this crappy UX, embedded wallets are emerging to remove some of the points of friction that exist with personal wallets. Unlike personal wallets, embedded wallets are invisible to users as they come with a set of APIs rather than a dedicated frontend.

Application developers will be able to use these APIs to integrate wallet functionality directly into their user interfaces, giving them more creative freedom to experiment and customize the wallet experience for their applications.

Going back to our earlier example, crypto game developers will be able to let users spin up a pre-funded custom-branded wallet so they can go from having no wallet and no money to playing a blockchain-based game as fast as it takes to create an email account.

Under the hood, this would be powered by session keys (to pre-approve transactions users would normally need to make) and multicalls (to batch several pre-approved transactions into one bundled transaction).

To make this more concrete, applications like OpenSea may want to compete with a personal wallet like MetaMask to be the primary touch point for users by offering a superior account management experience with customized embedded wallets.

What all of this means is that certain applications may be motivated to sidestep personal wallets by giving their users customized embedded wallets with a self-custody experience that rivals what personal wallets provide; in doing so, application teams will be able to own the user relationship in a much more direct way.

For example, users may need to give social login providers like Google certain permissions over their SC account. The same goes for providers of multi-factor authentication and social recovery. This is great for adoption because end-users will feel safer knowing their accounts can be backed up easily, giving them a comparable experience to what they're used to in web2 today.

So even if ERC-4337 could mean ceding some control to third parties to improve the self-custody experience for users, they'll still be able to retain full control over their accounts with the added benefit of being able to tailor their accounts' security set-up to meet their needs, with more granular account permissioning and control.

Personal wallets and applications using embedded wallets may want to build their own OFAs to capture the MEV from user ops, similar to how Robinhood sells its orderflow to market makers and large trading firms. In the same vein, personal wallets and applications using embedded wallets could use the MEV they capture to subsidize gas fees for their users.

ERC-4337 will also open the door for experimentation with mempool design as it allows for the creation of alternative user op mempools with different rulesets. For example, wallets could run their own user ops mempool that only shares partial data on incoming user ops to their OFA to reduce harmful MEV.

This higher level, alternative mempool layer could potentially be used by Bundlers to match intents (user ops) before they hit the chain to make settlement cheaper and more efficient. This would be a bit similar to how the Clearing House Interbank Payments System's clearance system continuously matches, nets, and then settles payments via Fedwire.

Web2 apps have struggled to connect to the web3 ecosystem and reap its benefits because they have to build their own infrastructure to solve a number of issues (e.g., wallet integrations, chain support, and on/off ramps).

One of the most exciting new use-cases of ERC-4337 is the ability for existing web2 apps to embed wallets in-app. This will let the mainstream applications we use today easily connect to the blockchain ecosystem and integrate crypto-native features, thereby converting their users into web3 without them having to manually spin up wallets.

By using embedded wallet middleware to create wallets on users' behalf and add metadata to them, for example, apps could use click-through ads to seamlessly onboard users and track where they came from. This would also make identifying single users on their platforms much simpler as they could map different wallets to the same email address.

ERC-4337 may also make it easier for apps to engage with existing users and resurrect activity. For example, DEXs may be able to more accurately track how much a user trades and issue fee rebates or dynamic fees based on how much volume they contribute, and, more generally, may be able to create loyalty programs to retain and incentivize users.

3a8082e126