An exchange says “completed,” but the receiving balance has not changed. The transaction hash helps separate what happened on the blockchain from what the receiving platform has credited. Copy it from the sender’s record, identify the network, then inspect the matching explorer without connecting a wallet.
What a transaction hash can tell you
A transaction hash—also called a TxID, transaction ID or, on some networks, a signature—identifies a submitted transaction. Formats vary across chains, so the characters alone may not reveal the network. The hash is not a password and cannot by itself authorise a transfer.
It does expose public relationships such as relevant addresses, time and amount.
Share only the transaction required for support; there is no need to publish a complete balance or identity file. No legitimate explorer lookup requires a seed phrase, private key, one-time code or remote-control session.
Choose the network before the explorer
The same asset can move on several chains, and each chain maintains separate transaction data. Searching an Ethereum hash on a Solana explorer can produce “not found” without proving that no transfer occurred. The sender's withdrawal history or wallet should identify the network. Record it before opening an explorer.
A public transaction lookup should not require connecting or signing with a wallet. Avoid ads that promise to unlock, accelerate or recover a transaction. ethereum.org’s explorer guide describes interfaces for viewing blocks, transactions, accounts and other onchain activity, and lists several tools and the common fields they expose.
Pending, success, failed and not found
| Result | What it supports | What it does not prove |
|---|---|---|
| Pending | A node or explorer has seen the transaction, but inclusion or confirmation is incomplete | Final success or recipient credit |
| Success | The network included and successfully executed the transaction under its rules | Correct memo, supported token or custodial credit |
| Failed | Onchain execution did not complete the intended state change | Automatic refund of the network fee |
| Not found | This explorer did not return the identifier | That funds are lost or the sender never attempted a transfer |
Solana’s getTransaction documentation makes a similar distinction at the protocol-query level: it searches by transaction signature and can return no result when the transaction is not found or confirmed at the requested commitment. A user need not call the API, but should not treat an empty query result as a confirmed failure.
Fields to verify after finding the record
- Network: the explorer belongs to the chain selected by the sender.
- Status: read the exact label rather than relying on colour.
- From: confirm that the sending address is plausible for the wallet or platform.
- To: note that this may be a smart contract rather than the ultimate token recipient.
- Token transfers: for contract tokens, inspect transfer events instead of only the native-asset Value field.
- Amount: confirm token identity and decimal display.
- Block and time: ensure the record corresponds to this transfer.
- Fee: distinguish the onchain fee from any platform withdrawal charge.
A contract transaction may show zero native value while its token-transfer section records the intended asset movement. Conversely, a success badge without the expected token event is not evidence that the expected asset arrived.
Confirmations are chain- and recipient-specific
On some chains, a confirmation count rises as later blocks build on the transaction's block. Other chains expose commitment or finality states. A single “safe number” does not apply to all of them. A custodial recipient also chooses its own crediting threshold and may apply token, address or risk checks after the chain reaches that threshold.
Read both the explorer's current onchain status and the recipient's current deposit record or stated requirement. Network congestion, indexer lag or recipient maintenance can cause temporary disagreement. No guide can promise that a fixed number of confirmations always results in immediate credit.
If the explorer cannot find the hash
- Copy the complete hash again from the sender; do not type it or use a shortened version.
- Check the actual chain and mainnet, not a similarly named network or testnet.
- Confirm whether the platform still says reviewing or processing and has not created a TxID.
- Try another explorer listed by an official network source, or wait briefly for indexing.
- If no chain can find it, give the sending platform its internal record number, network, time and exact status.
If there is no TxID yet, the transfer may still be inside the sending platform; an explorer cannot create it. Use the withdrawal-status guide for that boundary. If the chain shows success but a custodial recipient has not credited the deposit, provide the recipient with the hash, network, asset, amount and destination address rather than sending another identical test.
If the transaction is onchain and failed
Read the explorer's failure category and check whether the intended asset balance actually changed. A reverted contract call may consume a network fee without moving the token. Blindly increasing a fee can repeat the problem when the cause is a contract condition, token approval, balance, sequence, expired quote or paused application.
If an application built the transaction, consult that application's official documentation. A third party cannot rewrite the chain's history. The safe task is to understand the failure, confirm the asset state, correct the condition and only then decide whether a new transaction is needed.