An ERC-4337 UserOperation is a smart-account instruction submitted to a bundler. The bundler includes it in an Ethereum transaction sent to an EntryPoint contract. Keep the operation hash and transaction hash separately: bundle inclusion does not prove the requested action succeeded, and a paymaster shifts who funds gas rather than removing the cost.
Keep the instruction and its delivery transaction together
ERC-4337 adds an application-layer route for account actions. A bundler collects operations and submits a transaction calling EntryPoint's handleOps. The account supplies its own authorization logic; the standard does not prescribe one universal meaning for its signature field. These roles are defined in the ERC-4337 specification.
The operation describes what the smart account should execute. The containing transaction delivers one or more operations to EntryPoint. Treating their identifiers as interchangeable loses the connection between a user's request and its individual result.
| Record | UserOperation | Containing Ethereum transaction |
|---|---|---|
| Account acting | Smart account identified by sender | Bundler's transaction sender |
| Identifier to retain | userOpHash | Transaction hash |
| Replay and ordering state | EntryPoint nonce for the smart account and nonce key | Transaction nonce of the bundler's sender |
| Requested call | Account execution instructions in callData | Call to EntryPoint containing the bundle |
| Fee evidence | Operation gas charge and account or paymaster responsible | Network fee for the complete transaction |
| Result to examine | This operation's execution and application effects | Whether the enclosing transaction completed |
This article uses the tagged reference EntryPoint v0.9.0 for implementation details. Identify the chain, deployed EntryPoint and account implementation before applying its behavior. A wallet being a smart wallet does not establish that a particular action uses this route. The example also excludes account deployment, EIP-7702 delegation and aggregated signatures.
Signing remains an authorization decision. Decode the target, value and any batched calls through the account's execution format. The typed-data signature guide explains why readable fields still require a permission check. A familiar wallet prompt cannot substitute for knowing which contract enforces the requested action.
Follow a swap beyond the bundler's response
The draft ERC-7769 bundler API describes returning userOpHash after simulation and pool acceptance. That response is useful evidence of acceptance by that service. It is not an inclusion receipt. Check the provider's supported EntryPoints and receipt methods before relying on this interface.
Consider this hypothetical Ethereum sequence. A deployed account A requests swap U2 using nonce key 0, sequence 7. Paymaster P authorizes its gas. Two unrelated operations, U1 and U3, belong to other accounts. The swap has a minimum-output condition, and its account implementation propagates a failed swap call as a revert.
Assume the bundler's full local execution simulation passes at the listed times. No funds move during those simulations. The eventual bundle completes, there is no reorganization during this example, and P's deposit remains sufficient. U2 and T are teaching labels; actual records need their full, distinct hashes.
| Time | Observation | What the application should record |
|---|---|---|
| 10:00:00 | A signs U2 | Authorization prepared; no inclusion |
| 10:00:01 | Bundler accepts U2 and returns its operation hash | Accepted by this endpoint |
| 10:00:04 | Final local simulation passes | Result under that simulated state |
| 10:00:05 | Bundler broadcasts transaction T containing U1, U2 and U3 | T attached to U2; inclusion unresolved |
| 10:00:08 | Another transaction changes the pool price | Earlier simulation is no longer the same state |
| 10:00:12 | T is included; U1 and U3 execute, U2's swap reverts | T succeeds; U2 fails; reconcile its gas and nonce |
The standard's simulation discussion explains that operation validation depends on EVM state, which other operations or transactions can change. A simulation observes an assumed state; it does not reserve the swap price or a sponsor's future balance.
For U2, inspect eth_getUserOperationReceipt using its operation hash. Its specified receipt fields include operation success, gas cost and the containing transaction receipt. The latter covers the whole bundle. Save both results instead of flattening them into one green “completed” label.
In the tagged EntryPoint execution implementation, an account-call revert can be caught, charged and reported while processing continues. Some failures can instead revert the enclosing bundle. The timeline deliberately describes the first case; it is not a promise that every failure is isolated.
Reconcile the sponsored charge in native units
The bundler funds the outer transaction's network fee. EntryPoint accounting then charges the operation's account or paymaster deposit and compensates the bundle beneficiary. Sponsorship changes the funding relationship; consumed computation still has a payer.
OpenZeppelin's paymaster documentation describes signed sponsorship as one implementation and requires funded ETH for the operations it sponsors. A sponsor's permission and available balance are separate checks. A service may also impose eligibility rules or charge the user under its own arrangement; inspect those terms before calling an action free.
Continue the hypothetical U2 example with these receipt inputs. They are illustrative values, not measured network costs. Assume the normal fee-accounting path, no unused-gas penalty and no separate token charge from P.
| Input or result | Illustrative value | Interpretation |
|---|---|---|
| U2 maximum fee per gas | 40 gwei | Signed fee cap |
| U2 priority fee cap | 2 gwei | Maximum priority component |
| Inclusion block base fee | 20 gwei | Block input |
| U2 accounted gas | 100,000 gas | Full operation accounting, not only swap gas |
| Effective operation price | 22 gwei | Minimum of 40 and 20 + 2 |
| U2 charge | 0.0022 ETH | 100,000 × 22 × 10⁻⁹ |
| P's deposit before U2's net charge | 0.0500 ETH | Example accounting balance |
| P's deposit after that charge | 0.0478 ETH | 0.0500 − 0.0022 |
The price calculation follows _getUserOpGasPrice in EntryPoint v0.9.0. Its gas accounting includes overhead and can apply unused-gas penalties. The event interface identifies the actual operation charge and gas total. Use that total rather than reconstructing a bill from the inner swap alone.
P loses 0.0022 ETH of deposit even though the intended swap did not complete in this scenario. The 40 gwei cap does not mean P paid 0.0040 ETH. Nor does U2's 0.0022 ETH describe T's entire network fee: T also carries other operations and transaction overhead.
Keep network-specific charges separate when extending the worksheet to a rollup. The blob fees versus L2 gas guide explains why one execution component is insufficient to describe every rollup bill. These Ethereum example numbers are not a universal L2 pricing formula.
A failed action can still consume the operation nonce
EntryPoint's v0.9.0 NonceManager separates a nonce into a 192-bit key and a 64-bit sequence. Its state belongs to the smart account and key, independently of the bundler sender's ordinary transaction sequence. Account code may impose further restrictions.
In the hypothetical timeline, validation advances A's key-0 sequence from 7 to 8 before the caught execution failure. Because T completes, that advancement remains. U2's failed swap does not make sequence 7 available again.
If T were included but reverted entirely, EntryPoint's operation-nonce and deposit updates would roll back. The bundler would still spend network gas and consume its ordinary transaction nonce: Geth's transaction state transition increments that nonce before the contract call and settles gas after it. Those are separate ledgers to reconcile.
Record the outcome as “included, execution reverted, sequence consumed, sponsor charged.” Creating another operation with sequence 8 is a new attempt and needs a fresh decision about price, expiry, permission and gas. If the original outcome is uncertain, first recover its evidence; a new sequence can create another live authorization.
The ordinary EVM nonce guide remains relevant to T's sender. Keep its recovery record separate from A's operation sequence so an apparent gap in one account is not repaired using the other's nonce.
Resolve missing evidence before retrying
Different stopping points require different investigations. The following table is a recovery method, not a list of guaranteed provider error messages.
| Observation | Evidence to recover | Decision before another attempt |
|---|---|---|
| Submission rejected | Exact validation error, chain and supported EntryPoint | Correct the identified mismatch or funding issue |
| Operation hash returned, no receipt | Endpoint, operation fields, elapsed time and any containing transaction | Establish whether the attempt remains pending or was included elsewhere |
| T succeeds but U2 reports failure | U2's reason, gas charge and nonce state | Repair the failed prerequisite and reassess authorization |
| U2 reports success but expected tokens are missing | Decoded calls, operation logs and recipient balances | Reconcile the application effect before declaring the swap complete |
| Recent inclusion disappears | Canonical block reference and current receipt evidence | Reopen the operation's tentative outcome |
A null receipt is missing inclusion evidence, not proof that the authorization is permanently unusable. Do not “fix” a lookup by sending the operation hash to a transaction-only receipt method. Recover the mapping through an operation-aware endpoint or EntryPoint event evidence.
Likewise, a successful execution flag means the relevant call completed without a revert under that interface. The application must still verify its expected economic effects. An account's batch policy can matter: a method that tolerates a failed subcall needs more detailed outcome checks than a method that reverts the whole account call.
Keep a completion record that another person can inspect
For each requested action, retain the chain, account, EntryPoint version and address, operation hash, nonce key and sequence, decoded calls, sponsor terms, and containing transaction hash when available. Add the canonical block reference, operation result, actual gas charge and the application outcome being checked. Avoid retaining a usable signature in ordinary support logs.
Before integrating a wallet route, validate four controlled cases: a valid sponsored operation, a rejected sponsorship, a swap that reverts after validation, and a lost submission response. For each, verify that the interface shows the operation's actual state and that retry handling cannot silently create another authorization.
For rollups, add a separate settlement field. The optimistic versus ZK rollup comparison explains another layer of verification; an operation receipt does not collapse execution, proof processing and settlement into one event.
Close the record only when it answers four concrete questions: which operation was authorized, which transaction carried it, what the requested action actually did, and whose funds paid for the attempt.