In the previous article, we showed how a
userOperation is processed by the
EntryPoint contract and ultimately executed to modify the account state.
Such flow uses the funds deposited by the account to the
EntryPoint to fund the transaction gas cost. However, there is an extension to that flow that allows users to execute operations without paying for gas at all.
Introducing the paymaster component…
The paymaster covers the transaction cost of a given user. It can either pay through the native token or any ERC20 token as well!
This calls for a slight modification of the flow. It starts with passing an address value for the paymaster field in the
Note that when an address is passed, there is no need for the account itself to have any funds staked to the
EntryPoint.This removes further friction from the user experience as well.
The paymaster has the following interface:
validateUserOp on the account to make sure the user is allowed to execute the
calldata field on the wallet. This is the same flow as if we are not using a paymaster.
EntryPoint now calls
validatePaymesterUserOp on the paymaster which has one goal:
To make sure the user can use the paymaster’s stake to execute their operation.
Where this function is called is not straightforward to find in the EntryPoint contract, but it is called within
After performing these checks, it returns a
context stored in
_handleOps() then calls
_executeUserOp() while passing
Note that there is a loop because the EntryPoint executes multiple
userOperations at a time.
_executeUserOp then calls
innerHandleOp() which finally executes the
calldata to modify the account state.
Then, the function
_handlePostOp() is called. If the address of the paymaster in the
userOp is not the 0 address, the
postOp() function is called on the paymaster. This function finally handles the internal paymaster accounting.
What happens inside the Paymaster
Paymaster usually requires certain entities to stake ether or tokens to cover the transaction cost. We can call them sponsors
Sponsors then can whitelist spenders to use their stake. A sponsor can be the account service provider for instance. This is usually the process for paymasters that uses ETH.
For paymaster that uses ERC20 tokens. The process is pretty much the same. Except an oracle is used to get the price for the token used in terms of ETH.
Then, the tokens are removed from the stake of the sponsor. Which means it is implicitly seized by the paymaster.
Note that the paymaster can be developed by a third party other than the service provider. The project developing the wallet does not need to develop its paymaster as well.
It is pretty much like Oracles, you can use UniswapV3 instead of building your own.
In the next article in this series, we will go through a checklist of issues to look for when auditing ERC4337 wallets!