| Field | Type | Description |
|---|---|---|
| sender | address | The address of the smart contract account. |
| nonce | uint256 | Anti-replay protection. |
| initCode | bytes | Code used to deploy the account if not yet on-chain. |
| callData | bytes | Data that’s passed to the sender for execution. |
| callGasLimit | uint256 | Gas limit for the execution phase. |
| verificationGasLimit | uint256 | Gas limit for the verification phase. |
| preVerificationGas | uint256 | Gas to compensate the bundler for the overhead to submit a UserOperation. |
| maxFeePerGas | uint256 | Similar to EIP-1559 max fee. |
| maxPriorityFeePerGas | uint256 | Similar to EIP-1559 priority fee. |
| paymasterAndData | bytes | Paymaster contract address and any extra data the paymaster contract needs for verification and execution. When set to 0x or the zero address, no paymaster is used. |
| signature | bytes | Used to validate a UserOperation during verification. |
Account Abstraction
UserOperations
The mempool operation requested by the user focuses on the following concept:
The decentralized mempool for EIP-4337 consists of an unrestricted peer-to-peer network of independent bundlers. It operates without assuming any contracts as permissible or impermissible, treating all contracts equally when validating them.
However, there may be instances where certain contracts have undergone audits and been proven to be secure, despite violating some rules set by the decentralized mempool. In such cases, a group of bundlers can create alternative mempools specifically for handling these exceptions. An example scenario that might require this is when using a Deposit Paymaster that can abstract gas fees with any ERC-20 token.
Furthermore, in addition to its main connection to the decentralized mempool, a bundler also maintains connections to any other alternative mempools it chooses to participate in.