The wallet says confirmed. The explorer page shows a green tick. And the tokens are not in the account. Nothing is stuck and nothing needs resubmitting: the status field answered a narrower question than the one being asked. This is what that field certifies, what it leaves out, and where the answer you are actually looking for is recorded.
What a success status actually certifies
EIP-658 placed a status code in the transaction receipt and defined its two values in one line: 0 indicating failure, due to any operation that can cause the transaction or top-level call to revert, and 1 indicating success. A block explorer renders that 1 as a tick.
The scope of that definition is what matters here. The code describes the top-level call. It reports that the outermost piece of execution finished without reverting, and it reports nothing beyond that: not that a particular token balance changed, not that the amount you intended moved, not that the contract you called did the thing you asked of it. A receipt whose status is 0 is what an explorer labels reverted. A receipt whose status is 1 rules that out and stops there.
Every case below lives in that gap. The chain recorded what happened in full. The one-word summary at the top of the page was answering a different question.
| The question you are asking | Where the answer is recorded |
|---|---|
| Did it reach a block | The block number on the receipt |
| Did the outermost call avoid reverting | The receipt status code |
| Did this token balance change | The transfer events in the logs |
| Did my user operation do its work | The success flag on its own event |
Why a token transfer can fail without reverting
The ERC-20 token standard declares transfer as a function that returns a boolean, and it is emphatic about the consequence: callers must handle false from returns bool success, and callers must not assume that false is never returned. Failure is permitted to arrive as a return value instead of as a revert.
When a token reports failure that way, the outcome depends on the contract that called it. A caller that inspects the boolean can revert on false, and the receipt comes back with status 0. A caller that discards the boolean carries on, the outermost call completes, and the receipt says success while the balance never moved.
Return values differ in a second way. OpenZeppelin's SafeERC20 library describes itself as wrappers around ERC-20 operations that throw on failure when the token contract returns false, and adds that tokens returning no value at all are also supported, with non-reverting calls assumed to be successful. A library written to normalise those return values is direct evidence that they are not uniform.
Failures a contract deliberately swallows
A contract can call another contract and decide in advance not to fail alongside it. Solidity's try and catch construct, and the low-level call that hands back a success flag rather than propagating a revert, both exist so that execution can continue past an inner failure. Routers, batchers and relayers use that deliberately: one leg of a batch fails, the remaining legs settle, and the transaction as a whole is a success.
Seen from the receipt, this is indistinguishable from the previous case. An inner call failed, the outer call absorbed the failure, and the status field records the outer result. The inner failure is still on the chain, but it sits in the execution trace and in what the logs do not contain rather than in the status field.
An insufficient allowance is one route into this shape. A contract that moves your tokens with transferFrom is spending inside a limit you set with a token approval. When that limit is smaller than the amount being pulled, the inner call fails, and whether the whole transaction fails with it is decided by the caller rather than by the token.
When the amount that arrives is smaller than the amount sent
A third case involves no failure at all, and the arithmetic still comes out wrong. A token contract can deduct something inside its own transfer function, crediting the recipient with less than the sender handed over. Send 5,000 units of a token that takes 3% on every transfer and 4,850 arrive. The receipt says success, the transfer event exists, and the number inside it is not the number that was typed.
Rebasing tokens produce a related mismatch from the opposite direction. Their balances are rewritten by the contract rather than moved by a transfer, so a balance can change with no transfer event behind it. Reconciling a wallet display against the amounts in the transaction history will not add up for such a token, and neither reading is faulty.
What a paymaster transaction failed message means
Under account abstraction what you submit is not a transaction. ERC-4337 defines a UserOperation object with a mempool of its own, and a bundler that packs those objects into one ordinary transaction addressed to an EntryPoint contract. A paymaster is a contract that agrees to pay for the transaction instead of the sender. A failure message naming the paymaster covers two situations that share nothing except the word failed.
The first is rejection during validation. ERC-4337 requires that if any validateUserOp call fails, handleOps must skip execution of at least that user operation, and it requires bundlers to reject invalid operations from their mempool instead of putting them on chain. A paymaster that declines to sponsor the call, that has too little deposit left, or that fails its own validation puts the operation in this branch. Nothing was included, nothing was charged, and there is no hash to look up, because the failure happened before the chain saw the operation.
The second happens after inclusion, and it is the one that produces the tick. Once validation has passed, the specification states that the execution will happen and only done once, and also guarantees the fee payment. The EntryPoint then emits an event for each user operation carrying a success flag, documented as true if the sender transaction succeeded and false if it reverted, next to the actual amount paid by the account or the paymaster. The bundle transaction succeeds, the paymaster is charged, and the flag on your operation is false. All three hold at the same time.
| Where it failed | Reached a block | Who paid | What there is to look up |
|---|---|---|---|
| Validation, before inclusion | No | Nobody | An error from the bundler or the wallet, and no on-chain record |
| Execution, after inclusion | Yes | The account or the paymaster | A successful transaction whose user operation event carries a false success flag |
Where to look instead of the status field
Token movements are recorded as events in the logs. An explorer's token transfer view is a rendering of those events, so if your address does not appear in one of them, that token did not move, whatever the status says. The logs are the check; the status is the summary.
Three questions do the work. Does a transfer event involving your address exist at all, or is that section of the page empty? If one exists, is its amount the amount that was sent? And is the contract emitting it the token contract you meant, on the network you meant?
A fourth possibility survives all three checks: the transfer happened exactly as instructed and is being looked for in the wrong place. A second address derived from the same seed phrase, the same address on a different network, and a token that a wallet will not display until its contract is added by hand each produce an empty screen next to a perfectly good receipt.
The bottom line
A receipt status is a statement about the outermost call and about nothing else. Success means the transaction did not revert. It has never meant that a token moved, that the right amount moved, or that the contract did what was wanted with it. Those facts live in the event logs, and under ERC-4337 in a success flag that is kept separate from the status of the transaction carrying it.
When a transfer goes missing behind a green tick, work down the layers in order: a transfer event, then its amount, then the token contract and the network. To keep learning the fundamentals, follow more from Bitbase Academy.
Related reading
Other Bitbase articles on this topic:
- How to Switch RPC Endpoints Safely
- Maximum Transaction Fee Exceeded: What That Wallet Warning Means
- RPC Rate Limit Exceeded and How to Stop Hitting It
- Global Liquidity, M2 and Bitcoin: A Measurement Guide
Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of September 2026; refer to the latest official information.
References
[1] Ethereum Improvement Proposals, EIP-20: Token Standard (the transfer function and its boolean return value) eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-658: Embedding transaction status code in receipts (the status field of the transaction receipt) eips.ethereum.org
[3] Ethereum Improvement Proposals, ERC-4337: Account Abstraction Using Alt Mempool (validation, bundlers and paymasters) eips.ethereum.org
[4] eth-infinitism, account-abstraction, contracts/interfaces/IEntryPoint.sol at tag v0.7.0 (the UserOperationEvent declaration) raw.githubusercontent.com
[5] OpenZeppelin, openzeppelin-contracts, contracts/token/ERC20/utils/SafeERC20.sol at tag v5.1.0 (the library doc comment) raw.githubusercontent.com
