UserOperation Hash vs Transaction Hash: Track an ERC-4337 Payment

A UserOperation hash identifies an ERC-4337 operation; the blockchain transaction hash identifies the transaction that includes its bundle. They are different lookup keys. Find the operation receipt to connect them, then read the operation's own success and payment effects instead of relying only on the outer transaction's status.

Why a wallet can give you a hash an explorer cannot find

ERC-4337 describes UserOperations being collected by a bundler and submitted through an EntryPoint contract. The wallet's initial reference can therefore identify an operation awaiting inclusion, rather than an already broadcast ordinary Ethereum transaction. A hexadecimal value that looks like a transaction hash does not tell you which kind it is.

Do not infer the reference type from the number of characters alone. Ask which wallet field supplied it: UserOperation hash, transaction hash or a provider's internal request ID. Those labels describe different records. Preserve the network and the original reference before replacing it with a guessed value or concluding that an explorer's empty search means the payment disappeared.

Follow the reference from acceptance to inclusion

The ERC-7769 RPC specification defines the relevant lookup methods. A successful eth_sendUserOperation response indicates acceptance into the client's operation pool under its stated validation flow. It is not a transaction receipt and does not establish that the intended action has already executed.

The operation lookup can provide an outer transaction hash after inclusion. The operation receipt includes its own result and a nested transaction receipt for the whole bundle. Pimlico's receipt-method documentation illustrates both identifiers in one response. Use that connection rather than attempting to transform one hash into the other by editing its text.

1. Confirm the chain and whether the wallet's reference is a UserOperation hash. Keep the wallet's stated account and EntryPoint context if available.
2. Use the wallet's supported operation tracker or an appropriate bundler lookup to request the UserOperation receipt.
3. If a receipt is available, locate the containing transactionHash and open it on the correct network's explorer.
4. Match the receipt to your UserOperation and account, then read the operation-level success rather than stopping at the bundle status.
5. Verify the intended recipient, token contract and actual amount transferred. A successful operation can perform an action other than the payment you expected.
6. If a service is receiving the payment, reconcile its order or deposit separately and provide the linked references to support.

One successful bundle can contain a failed operation

The EntryPoint's interface includes a UserOperationEvent carrying the operation hash and a success flag. That provides a way to distinguish the outcome of a particular operation within a larger transaction. Do not read an unrelated operation's event as your payment just because it appears in the same receipt.

Consider a fictional bundle containing operation Cedar and operation Maple. The outer transaction finishes successfully. Cedar's account call succeeds, while Maple's call reverts. A person tracking Maple cannot report payment success solely from the outer receipt's green status. They need Maple's own result and, where relevant, its execution reason.

Even operation-level success is not an instruction to stop checking the asset movement. A submitted action could be an approval, account setup or an unrelated contract call. A wallet or application might also implement its own handling inside a call. The chain can successfully execute the action it was given while that action still differs from the payment the user had in mind.

Interpret a missing receipt without inventing a final result

Pimlico documents null when a receipt is unavailable. Depending on the method and provider, a missing result can require checking inclusion, network, endpoint support and history coverage. It is not a universal confirmation of failure, a refund or permission to pay again.

Provider lookups also have operational limits. Alchemy's receipt documentation describes a bounded historical scan and a way to position its lookup window. A request searching the wrong history range is different from evidence that an operation never existed. Use the provider's documented scope rather than assuming all endpoints keep identical records.

The ERC-4337 documentation also makes the EntryPoint relationship explicit. Networks and supported EntryPoint versions matter. A copied reference searched on a different chain or against an unsupported execution context will not answer the question about the original payment.

Do not confuse fees, account identity and payment amount

The outer transaction's sender can be the bundler rather than the account whose operation you initiated. Seeing an unfamiliar outer sender is therefore not sufficient evidence that your wallet was replaced. Use the operation's account and effects to reconstruct what actually happened, while still checking that the recipient and asset are correct.

The bundle's total gas usage also describes a different scope from one operation's execution cost. A sponsored-fee workflow adds another accounting layer, not a guarantee that every action is free or that a particular payment completed. Keep the payment's token amount separate from gas and service-side charges when asking support to reconcile it.

• Network and wallet/application version, with the exact reference type supplied by the interface.
• UserOperation hash, containing transaction hash if found and the relevant EntryPoint/account.
• Operation result and any available execution error, rather than only a screenshot of the outer green status.
• Intended asset contract, recipient and amount, plus the receiving order or deposit reference.

If the original outcome remains uncertain, resolve it before authorizing a fresh payment. Rebuilding can create a different operation; a missing display response does not establish that the earlier one cannot execute. Support does not need the seed or private key to locate a public operation receipt or containing transaction.

For token-payment effects after you find the transaction, use the existing guide to ERC-20 receipts beyond a Success label. For a no-account swap, distinguish the exchange order from both blockchain references. The service's how-it-works page describes the exchange flow; it does not make a UserOperation hash interchangeable with the transaction evidence a receiving platform needs.