Ethereum transaction successful but tokens missing: what to check

A successful Ethereum transaction does not, by itself, prove that the intended ERC-20 tokens reached the intended account. Success reports whether the transaction as a whole completed without reverting. Confirm the action that ran, the exact token contract, the recipient and the transfer evidence before treating it as a completed payment.

Start with the original transaction hash on Ethereum Mainnet. Do not send another payment merely to test a stale wallet display. This guide describes a read-only inspection of an included transaction, not a recovery service or instructions to sign another transaction.

Read Success at the right level

EIP-658 defines the receipt status as the result of the top-level call. Status 1 means success and 0 means failure; JSON-RPC represents them as 0x1 and 0x0. That is a statement about execution, not a checklist of every outcome you wanted from the app.

A contract can handle an unsuccessful inner operation without reverting the whole transaction. The ERC-20 standard also explicitly requires callers to handle a returned false. Do not assume every token implementation reports unsuccessful transfers by reverting.

The receipt’s status is not the true or false returned by a token method. The receipt reference exposes transaction status, block and logs; it does not turn the status field into the return value of an inner call. Decoded execution details can help, but a trace error or a method label alone needs interpretation in the context of the complete action.

If the overall receipt is Failed, use the failed transaction and gas guide. If it has not been included, use the pending transaction guide. The checks here concern an included transaction marked Success.

Establish whether the action was a transfer

An app may ask for an approval before a later transfer, swap or deposit. Under ERC-20, approve sets a spending allowance; it does not itself send the approved amount to the spender. Its successful transaction can therefore leave the token balance unchanged.

Look at the action and decoded input where available. Record the transaction’s destination contract and the operation you intended. The transaction’s To field can be a router or another contract rather than the ultimate token recipient. Do not equate that field with the recipient recorded by a token transfer.

Observation	What it establishes	What remains to check
Receipt status Success	Top-level execution succeeded	The intended action’s result
Successful approval	A permission action ran	A separate transfer or protocol action
Matching Transfer log	That contract emitted a transfer record	Identity, amount and resulting state
Current token balance	The account’s quantity at that read	Other activity and observation time

Keep the hashes of separate steps. A successful approval followed by a transfer is two records; one Success label cannot stand in for both. Nor does an app’s completion message establish that an exchange credited a deposit or a bridge completed on another chain. Those services need their own records and rules.

Match the transfer record to the exact token and recipient

The standard’s Transfer event records a sender, recipient and amount. In the receipt’s logs, check the address of the contract that emitted the record, then compare its decoded fields with the payment you intended. A familiar symbol is insufficient: another contract can use the same name or emit a similar-looking event.

Verify the network and full token contract address through a source you already trust. Compare the full recipient address, not just a shortened prefix and suffix. Our wallet address and token contract guide explains which address identifies the asset and which identifies the account.

Check the amount as well as the event’s presence. ERC-20 includes zero-value transfers, so finding a Transfer event does not establish a positive payment. If the log shows a raw integer, use the token’s verified decimal scale to interpret it. Do not apply formatting twice or invent a scale when metadata is unavailable.

For example, suppose an intended payment is 25 tokens. A successful approval for 25 tokens is not that payment. A transfer record for zero tokens is not that payment either. A record for 25 tokens from a different contract still does not establish receipt of the intended asset. These are hypothetical comparisons, not observations from a live wallet.

Compare state without attributing every change to this hash

Read the recipient’s balance for the same token contract on the same network. The standard’s balanceOf(account) reports the account’s token balance, not an explanation of what one transaction changed. A wallet gallery or a fiat portfolio total may be delayed or describe something else.

Record the block or time of the read. The latest balance can include transfers after the transaction you are checking. Even comparing balances at the preceding and containing blocks may include other transactions in that block. Do not claim that one difference isolates this hash without examining the other activity.

If the evidence disagrees, keep the disagreement visible. Custom token mechanics, an unsupported reader or a protocol’s internal accounting may need the exact contract’s documentation and support. A contract’s log is not a certificate of authenticity or safety. A failed balance query is unknown, not a zero balance.

Keep a record before deciding on another payment

Use a familiar explorer or contract reader reached through a trusted route. No wallet connection, signature, approval or recovery phrase is needed for these public checks. This procedure is based on the primary documentation checked on 26 October 2026; it was not tested on a live transaction for this article.

1. Identify the original transaction. Save Ethereum Mainnet, the full hash, sender, block and overall receipt status.
2. Identify the actual action. Distinguish approval from transfer, swap or deposit. Save any separate hashes belonging to the flow.
3. Match the token evidence. Record the emitting contract, transfer sender, recipient and amount with its units. Compare them with the intended asset and account.
4. Check the resulting state. Read the exact token balance or relevant protocol record, recording the block or time and other activity that could affect it.
5. Leave unresolved parts unresolved. Preserve missing logs, failed reads or unexplained differences. Consult the wallet or protocol’s official support with public transaction details before deciding whether another transaction is appropriate.

Your inspection is complete when you can explain what succeeded and what evidence supports the intended receipt. If the transaction succeeded but the payment remains unverified, label it that way. The Success badge is useful evidence; it is not permission to ignore the asset, recipient or amount.