A UserOperation is a data structure used in ERC-4337 account abstraction to describe an action that a smart account wants to perform. It serves a transaction-like role for smart accounts, but it is not a native Ethereum transaction and is not submitted directly to Ethereum consensus in the same way as a transaction signed by an externally owned account.
Instead, UserOperations move through dedicated ERC-4337 infrastructure. They can be collected by Bundlers, processed through the EntryPoint smart contract, and ultimately executed by the user’s smart account. This additional layer makes it possible to introduce programmable validation, gas sponsorship, alternative authentication methods, batched actions, and other wallet features without changing the basic format of Ethereum’s native transactions.
The distinction between a UserOperation and a transaction is fundamental. A UserOperation expresses what a smart account wants to do and provides the information required to validate and fund that request. An ordinary Ethereum transaction is later used to carry one or more such operations to the EntryPoint contract for on-chain execution.
Why ERC-4337 Introduced UserOperations
Traditional Ethereum accounts use a relatively rigid transaction model. An externally owned account signs a transaction with its private key, specifies parameters such as the recipient, value, data, gas settings, and nonce, and broadcasts that transaction to the Ethereum network. The sender also needs ETH to pay the transaction fee.
Smart contract accounts can implement more flexible rules, but they need infrastructure capable of expressing and processing those rules before execution. ERC-4337 addresses this problem without requiring Ethereum consensus to treat smart accounts exactly like EOAs.
UserOperations are central to this design. Rather than forcing every account abstraction action into the conventional EOA transaction workflow, ERC-4337 creates a separate request format that can contain information needed by programmable accounts and their surrounding infrastructure.
This allows a smart account to use custom signature schemes, multiple signers, recovery policies, Session Keys, or other validation logic. A Paymaster can also sponsor execution costs, while a Bundler can package operations for submission to Ethereum.
UserOperations therefore provide the common format through which these account abstraction components coordinate.
What Information Does a UserOperation Contain?
A UserOperation contains the information required to identify the smart account, prevent replay, describe the requested execution, validate authorisation, estimate resource requirements, and determine how execution will be funded.
The exact representation has evolved across ERC-4337 versions. Modern implementations use a packed form when interacting with EntryPoint, so developers should not assume that every field layout shown in older documentation corresponds exactly to the latest contract interface.
Conceptually, however, a UserOperation contains several important categories of information:
- sender information identifying the smart account;
- a nonce used to prevent replay and support account-specific sequencing;
- account deployment or factory-related information when necessary;
- call data describing the action the account wants to execute;
- gas-related limits and fee parameters;
- optional Paymaster information for sponsored execution;
- a signature or other authorisation data used by the account’s validation logic.
Unlike a conventional Ethereum transaction, these fields are interpreted within the ERC-4337 framework. EntryPoint coordinates the validation process, but the smart account itself can determine whether the provided authorisation satisfies its rules.
This is what makes UserOperations useful for programmable wallets. The protocol does not need to assume that every account is controlled by one ECDSA private key operating under the traditional EOA model.
From UserOperation to On-Chain Execution
A UserOperation needs to pass through several stages before its requested action changes blockchain state. This process separates the user’s intent from the Ethereum transaction that eventually carries it on-chain.
The basic lifecycle works as follows:
- A wallet or application prepares a UserOperation for a smart account.
- The account provides the authorisation required by its validation policy.
- The operation is submitted to ERC-4337 infrastructure, commonly through a Bundler.
- The Bundler checks and simulates the operation before deciding whether to include it.
- One or more UserOperations are packaged into an Ethereum transaction targeting EntryPoint.
- EntryPoint coordinates account and Paymaster validation and then processes accepted operations.
- The smart account executes the requested call, while gas costs are settled according to the ERC-4337 rules.
This lifecycle explains why saying that a UserOperation “replaces an Ethereum transaction” requires some qualification. It replaces the ordinary transaction as the user-facing request format within ERC-4337, but Ethereum still processes a native transaction underneath.
The Bundler is responsible for creating that transaction. From Ethereum’s perspective, the resulting EntryPoint interaction is an ordinary on-chain transaction containing the data needed to process account abstraction operations.
UserOperation vs Ethereum Transaction
The easiest way to understand a UserOperation is to compare it with the transaction model used by externally owned accounts.
| Characteristic | Standard Ethereum Transaction | UserOperation |
| Created for | Primarily native Ethereum transaction flow | ERC-4337 smart accounts |
| Native protocol transaction | Yes | No |
| Submitted directly for block inclusion | Yes | No |
| Processed through EntryPoint | No | Yes |
| Can use Bundler infrastructure | Not required | Yes |
| Gas can be sponsored by ERC-4337 Paymaster | No | Yes |
| Validation model | Native transaction rules | Programmable smart account validation |
| Supports account deployment flow | Separate process | Can support deployment-related data |
| Final execution reaches Ethereum state | Yes | Yes |
The two formats therefore operate at different layers. A conventional transaction is directly understood by Ethereum’s execution protocol, while a UserOperation is interpreted through ERC-4337 contracts and infrastructure.
This distinction also prevents confusion between UserOperations and meta-transactions. Both approaches can move some transaction responsibilities away from the user, but ERC-4337 defines a broader standardised system involving smart accounts, EntryPoint, Bundlers, optional Paymasters, and dedicated validation rules.
Validation Before Execution
A major difference between ERC-4337 and conventional transaction submission is the importance of pre-execution validation.
Bundlers pay to submit transactions containing UserOperations, so they need reasonable confidence that the included operations will satisfy the required conditions. Otherwise, attackers could submit operations designed to waste Bundler resources or create repeated failures.
Simulation helps Bundlers evaluate whether an operation is suitable for inclusion. The process can check account validation, gas requirements, Paymaster conditions, nonce behaviour, and other properties relevant to successful processing.
Once the operation reaches EntryPoint, validation occurs according to ERC-4337 rules and the smart account’s own logic. If a Paymaster is involved, its sponsorship conditions also need to be satisfied.
This programmable validation is one of the reasons UserOperations are more flexible than ordinary EOA transactions. A smart account might require multiple signatures for a high-value transfer while accepting a Session Key for a restricted application action. Both can ultimately result in blockchain execution, but the account decides which authorisation policy applies.
The UserOperation provides the data that allows this logic to be evaluated.
Gas and Paymasters in a UserOperation
ERC-4337 also separates the user-facing action from the requirement that the initiating wallet personally hold ETH for every operation.
A UserOperation contains information used to determine execution costs and fee conditions. Normally, the smart account can be responsible for those costs through the ERC-4337 mechanism. Alternatively, a Paymaster can agree to sponsor an eligible operation.
This makes several fee models possible. A dApp could pay gas for new users, a wallet could allow fees to be recovered through another token, or a service could subsidise specific contract interactions.
The underlying Ethereum execution is not free. The Bundler still submits a transaction and network resources still consume gas. Account abstraction changes how that cost is funded and accounted for rather than removing it.
This separation is particularly useful for onboarding. A smart account can potentially perform its first useful operation without requiring the user to acquire ETH beforehand solely to cover gas.
Nonces and Replay Protection
UserOperations need replay protection just as conventional cryptocurrency transactions do. Without it, a valid signed operation could potentially be submitted multiple times.
ERC-4337 uses nonce mechanisms associated with the smart account and EntryPoint processing. This allows operations to be uniquely identified in the context of the account and prevents already consumed authorisations from simply being executed again.
The model can also support more flexible sequencing than the basic linear nonce behaviour familiar from EOAs. This is valuable for smart accounts that may have multiple independent workflows or authorisation channels operating at the same time.
For example, a wallet could support different logical sequences for ordinary user actions and automated operations. The implementation still needs to satisfy ERC-4337 rules, but smart account architecture can use the nonce model to avoid forcing every activity through one simple sequential queue.
Nonce handling is therefore not just a technical field inside the UserOperation. It is part of making programmable account execution reliable under parallel and automated usage.
Failed UserOperations and Security
UserOperations interact with several independent components, which creates failure cases that do not exist in exactly the same form for ordinary EOA transactions.
An operation can be rejected because its signature or account validation fails, its nonce is incorrect, gas parameters are unsuitable, or a Paymaster refuses sponsorship. State changes occurring between simulation and execution can also affect whether an operation remains executable.
Attackers may deliberately construct problematic operations to waste infrastructure resources. For this reason, ERC-4337 imposes restrictions around validation behaviour and Bundlers apply simulation and reputation-related protections where appropriate.
A malicious dApp is another risk. Account abstraction does not make every UserOperation safe simply because a smart account processes it. Users and wallets still need to understand what actions are being authorised, especially when an operation grants token approvals, interacts with unfamiliar contracts, or transfers valuable assets.
The security advantage comes from programmability. Smart accounts can implement stronger policies than the all-or-nothing authority of a traditional private key, but those policies must still be designed and implemented correctly.
Why UserOperations Matter for Smart Accounts
UserOperations are the transaction-like language of ERC-4337. They give smart accounts a standard way to describe actions while leaving room for programmable validation, alternative fee models, and specialised transaction submission infrastructure.
This makes them a foundational component behind many account abstraction features. Session Keys can authorise restricted operations, Paymasters can sponsor their gas, and Bundlers can collect and submit them through EntryPoint. Each component has a separate function, while the UserOperation carries the information needed to connect those functions.
For users, most of this infrastructure can remain invisible. A wallet interface may simply show a transfer, swap, game action, or account recovery request. Behind that interface, however, the wallet can create a UserOperation instead of asking the user to construct and fund a conventional EOA transaction.
The significance of UserOperations is therefore not that they replace Ethereum transactions at the protocol level. They create an additional programmable transaction layer for smart accounts, allowing ERC-4337 to deliver account abstraction while continuing to use Ethereum’s existing execution and consensus infrastructure.