A block explorer is a website that displays the public contents of a blockchain. It is the most useful tool a beginner can learn, because it answers questions that support chat cannot: whether a transaction exists, what it contained, and whether the network considers it settled. Reading one carefully removes a large amount of unnecessary worry.
An explorer shows what a network recorded. It cannot tell you whether a transfer was a good idea, who controls an address, or why a service has not credited a deposit.
- What a transaction hash lets you establish independently.
- Why confirmations describe settlement rather than safety.
- How token transfers hide inside contract calls.
- What to gather before opening a support ticket.
What a block explorer actually shows
An explorer reads a public network and formats it for humans. It shows blocks, transactions, addresses, balances, and, on networks that support contracts, the calls those transactions made. It does not have private information. It cannot see your exchange account, your identity, or the reason you sent something, and it cannot change anything it displays.
Different explorers cover different networks, and several may cover the same one with different layouts and labels. The underlying data is the network’s, so two reputable explorers for the same chain should agree on facts. If they disagree, you are probably looking at two different networks or two different assets with similar names.
Start with the transaction hash
Every broadcast transaction has a hash: a long string that identifies it uniquely. Wallets and exchanges display it after a withdrawal or transfer, sometimes labelled TXID. Paste it into the explorer for the correct network and you get the authoritative record. Keep this string with your own notes, because it is the single most useful piece of evidence in any support conversation.
If a service says a transfer was sent but gives no hash, that is worth asking about. A transfer that exists on a network has a hash. A movement between two accounts inside the same platform may have none, because nothing touched the network; it was an internal ledger entry. Those are different events, and confusing them causes a lot of avoidable panic.
Confirmations describe settlement, not safety
After inclusion in a block, each subsequent block adds a confirmation. More confirmations make reversal progressively less plausible, which is why receiving services often wait for a specific number before crediting funds. The number they require differs by network and by service, and it is a policy choice rather than a universal rule.
Confirmations say nothing about whether a transaction was a good idea. A fully confirmed transfer to a scammer is exactly as settled as a correct one. Read confirmations as an answer to “has the network accepted this?” and never as an answer to “was this the right recipient?” The second question has to be answered before you send.
What a status actually means
| Status | What it means | What to do |
|---|---|---|
| Pending | Broadcast but not yet included in a block. | Wait; check whether the fee offered is low for current demand. |
| Success | Included and executed without reverting. | The network’s part is done; any delay now belongs to the receiving service. |
| Failed | Included, but the code it called did not complete. | The transfer did not happen; the fee is generally still spent. |
| Not found | No such transaction on this network. | Check the network, the hash, or whether it was an internal platform movement. |
Reading amounts, fees, and the fee asset
An explorer separates the amount transferred from the fee paid. On many networks the fee is paid in the native asset even when the transfer moves a token, so a transaction page may show a token amount alongside a fee in a different unit. Read both. A common surprise is that the amount received is lower than expected because a platform deducted its own withdrawal fee before broadcasting.
Compare three numbers when something looks wrong: what the sending service said it would send, what the network transaction actually contains, and what the receiving service credited. The gaps between them usually identify who to ask. If the network amount matches the sender’s stated amount, the question belongs to the receiving service.
A useful discipline is to compare three numbers whenever something looks wrong: what the sending service said it would send, what the network transaction actually contains, and what the receiving service credited. Each gap points at a different party. Arriving at a support conversation already knowing which of the three does not match turns a vague complaint into a specific, answerable question.
Addresses are not identities
An address page shows balances and a history of transactions, and none of that reveals a name. Labels attached to well-known addresses come from the explorer’s own research, not from the chain. Treat those labels as helpful hints that can be wrong, outdated, or absent, and never as proof of who controls an address.
The reverse also matters. Because history is public, an address you reuse builds a visible record. That is not automatically harmful, but it is worth knowing before you publish an address anywhere permanent. Sharing a transaction hash in a support ticket reveals the addresses involved, so redact only what a service actually needs and expect the rest to be visible anyway.
Pending, dropped, and replaced transactions
A transaction that has been broadcast but not included sits in the mempool. Explorers usually show it as pending. If the fee offered is low relative to current demand, it can wait a long time. On some networks it may eventually be dropped and disappear entirely, which means it never happened rather than that it failed halfway.
Some networks allow a pending transaction to be replaced by a new one from the same account with the same nonce and a higher fee. Wallets present this as speeding up or cancelling. It is neither magic nor guaranteed: it is a competing transaction, and whichever version is included is the one that counts. Watch the explorer to see which outcome occurred.
Replacement transactions are worth understanding before you need one. Speeding up or cancelling a pending transaction means broadcasting a competing transaction from the same account, and whichever version is included is the one that counts. It is not an undo button, it costs a fee, and on a congested network it can fail to take effect at all.
Tracing a transfer that has not arrived
Work through these in order. Most cases resolve at step two or three without contacting anyone.
Find the hash
Copy it from the sending wallet or platform. A transfer that touched a network has one; an internal platform movement does not.
Open the right explorer
Use an explorer for the network you actually sent on, not the network you meant to use.
Read the status
Pending means wait. Failed means it did not happen. Success means the network’s part is complete.
Compare the destination
Check the recorded address against the one the receiving service gave you, character by character.
Decide who to ask
Correct address and confirmed means it is a crediting question for the receiver. Anything else is a different conversation.
Token transfers hide inside contract calls
On contract-capable networks, moving a token is a call to that token’s contract rather than a plain transfer of the native asset. The main transaction line may therefore show a value of zero while a separate section lists the token transfer that actually took place. Beginners often read the zero and assume nothing moved.
Look for the token transfer section, and check the contract address of the token, not only its symbol. Symbols are not unique and can be copied deliberately. A transaction can also succeed at the network level while the contract logic reverts, in which case the explorer marks the transaction as failed and the fee is still spent.
Contract interactions also produce a status that beginners misread. A transaction can be recorded successfully at the network level while the contract logic reverts, in which case the explorer marks it as failed and the fee is still spent. Nothing was stolen and nothing moved; the attempt simply did not complete, and understanding that distinction avoids a great deal of unnecessary alarm.
Using an explorer to answer a support question
Before contacting anyone, gather the hash, the network, the sending and receiving addresses, the amount, the fee, the timestamp, and the current confirmation count. Write down which service you used at each end. This turns a vague message into a specific one and usually shortens the exchange considerably, because it tells the agent exactly where to look.
Then decide what you are actually asking. If the network shows the transfer confirmed to the address the receiving service gave you, the question is about crediting. If it shows the transfer confirmed to a different address or network, the question is different and often has no good answer. Knowing which situation you are in before you write is the point of learning this tool.
Gather this before contacting support
- Transaction hash — The identifier, copied in full from your wallet or platform.
- Network and asset — The exact chain used and the token version sent.
- Both addresses — Sender and destination, as recorded on the explorer.
- Amount and fee — What the network recorded, not what you intended to send.
- Time and confirmations — The timestamp and the current confirmation count.
- Both services — Which platform or wallet sat at each end of the transfer.
Key terms to keep handy
- Block explorer
- A website that presents blockchain data in a readable format.
- Transaction hash
- The unique identifier of a transaction, often called a TXID or transaction ID.
- Confirmation
- A block added at or after the block containing your transaction.
- Nonce
- A counter that orders transactions from a single sending account on some networks.
- Mempool
- The waiting area of broadcast transactions that have not yet been included in a block.
- Contract call
- A transaction that runs program code rather than only moving the network’s native asset.
Produce a hash you can look up
The OKX sell & withdraw guide covers selling and withdrawing, which is the action that produces a transaction on a network and therefore a hash you can verify independently of anything the platform tells you.
Get into the habit of saving that hash every time. It is the only piece of evidence that does not depend on a company’s interface remaining available, accurate, or accessible from your country.
Sources and further reading
- Ethereum transaction overview (opens in a new tab)
- Bitcoin: what you need to know (opens in a new tab)
- Bitcoin developer documentation (opens in a new tab)
Frequently asked questions
Do I need an account to use a block explorer?
No. Reading public blockchain data requires no account. Some explorers offer optional accounts for alerts or developer features, but the basic lookup of a transaction, block, or address is open to anyone.
My transaction is confirmed but the exchange has not credited it. Why?
Services set their own confirmation thresholds and processing steps, and some review deposits before crediting. A confirmed transfer to the correct deposit address on the correct network is the evidence to include when you ask the receiving service about timing.
What does a failed transaction mean?
It usually means the transaction was included in a block but the code it called did not complete successfully. The state change does not happen, and the fee for the attempt is generally still spent because the network performed the work.
Can an explorer tell me who owns an address?
No. Explorers display public network data. Any name shown next to an address is a label the explorer added from its own research, which may be incomplete or wrong, and most addresses have no label at all.
Why can I not find my transaction hash?
The most common reasons are searching on an explorer for a different network, a typing or truncation error in the hash, or a movement that happened inside one platform and never touched a blockchain at all.
What should I read next?
Read the network fees guide to understand why fees vary and why a pending transaction may wait, and the guide on sending crypto to the wrong address for what an explorer can and cannot resolve.
Crypto can lose substantial value, and transfers may be irreversible. This guide is educational, not financial, legal, or tax advice. Exchange access and features depend on your location.
Independent educational writing. How we research and correct our guides.