ERC-4337 is an Ethereum standard that aims to revolutionize the way user accounts are handled in the Ethereum ecosystem, as part of the Shanghai hard fork of the Shapella Upgrade. It is a means of account abstraction that allows for the creation of smart accounts. These accounts are entities that can perform multiple tasks, handle multi-factor authentication, initiate and sustain crypto subscriptions, and more, all through code. 
On March 1, 2023, during WalletCon in Denver, Yoav Weiss, a security fellow from the Ethereum Foundation, announced that the primary contracts for ERC-4337, commonly referred to as "account abstraction" by blockchain developers, had undergone an audit by Open Zeppelin and were approved for use on all Ethereum Virtual Machine (EVM) compatible networks, including Polygon, Optimism, Arbitrum, BNB Smart Chain, Avalanche, and Gnosis Chain. 
The primary goal of ERC-4337 is to bring the functionality of smart contracts to wallets. Traditionally, wallets have been limited to managing private keys and signing transactions. However, with ERC-4337, wallets become synonymous with smart accounts, allowing for more complex functionality. ERC-4337 aims to increase the adoption of web3 technology by simplifying the user experience and making it easier for non-developers to interact with the Ethereum ecosystem. 
With ERC-4337, Ethereum plans to bring new ideas to user accounts and make them more user-friendly.
Account abstraction is a blockchain-specific term that refers to the ability to abstract away the details of an account's implementation from the contract code that interacts with it. This means that developers can write contract code that can interact with different types of accounts without knowing the specific implementation details of each account type. 
The term "abstraction" refers to the removal or extraction of legacy handling of user accounts, such as the reliance on private keys and the need for seed phrases. Account abstraction enables platforms to offer cryptocurrency services without the need for users to create a conventional wallet and manually save their seed phrase or private key. This is possible as cryptographic keys can be saved locally in the hardware security module (HSM), allowing the creation of secure self-custodied cryptocurrency wallets. 
Functions and Mechanisms
It provides rules and mechanisms for validating UserOperations before they are added to the mempool and bundled into transactions. The validation process checks for forbidden opcodes, limited storage access, and limitations on CALL opcodes. The UserOperation is not allowed to access any data related to other UserOperations or contracts, and three special contracts interact with the account: the factory, the paymaster, and the signature aggregator. 
The code is also built to ensure the safety of the platform by implementing a set of entry point methods that handle user operations and aggregated operations. These methods perform various checks and validations to ensure that only valid operations are executed, and that they are executed in a secure and efficient manner. 
For example, the handleOps function makes two loops, the verification loop and the execution loop, to validate and execute each user operation. In the verification loop, the function creates the account if it does not yet exist, and calls validateUserOp on the account to verify the operation's signature, pay the required fee, and validate the account's deposit. In the execution loop, the function calls the account with the user operation's calldata, and it's up to the account to choose how to parse the calldata and execute the operation. To prevent malicious actors from disrupting the platform, the code implements a reputation system for paymasters, who can sponsor transactions for other users. The paymaster interface includes functions for validating user operations and managing their deposit, as well as adding and withdrawing stakes. 
The code also includes checks to prevent DoS attacks by paymasters and ensure that they have enough ETH deposited with the entry point to pay for the operation. If the paymaster's validatePaymasterUserOp function returns a "context", the handleOps function must call postOp on the paymaster after making the main execution call, and guarantee the execution of postOp by making the main execution inside an inner call context. 
The protocol also includes several functions to make account abstraction not just secure but also efficient. Some of the main functions includes eth_sendUserOperation for submitting UserOperation objects, eth_estimateUserOperationGas for estimating gas values, eth_getUserOperationByHash for returning a UserOperation based on a hash, eth_getUserOperationReceipt for returning a UserOperation receipt based on a hash, and eth_supportedEntryPoints for returning an array of supported entryPoint addresses. 
Did you find this article interesting?