Investigate a Successful Transaction With No Expected Token Row

A successful execution status answers whether the top-level transaction succeeded. It does not, by itself, identify the asset you expected or prove that a wallet has discovered and displayed that asset.

Identify the operation that succeeded

Read the transaction destination and decoded operation on the correct explorer. A successful approval changes permission; it is not an exchange receipt. A transfer to another account should not be expected to increase the sender’s balance. Write down the actual operation before interpreting a green success label as proof of a particular token purchase. Keep an unrelated quote screenshot separate from this evidence.

Follow the expected asset to its recipient

For a standard ERC-20 transfer, examine token transfer events and compare the full recipient address and token contract with your intended result. ERC-20 specifies a Transfer event for transfers, while EIP-658 describes the top-level receipt status. These are different pieces of evidence. An explorer label is convenient, but the network and full contract are needed to distinguish similarly named tokens.

Compare the display with chain evidence

Confirm the wallet is viewing the same account and chain as the receipt. Then check whether the interface supports showing that token at all. The inspected RunixCoin mainnet asset list contains native-coin rows; a missing WETH or USDC row does not establish a zero ERC-20 balance. Do not import a token using an address copied from an unsolicited message. Use the issuer’s official registry to establish identity first.

Record what remains uncertain

For an illustrative investigation, a successful approval plus no USDC row establishes neither a swap nor missing swap proceeds. A verified USDC transfer to the intended account plus no row instead points toward a display or discovery question. Note the observation time because later transfers may change a balance. If events, recipient or contract remain unclear, preserve that uncertainty. Avoid sending a second transaction to test whether the first display was wrong.

References and verification

Reviewed . Product limits reflect inspected public interface code. These are educational checklists, not reports of tested mainnet transactions; browser behavior and execution were not verified.