Why Does a Transaction Show as Successful but the Tokens Never Arrived?
A transaction can show as successful on the block explorer while the tokens never reach your wallet because "success" only means the transaction executed without reverting - not that it did what you expected. The most common causes are an incorrect recipient address, a token transfer rejected by the receiving contract, or a front-end interface that failed to submit the intended transaction. You need to check the transaction's internal transfers and event logs, not just its status.
How to Diagnose the Problem
Step 1: Copy the Transaction Hash and Open It in a Block Explorer
Every transaction has a unique hash (txid). Find it in your wallet history or from the exchange or service you used. Paste it into Etherscan (or the relevant explorer for that chain). The page will show a green checkmark and "Success" if the transaction did not revert. Ignore that for now.
Step 2: Look at the "Token Transfers" Tab
On Etherscan, the transaction page has tabs: "Overview", "Internal Txns", "Token Transfers", and others. Click "Token Transfers". This table shows every ERC-20, ERC-721 (NFT), or other token transfer that occurred inside that transaction.
- If you see your token (by contract address, not just name) moving from the sender to the intended recipient, the token arrived. The problem is in your wallet's display, not the chain.
- If you see no token transfers at all, the transaction did not move any tokens, even though it succeeded.
- If the token transferred to a different address than you expected, the recipient address was wrong.
Step 3: Check the "Logs" Tab for Event Emissions
If the "Token Transfers" tab is empty but you expected a token transfer, the transaction may have called a contract that does not emit a standard transfer event. Click "Logs" to see raw event logs. Look for a Transfer event (topic 0x 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef). If you see one, the token moved. If you see none, no token transfer occurred.
Step 4: Check the "Internal Txns" Tab for Native Coin Transfers
If the tokens are native coins (ETH on Ethereum, MATIC on Polygon, etc.), they will not appear in "Token Transfers". Go to "Internal Txns". This shows ETH transfers triggered by contract calls. If you see a transfer to your address, the coins arrived. If not, they did not.
Common Reasons for a Successful Transaction With No Tokens
You Sent Tokens to the Wrong Address
This is the most frequent cause. The transaction succeeded because sending tokens to any valid address is a valid action. The tokens are now owned by that address. If you sent them to a contract that does not support that token (e.g., sending USDC to the ETH deposit contract), the contract may have rejected the transfer and returned the tokens to the sender - or it may have accepted them and locked them permanently. Check the "Token Transfers" tab for a transfer back to the original sender. If you see one, the contract refused the deposit. If you see no return transfer, the tokens are lost.
The receiving contract rejected the token
Some smart contracts, especially DeFi protocols, only accept specific tokens. If you send an unsupported token, the contract's transfer function may succeed (meaning the token left your wallet) but the contract's internal logic may immediately reject it and send it back. Look for a second transfer in the same transaction sending the token back to you.
The front-end sent a different transaction than you intended
This happens with phishing sites or compromised dApps. You approve a transaction thinking it will transfer tokens, but the dApp submits a call to a different function - such as approve instead of transferFrom. The transaction succeeds because the approve call works, but no tokens move. Check the "Function" field on the transaction page. It tells you what function was actually called. If it says approve or increaseAllowance, you did not send tokens; you gave the contract permission to move them later. Revoke that approval using the method covered in this site's guide on checking and revoking ERC-20 approvals.
The Token Contract Has a Fee or Burn Mechanism
Some tokens deduct a fee or burn a percentage on every transfer. The transaction succeeds, but the recipient receives less than the sent amount - possibly zero if the fee is 100%. Check the token's contract for a feeOnTransfer or _taxRate function. Compare the amount in the "Token Transfers" tab to the amount you sent.
The transaction was a different operation altogether
You may have called a function that does not move tokens, even though you thought it would. For example, calling stake on a staking contract locks your tokens but does not send them to your wallet. The transaction succeeds, your balance in the data/simulate-transaction-before-signing/">wallet does not increase, but the tokens are now in the staking contract. Check the "Logs" for events like Staked or Deposit.
What to do next
- If the tokens transferred to a wrong address: There is no way to reverse a confirmed transfer on a blockchain. The only hope is if the recipient address belongs to someone you can contact, or if it is a contract you control.
- If the front-end lied and you called
approve: Revoke the approval immediately. The tokens never left your wallet. - If the receiving contract rejected the tokens: Your tokens are back in your wallet. Refresh your balance display.
- If the transaction was a staking or deposit: The tokens are in the protocol. Check the dApp's interface for your balance there.
Always simulate a transaction before signing, as covered in this site's guide on simulation. It shows you exactly what the transaction will do, including token movements, before you commit to it on-chain.
Not financial advice. basiliskawakens.xyz publishes market data and general information about digital assets. Crypto assets are volatile and you can lose everything you put in. Nothing here is a recommendation to buy, sell or hold, and we make no price predictions.
Prices are sourced from third parties and may be delayed or wrong. Verify anything you intend to act on against a primary source.