A quick overview of the standard for developers.
This page gives a simplified overview of ERC-4337 so that developers can get a basic understanding of the different components and how they can be pieced together to build their applications. For a full run down on the spec we recommend going straight to the source.
There are four main components to ERC-4337: a
Contract Account. These can be supplemented by
UserOperationsare pseudo-transaction objects that are used to execute transactions with contract accounts. These are created by your app.
Bundlersare actors that package
UserOperationsfrom a mempool and send them to the
EntryPointcontract on the blockchain.
EntryPointis a smart contract that handles the verification and execution logic for transactions.
Contract Accountsare smart contract accounts owned by a user.
Paymastersare optional smart contract accounts that can sponsor transactions for
Aggregatorsare optional smart contracts that can validate signatures for
All Stackup tools are EIP-4337 compliant and composable with other open-source packages to make handling this logic easy.
- Bundler receives
UserOperationsvia a JSON RPC Client and submits them to the
- Paymaster API Plug-n-Play APIs to enable gasless transactions in your apps.
Recommended ecosystem tools:
- eth-infinitism client SDK helps you build
UserOperationsin your client.
- eth-infinitism contracts provides a library of ERC-4337 smart contracts for common use cases.
The following sections describe the
Account Contract, and
Paymaster Contract in more detail.
All components of ERC-4337 revolve around a pseudo-transaction object called a
UserOperation which is used to execute actions through a smart contract account. This isn't to be mistaken for a regular transaction type.
|The address of the smart contract account|
|Code used to deploy the account if not yet on-chain|
|Data that's passed to the |
|Gas limit for execution phase|
|Gas limit for verification phase|
|Gas to compensate the bundler|
|Similar to EIP-1559 max fee|
|Similar to EIP-1559 priority fee|
|Used to validate a |
Bundler is a class of actors that can do several things:
- Listen in to a
- Runs simulations.
- Bundles an array of operations.
- Relays bundles to the
UserOperation mempool is separate and not to be confused with the regular transaction mempool.
Although a public P2P
UserOperation mempool is still a work in progress, the advantages of account abstraction can still be leveraged today by relying on private mempools that anyone can spin up.
EntryPoint is a contract that acts as a central entity for all ERC-4337 accounts and paymasters. It coordinates the verification and execution of a
UserOperation. For this reason, it's important for all implementations of an
EntryPoint to be audited and not controllable by any single entity.
The above sequence diagram shows how the
EntryPoint handles a batch of
UserOperations sent by the
Bundler. Essentially there are 2 phases.
- Verification loop: Verifies that each
UserOperationis valid by checking it with both the
Account Contractand the
- Execution loop: Sends the
The verification loop will also make sure that either the
Account Contract or
Paymaster Contract can pay the maximum gas cost for each
UserOperation. In the execution loop any unused gas fee is refunded to the
Account Contract or a function is called on the
Paymaster Contract to run any required fee logic.
Create2Factory refers to EIP-2470: Singleton Factory. This is a permission-less contract used to deploy
Accounts with the same deterministic address on any chain.
Contract Account is an end user's account. At minimum it needs to check whether or not it will accept a
UserOperation during the verification loop.
Additional features to support other account functions like social recovery and multi-operations can be added here too.
Aggregator is a smart contract that is trusted to validate signatures for
Paymaster is another contract account that handles any
UserOperation with sponsored transactions. It is required to do 2 things:
- Check whether or not it will accept a
UserOperationduring the verification loop.
- Run any required fee logic in the execution loop.
An example of a
Paymaster logic could be to withdraw a certain amount of ERC-20 tokens from the
Contract Account after the
UserOperation is executed. This allows for a UX where users can pay for gas in any currency they choose.
Putting it all together: