RoadToChain Logo
RoadToChain
T4/M4.4/UserOperations field anatomy
advanced 14m read

UserOperations field anatomy

Breaking down sender, nonce, callData, paymasterAndData, and gas limits in a UserOp.

#userop #erc4337 #diagram

To write custom clients or parse logs in ERC-4337 systems, you must understand the fields of the UserOperation (UserOp) struct. A UserOp represents the user's intent, packaged as a Solidity struct definition.


1. The UserOperation Struct Definition

Here is the exact Solidity representation of a UserOperation defined in the IEntryPoint interface:

SmartAccount.sol
solidity
struct UserOperation {
    address sender;
    uint256 nonce;
    bytes initCode;
    bytes callData;
    uint256 callGasLimit;
    uint256 verificationGasLimit;
    uint256 preVerificationGas;
    uint256 maxFeePerGas;
    uint256 maxPriorityFeePerGas;
    bytes paymasterAndData;
    bytes signature;
}

2. Field-by-Field Dissection

sender (address)

The address of the user's Smart Account contract. This is the contract that will validate and execute the operation.

nonce (uint256)

A counter to prevent replay attacks. Unlike EOA nonces, which are simple sequential numbers, ERC-4337 nonces can have key namespaces (the upper 192 bits represent a namespace key, allowing out-of-order parallel transactions).

initCode (bytes)

If the user's Smart Account has not been deployed on-chain yet, this field contains the creation payload: the factory contract address (first 20 bytes) followed by the constructor arguments. The EntryPoint contract uses this payload to deploy the wallet contract dynamically on the user's first transaction.

callData (bytes)

The execution payload passed to the Smart Account during the execution phase. This defines which target contract to call and with what function arguments (e.g., calling the Socio3 contract's createPost function).

callGasLimit (uint256)

The amount of gas allocated for the execution phase (executeUserOp).

verificationGasLimit (uint256)

The amount of gas allocated for the validation phase (validateUserOp). This is critical: if validation uses too much gas or accesses forbidden state, the bundler will discard the operation to prevent spam.

preVerificationGas (uint256)

The gas to cover the overhead of transmission, serializing, and bundling. This is paid to the bundler to cover their transaction submission cost.

maxFeePerGas and maxPriorityFeePerGas (uint256)

EIP-1559 gas pricing parameters, defining the maximum fee and tip the user (or Paymaster) is willing to pay.

paymasterAndData (bytes)

If gas is sponsored, this field contains the address of the Paymaster contract (first 20 bytes), followed by any verification parameters (like the verification signature generated by your backend server). If empty, the Smart Account contract pays for its own gas.

signature (bytes)

The cryptographic signature generated by the user's Privy EOA signer. The Smart Account's verification code reads this signature to validate that the EOA owner approved the UserOp.

Was this lesson helpful?

Let us know what you think of this specification. (submitting anonymously)