It’s easy to understand why the concept of Account Abstraction has enveloped the Ethereum community since the release of ERC-4337. It promises a whole new, easier way to interact with the Ethereum ecosystem. Losing your private keys will not necessarily mean permanent loss anymore; you won’t need ETH to pay your gas fees; and the off-chain world becomes increasingly simpler to integrate into your on-chain activity. Many believe social recovery is the key to onboarding the next billion users to web3 by reducing self-custody risks.
Account Abstraction as a concept is not new—Vitalik wanted to include it in the initial launch of Ethereum but did not have the time. He had created two Ethereum Improvement Proposals (EIPs) related to account abstraction (EIP-86, and EIP-2938) prior to the release of ERC-4337.
But these enhancements to the way we experience web3 introduce new complexities into the transaction lifecycle that are important for both users and developers to understand. This guide will break down the components that make up account abstraction and walk you through the new transaction lifecycle under ERC-4337.
For a deeper technical dive into ERC-4337 we recommend reading the full spec ERC-4337: Account Abstraction Using Alt Mempool.
How Ethereum works today and what account abstraction (ERC-4337) will change
To fully understand account abstraction, you must first understand the different types of accounts that exist on most EVM-compatible chains—externally owned accounts (EOAs) and smart contracts:
Externally owned account (EOA)
An externally owned account (EOA) is what your typical web3 wallet uses when interacting on most EVM networks. They are controlled by a set of cryptographic ‘private’ keys that are used to sign transactions or messages, and that’s basically all they can do.
Due to EOA limitations:
- All EOAs must pay gas fees in ETH on the Ethereum blockchain—even when conducting non-ETH transactions.
- If an EOA’s private keys are compromised, the entire account can be drained and there is nothing anyone can do to recover the account. The entire security of the account is based on the user’s ability to maintain their private keys.
Smart contract accounts
Unlike EOAs, smart contract accounts contain programmable logic that defines and automatically enforces rules via their code—IF this THEN that.
Traditionally, smart contracts are not controlled by a user but, instead, are deployed to the network and run autonomously. This is why Decentralized Exchanges (DEXs) are able to run, even if they had no front-end webpage for users to connect to, as their smart contract operates on the blockchain for anyone to call at any time.
Account abstraction seeks to harness the programmability of Smart Contract Accounts for end users. The programmability of a smart contract will enable users to achieve far more with their wallets than simply signing and executing transactions under an EOA.
How ERC-4337 changes Ethereum
TL:DR; it changes nothing (about the protocol) and everything (about the user experience).
Rather than making any adjustments to the consensus layer, which would require a hard-fork and extensive testing leading up to the launch, ERC-4337 is a proposal for a new standard on Ethereum that is currently being experimented with and refined, with contracts deployed on both Goerli testnet and Ethereum mainnet.
ERC-4337 sets a new standard for infrastructure that can enable :
- social recovery of wallet (i.e. losing your private keys won’t necessarily mean permanently losing access to your account);
- perform atomic multi-operations (e.g. approve and swap in same transaction);
- pay transaction fees with ERC-20 tokens;
- sponsorship of users’ gas fees on your dapp;
- and a host of other applications
It is the goal of ERC-4337 for there to eventually be no need for users to have an EOA if they have an ERC-4337 compliant smart contract wallet.
ERC-4337 Technical Specs: The New Components of Account Abstraction
There are five major components to Account Abstraction under ERC-4337: UserOperation, Bundler, EntryPoint, Aggregators, and Paymasters. The full spec can be found here: https://eips.ethereum.org/EIPS/eip-4337
UserOperation — pseudo-transaction objects that express a user’s intent
Rather than initiating a traditional transaction, smart contract wallets will instead create pseudo-transaction objects known as UserOperations (userOp) that represent the user's desired transaction intent.
From a technical perspective, UserOperations are Application Binary Interface (ABI) encoded structures comparable to internal transactions in smart contracts. These are not regular transaction types and should not be identified as “transactions.”
To ensure that a UserOperation will still be valid and capable of paying for its own execution on-chain, it is not allowed to access any information that might change between simulation and execution, such as current block time, number, hash etc.
A UserOperation is also only allowed to access data related to the sender address.
Like a “regular” transaction, a UserOperation contains: sender, to, calldata, maxFeePerGas, maxPriorityFee, signature, and nonce. However, unlike a transaction, the nonce and signature fields usage is not defined by the protocol, but by each account implementation.
Additionally, a UserOp also contains several additional fields not seen in “regular” EOA transactions, such as:
| Field | Type | Description |
sender |
address | The account making the operation |
nonce |
uint256 | Anti-replay parameter; also used as the salt for first-time account creation |
initCode |
bytes | The initCode of the account (needed if and only if the account is not yet on-chain and needs to be created) |
callData |
bytes | The data to pass to the sender during the main execution call |
callGasLimit |
uint256 | The amount of gas to allocate the main execution call |
verificationGasLimit |
uint256 | The amount of gas to allocate for the verification step |
preVerificationGas |
uint256 | The amount of gas to pay for to compensate the bundler for pre-verification execution and calldata |
maxFeePerGas |
uint256 | Maximum fee per gas (similar to EIP-1559 max_fee_per_gas) |
maxPriorityFeePerGas |
uint256 | Maximum priority fee per gas (similar to EIP-1559 max_priority_fee_per_gas) |
paymasterAndData |
bytes | Address of paymaster sponsoring the transaction, followed by extra data to send to the paymaster (empty for self-sponsored transaction) |
signature |
bytes | Data passed into the account along with the nonce during the verification step |
UserOperation Mempool—a new stop added before landing on-chain
Instead of going to the traditional public mempool that hosts pending transactions for EOAs, UserOperations will instead be sent to the UserOperation mempool—a dedicated, higher-level mempool specifically for UserOperations.
Like the traditional public mempool, the UserOperation mempool is made up of a permissionless P2P network. UserOperation mempool nodes can use logic similar to today’s Ethereum transaction handling logic to determine whether or not to include or forward a UserOperation to its peers.
UserOperations that use whitelisted Paymasters or SignatureAggregators (Aggregators) are put into a separate “alternate mempool.” Only Bundlers that support these whitelist will use UserOperations from these alternate mempools. UserOperations from alternate mempools can be bundled together with UserOperations from the main UserOperation mempool.
Bundler—facilitating a transaction’s path to finality
A Bundler is a node that listens to the UserOperation mempool, bundles multiple UserOperations together, and sends that bundle to the EntryPoint contract for execution.
On-chain, this would look like an EOA to smart contract transaction, with the execution of UserOperations as the internal transactions. The “from” address will be the Bundler, and the “to” address will be the EntryPoint contract. An example of this can be seen in the following ERC-4337 Goerli transaction.
Bundlers choose which UserOperation objects to include in their bundle transaction based on similar fee-prioritization logic used by block builders on Ethereum today.
Because the Bundler acts as the “from” address when getting the bundle transaction on-chain, the Bundler will pay the gas fee for the bundle transaction in ETH. Bundlers are compensated through fees paid as part of all the individual UserOperation executions.
Before accepting a UserOperation, Bundlers will simulate it to verify that the signature is correct and the UserOperation can pay its fees. Because Bundlers pay for the gas of all the UserOperations, it is important for them to avoid including UserOperations that failed validation to avoid absorbing the gas cost of those not able to pay.
A Bundlers can be a block builder, but not all block builders on the network are required to be Bundlers. Bundlers can also be net-new specialized actors that either broadcast their UserOperations bundle transactions to the public mempool for inclusion or relay them directly to specific block builders, similar to the way searchers operate today.
SPECIAL NOTE FOR BLOCK BUILDERS: When a block builder includes an ERC-4337 bundle transaction in a block, it is important that earlier transactions in the block don’t make any UserOperation fail. The block builder should either use access lists to prevent conflicts, or place the bundle as the first transaction in the block. |
EntryPoint—global contract to validate and execute UserOps
The EntryPoint contract is a singleton contract that verifies and executes the bundles of UserOperations sent to it. It is a global entry point that everyone using ERC-4337 compliant smart contract wallets will use to transact on the EVM. This concept is comparable to the single staking deposit contract.
The use of an EntryPoint simplifies the logic used by smart contract wallets, pushing the more complicated smart contract functions needed to ensure safety to the entry point rather than in the wallet itself.
Bundlers/Clients should whitelist their supported EntryPoint.
Aggregator—aggregate UserOp signatures
The bundled UserOperations are validated in a single step, rather than validating each signature separately, by an Aggregator— a helper contract trusted by accounts to validate an aggregated signature. Aggregators improve the efficiency and scalability of transaction processing under ERC-4337.
Bundlers/Clients can whitelist supported Aggregators.
Aggregators that access global storage will need to stake* (more on staking below).
Paymaster—sponsor user transactions
A Paymaster sponsors transactions for other users. This feature can be used to enable a number of interesting new features for transacting on Ethereum:
- application developers can easily subsidize fees for their users;
- users can pay gas fees with ERC-20 tokens or off-chain payment methods like credit cards or other subscription services;
- On-chain credit services
- And more.
There are currently two common types of paymasters according to Account Abstraction development firm StackUp:
- Verifying Paymaster: provide gas abstractions linked to an off-chain process. For example, it can enable users to pay for their transaction fees with a credit card or subscription service without sacrificing custody of their account.
- Deposit Paymaster: provide gas abstractions linked to an ERC-20 token on-chain.
Connecting to a Paymaster is optional.
A Paymaster must either limit its storage usage, or have a stake. If the Paymaster accesses global storage, it must stake*.
*SPECIAL NOTE on staking for entities using global storage UserOperation storage access rules prevent UserOperations from interfering with each other. However, “global” entities like Paymasters, factories and Aggregators are accessed by multiple UserOperations, and thus might invalidate multiple previously-valid UserOperations. To prevent abuse, the system will throttle down (or completely ban for a period of time) an entity that causes invalidation of large numbers of UserOperations in the mempool. To prevent such entities from “sybil-attack”, global entities must stake with the system to make such a DoS attack very expensive. This stake is never slashed, and can be withdrawn any time (after an unstake delay).There are exemptions for global entities that do not access global storage. |
Monitor and Test Account Abstraction Infrastructure
Blocknative has several resources for developers building Account Abstraction infrastructure, including an ERC-4337 UserOp Dashboard, an ERC-4337 Bundler on Goerli (endpoint: https://api.blocknative.com/v1/goerli/bundler), and real-time mempool monitoring of bundle transactions sent to the Goerli EntryPoint contract.
Send UserOps to the Blocknative Bundler on Goerli
If you are developing and testing Account Abstraction infrastructure, you can now send UserOperations to the Blocknative Bundler endpoint at https://api.blocknative.com/v1/goerli/bundler.
The Blocknative Bundler is built off of the Stackup open-source bundler. We currently have health checks and monitoring enabled. In the near future we plan to add:
- a status endpoint to the Bundler
- a Paymaster service + related wallet monitoring
Monitor the EntryPoint Contract in Real-time with Mempool Explorer
When submitting UserOps on Goerli, you can now use Mempool Exploror to monitor pending and confirmed transactions going through the EntryPoint contract. Mempool Explorer will auto-decode the EntryPoint contract calls to show the parameters of the Bundler to EntryPoint transaction. Full decoding of the userOp call data is coming soon!
For a step deeper, you can also use Mempool Explorer to monitor for pending simulations and see the EntryPoint contract's internal transactions and any expected net balance changes.
View On-Chain UserOps with Our 4337 Dashboard
Bundle already on-chain? You can use our 4337 UserOp Dashboard to view all the bundle transactions that have gone through the Goerli EntryPoint contract. We plan to roll out Ethereum Mainnet and Polygon Mumbai soon!
Join Us on Discord
Account abstraction is the likely path to onboarding the next billion web3 users. We are excited to help in further developing this infrastructure. If you have any questions or would like to collaborate, join our Discord to chat: https://discord.com/invite/zFaP9QMPZa
—-
Resources
https://eips.ethereum.org/EIPS/eip-4337
https://docs.stackup.sh/docs/introduction/erc-4337-overview
https://docs.stackup.sh/docs/introduction/account-abstraction
https://docs.stackup.sh/docs/packages/bundler/introduction
https://www.stackup.sh/blog/how-to-sponsor-transactions-using-a-paymaster
https://docs.stackup.sh/docs/api/paymaster/introduction#stackup-paymaster-api
https://ethereum.org/en/developers/docs/smart-contracts/
https://github.com/eth-infinitism/bundler-spec-tests
https://github.com/stackup-wallet/stackup-bundler
https://api.blocknative.com/v1/goerli/bundler
https://docs.ethers.io/v5/api/utils/abi/#application-binary-interface
Observe Ethereum
Blocknative's proven & powerful enterprise-grade infrastructure makes it easy for builders and traders to work with mempool data.
Visit ethernow.xyz
