A blockchain explorer can show a transaction as successful while the tokens still seem to be missing from the wallet. Those two observations are not necessarily contradictory. On Ethereum-style networks, a successful transaction receipt means the top-level transaction completed without reverting and its state changes were accepted by the chain. It does not, by itself, prove that the token you expected was credited to the address, on the network, or in the form you intended. Ethereum's JSON-RPC documentation defines transaction receipt status 1 as success and 0 as failure; the receipt also contains logs that can show what the transaction actually emitted. See the official Ethereum JSON-RPC documentation.
Start with evidence, not another transaction. You need the transaction hash, the network on which it was confirmed, the recipient address, and the token contract involved. If you sent to an exchange, also identify the exact deposit network and any memo or destination tag that the exchange required.
The most useful first question is: does the blockchain itself show that the intended address owns the intended token? A wallet app is an interface to blockchain state; it is not the place where the assets are physically stored. Ethereum's wallet guide explicitly notes that accounts live on the blockchain and recommends using a block explorer to check a transaction by address or transaction ID. See Ethereum's wallet guide.
Not always. It means the transaction executed successfully at the protocol level. A transaction may call a smart contract that performs several operations, and the explorer's overall status summarizes the top-level execution. To establish that an ERC-20 transfer occurred, inspect the transaction's token-transfer section or logs and confirm the expected Transfer event, token contract, sender, recipient, and amount.
The ERC-20 standard defines both a balanceOf function for checking an address's token balance and a Transfer event for token movements. The official Ethereum description is available in the ERC-20 token standard documentation. This is why an explorer's green “Success” badge should be treated as the beginning of the investigation, not the final proof that the exact asset reached the intended wallet.
| Field | What to verify | Why it matters |
|---|---|---|
| Network | The chain where the transaction was confirmed | A token on Ethereum, Base, Arbitrum, BNB Smart Chain, or another network is a separate on-chain balance even when an address format looks the same. |
| Recipient | The full destination address | A successful transfer to the wrong address is still a successful transfer. |
| Token contract | The contract address, not only the token symbol | Different tokens can share a name or ticker, and counterfeit tokens can imitate legitimate ones. |
| Amount | The transferred amount after any token-specific mechanics | Some tokens can use fee-on-transfer or rebase behavior, so a displayed amount may differ from a simple expectation. |
| Token balance | The recipient's balance on the explorer | If the explorer shows the balance at the address, the problem may be wallet display rather than custody. |
This is one of the most common explanations for “successful but missing.” A token exists on the network where it was transferred. If a wallet is currently displaying another network, the token may not appear even when you control the same-looking EVM address.
MetaMask's current help documentation tells users with a missing token to check whether the transaction is confirmed, verify the correct network, and compare the account's balance on the appropriate block explorer. See MetaMask's token help center.
If you control a self-custody EVM account and the token was sent to your address on another EVM network, switching to or adding the correct supported network may reveal it. That does not mean the token has “moved” between networks; you are simply viewing the blockchain where it already exists. Do not bridge or resend anything until you have confirmed the balance on that network.
If the explorer shows the correct token balance at your address, the most likely issue is presentation: the wallet has not detected or displayed that token. Many wallets maintain token lists or use token-detection services, and less common assets may need to be added manually.
MetaMask says it automatically displays many ERC-20 and SPL tokens but does not maintain an authoritative list of every token. Its official instructions allow users to add an unlisted token by contract address. See How to display tokens in MetaMask.
Use the contract address from an authoritative source, such as the project's official documentation or a verified explorer entry. Do not rely only on a ticker symbol sent in a message or shown in an unsolicited token. A fake token can use a familiar name while pointing to a different contract.
A centralized exchange deposit adds another layer. The blockchain can confirm that funds reached an address while the exchange still does not credit your account. The exchange may require a specific network, token version, minimum deposit, number of confirmations, or destination tag/memo.
Coinbase, for example, states that deposits must use an asset and network it supports and warns that deposits sent on an unsupported network may not be credited. Its official guidance is in Unsupported crypto deposits. Coinbase also explains that some assets require a memo or destination tag so a shared exchange address can be mapped to the correct customer account; see Deposit “Pending” — Memo not included.
For an exchange deposit, do not assume that controlling the destination address is enough—you normally do not control the exchange's private keys. Gather the transaction hash, network, token contract, destination address, amount, and memo/tag if applicable, then use the receiving platform's official support channel. Whether recovery is possible depends on that platform and the specific asset/network combination.
Yes. Cross-chain transfers can involve more than one stage. A transaction can succeed on the source chain while the bridge still has to relay, prove, finalize, mint, or release assets on the destination chain. The exact workflow depends on the bridge.
For a concrete example, Arbitrum's official bridge documentation says deposits from a parent chain to a child chain can take time to arrive and instructs users to view the destination network in their wallet. Withdrawals from Arbitrum One or Nova to Ethereum have a protocol-specific waiting period before funds can be claimed. See the Arbitrum bridge quickstart.
Therefore, if the transaction was a bridge operation, use the bridge's official status page or documentation rather than judging completion from the source-chain transaction alone. Avoid random “bridge recovery” websites reached through search ads or unsolicited messages.
If the on-chain recipient does not match the address you intended, the wallet display is not the main problem. Public blockchains generally do not provide a universal undo button after confirmation. Ethereum's wallet guidance states that a confirmed transaction cannot simply be canceled or returned.
Recovery then depends on who controls the receiving address. If it is another one of your self-custody accounts, you may still control the funds. If it belongs to an exchange or service, only that service can determine whether it can help. If it belongs to an unknown third party, there may be no technical mechanism forcing a return.
Yes. Some tokens have mechanics that affect how balances or transferred amounts appear. MetaMask specifically notes examples such as rebase tokens and tokens with transfer fees when troubleshooting balances. These designs can make the expected amount differ from the amount ultimately shown.
There is also a separate ERC-20 hazard: sending tokens directly to a smart contract that was not designed to handle them. Ethereum's ERC-20 documentation warns that a contract can receive ERC-20 tokens even if it lacks logic to recover or process them. In that case, the transfer can be valid on-chain while the tokens are effectively stuck in the contract.
Be especially cautious if someone asks you to connect your wallet to a “recovery” site, sign an unexpected approval, pay an additional fee to unlock tokens, or reveal your recovery phrase or private key. A legitimate support process should not require your seed phrase. MetaMask's token guidance warns users not to interact with unfamiliar sites or links associated with suspicious tokens.
Also remember that a token appearing in your address does not prove it has value or is legitimate. Unsolicited tokens can be used to lure users into malicious websites. Verify the contract through the official project source before interacting with it.
The decision point is the on-chain destination balance. If the correct explorer shows the intended token at your self-custody address, the asset is generally present on that chain and you should investigate wallet network or display settings. If the explorer shows the token at a different address, address ownership becomes the key issue. If the recipient is an exchange address, the exchange's crediting rules matter. If the transfer is cross-chain, destination finalization matters. And if the transaction has no expected token transfer at all, a green success status does not establish that the token movement you intended occurred.
This distinction prevents the most common mistake: treating “Success” as a promise that every off-chain interface, exchange balance, bridge stage, or wallet token list must immediately show the expected result. First establish what the blockchain recorded; then troubleshoot the layer that interprets that record.
This article was checked against primary documentation available in September 2026, including Ethereum's JSON-RPC and ERC-20 documentation, MetaMask's token-display and missing-balance guidance, Coinbase's deposit-support and memo guidance, and Arbitrum's official bridge documentation. Examples use Ethereum/EVM terminology where useful, but the broader troubleshooting principle—verify the chain, recipient, asset identifier, and receiving platform's rules—also applies to other blockchains. Exact wallet menus, exchange support, bridge timing, and supported networks can change, so confirm current details on the relevant official source before taking action.
A successful blockchain transaction does not always mean a wallet will display the tokens. Learn how to verify the network, recipient, token contract, explorer balance, bridge status, and exchange deposit details safely.
Why liquid staking tokens can trade below redemption value, how withdrawal queues, liquidity, risk and time affect the discount, and when swapping or redeeming may make more sense.
Use this practical airdrop safety checklist to verify official claim contracts, inspect wallet permissions, spot malicious signatures, and respond to suspicious approvals.
Learn how to monitor validator performance and commission changes from primary blockchain data, compare the trade-offs, and build a reliable delegator check routine.
Learn how to match crypto transfers across exchange and wallet exports, preserve cost basis, separate fees, and review Form 1099-DA before calculating gains.
Learn how MEV protection works for retail DEX swaps, how private transactions reduce sandwich risk, how slippage affects exposure, and what trade-offs to check before you trade.
Understand how account abstraction wallets use session keys, paymasters, and recovery rules, plus the permissions and risks to check before signing.
Avoid crypto withdrawal mistakes by checking the receiving chain, token contract, address, and memo or destination tag before you send funds.
Before delegating restaked assets, verify an operator’s AVS exposure, slash conditions, loss limits, redistribution rules, and exit delays with this practical checklist.
Learn what crypto proof of reserves can verify, what liabilities it may omit, and how to check an exchange’s snapshot, customer balances, and audit scope.
