How to check a crypto transaction on a block explorer
This is the guide for the ten minutes after you press Withdraw and nothing shows up. It is the most common panic in crypto and, in the ordinary case, the correct action is to do nothing for another half hour. The point of a block explorer is that it lets you tell the ordinary case apart from the other one without guessing — and the difference between them is visible in two fields.
If you have not sent the funds yet, read the withdrawal checklist first. Everything below assumes the transaction already left.
What is a TXID, and where is yours?
A transaction ID — TXID, or transaction hash — is the name the network gives your transfer at the moment it is broadcast. It is a long string of hexadecimal characters, it is unique, and it is the only handle that points at your transfer and nothing else.
The important word in that sentence is broadcast. The ID does not exist when you press the button. It exists when the sending platform actually releases the transaction to the network, and those are two different events that can sit hours apart. An exchange may hold a withdrawal for review, for a cooling-off window after a security change, or simply because its processing runs in batches.
So the first question is not “where is my money” but “does a TXID exist yet”. Open the withdrawal history on the platform that sent the funds and look at the entry. If there is an ID there, the transfer is on the network and the explorer can tell you about it. If the field is empty or shows only a status word, the chain has nothing to say, and no amount of searching will produce an answer, because there is nothing out there to find.
Which explorer do you paste it into?
A block explorer is a read-only window onto one network’s ledger. There is no universal one, because there is no universal ledger. Which explorer you need is decided by the network you selected on the withdrawal form, and that is a different question from which coin you sent.
This trips people up because the popular stablecoins are not native to any single chain. The same ticker can be issued on a dozen networks, and each one keeps its own separate record. Send on one and search on the explorer for another, and you get a blank result page that looks exactly like a blank result page for money that has vanished.
Two things make it worse. First, some networks share an address format — the account-style chains that use the same 0x prefix are mutually indistinguishable by eye, so a wrong-network transfer looks completely valid right up until the explorer says it has never heard of your transaction. Second, explorers localise: when we opened one for this guide it silently switched to the browser’s own language, so the field wording you are reading may not match the wording described in any guide, including this one.
The practical rule: go back to the withdrawal record, read the network name it stored — not the one you remember choosing — and search for an explorer for that. Most networks have at least one well-known public explorer, and your receiving platform's deposit page usually links to the one it uses itself.
What do the fields actually mean?
Explorers differ in layout and wording, but they are all displaying the same underlying record, and only a few of the rows change your decision.
Status has two meaningful states. Either the transaction has been included in a block, or it has not. Unconfirmed means it is broadcast and sitting in the pool of transactions waiting to be selected. It is not an error state and it is not a failure — it is a queue.
Confirmations is the count of blocks that have been built on top of the one holding your transaction, counting that block itself. The arithmetic is worth knowing because it removes all the mystery:
In the measurements taken for this guide, the tip stood at block 966,523. A transaction included in block 966,518 therefore showed 966,523 − 966,518 + 1 = 6 confirmations. Ten minutes later the tip has moved on and the same transaction reads 7. Nothing about the transaction changed; the chain simply grew.
That is why confirmations only ever go up, and why they are the right thing to watch. Each additional block sitting on top of yours is one more block an attacker would have to rebuild to erase your transfer, so the count is a rough measure of how expensive undoing it has become. It is also an integer, which makes it immune to the clock problem in the next section.
The rest of the page is context rather than decision. Amount may not match the sum you sent, for a reason covered under when this guide is wrong. Fee was fixed at broadcast and you cannot raise it afterwards. From and To are worth one careful look: confirm that the To address is the one you intended, character by character, at both ends of the string.
How long should a confirmation take?
Here is where most of the anxiety comes from, and it is a measurement problem rather than a crypto problem. Bitcoin aims for a block roughly every ten minutes. People hear that and expect blocks to arrive like buses on a timetable. They do not, and we can show it rather than assert it.
For this guide we pulled the timestamps of 15 consecutive Bitcoin blocks straight from the chain on 11 Sep 2026 — blocks 966,509 to 966,523 — and measured the 14 gaps between them.
The average came out at 9.97 minutes. That is the ten-minute target, essentially to the second, and it is the number every explainer quotes. Now look at what the average conceals:
| Measure | Value | What it tells you |
|---|---|---|
| Average gap | 9.97 min | The design target, met almost exactly across the sample. |
| Median gap | 3.70 min | The typical block arrives in well under half the advertised time. |
| Gaps under 5 min | 9 of 14 | Short waits are the common case, not the lucky one. |
| Gaps of 20 min or more | 2 of 14 | And long waits are frequent enough to expect one. |
| Longest single gap | 47.92 min | Nearly five times the target, inside a two-hour window. |
Our own measurement of 14 consecutive intervals on 11 Sep 2026, taken from a public block explorer’s chain data. Where this sample is weakest: 14 gaps is far too few to pin down a median, and the model in the next table puts the long-run figure nearer 7 minutes than the 3.70 we happened to measure. Read the chart for the spread, which is the point, and not for the exact statistics.
So “ten minutes a block” is an average that individual blocks almost never honour. The mechanism is that block discovery is a memoryless random process: the network adjusts difficulty so that blocks average ten minutes, but no rule spaces them out. Waiting twenty minutes tells you nothing has gone wrong, because a twenty-minute gap is an ordinary event.
That lets us answer the real question — how long a given number of confirmations should take — with arithmetic rather than folklore. Treating block arrivals as a random process averaging ten minutes, the wait for k confirmations has this shape:
| Confirmations | Average wait | Median wait | Slower than this 1 time in 10 | Chance of taking over 2 hours |
|---|---|---|---|---|
| 1 | 10 min | 7 min | 23 min | 0.0% |
| 3 | 30 min | 27 min | 53 min | 0.1% |
| 6 | 60 min | 57 min | 93 min | 2.0% |
| 12 | 120 min | 117 min | 166 min | 46.2% |
Our own calculation. Modelled as a Poisson process with a ten-minute mean, which is the network’s design target rather than a promise; real waits also depend on whether your fee clears the current queue. Reproduce it as the Erlang distribution with shape k and mean 10k minutes.
Read the six-confirmation row, because it is the common threshold. The average is an hour, but one wait in ten runs past 93 minutes, and about 2 in 100 take longer than two hours. None of those are malfunctions. If you open a support ticket at the ninety-minute mark you are, most of the time, reporting arithmetic.
There is a second reason the wait can stretch, and it has nothing to do with luck. Transactions compete for space in each block, and the fee decides the position in that queue. When we looked at the pending pool on 11 Sep 2026 it was stacked in 8 fee bands, and the lowest-paying band alone held 59,759 transactions with an estimated 36 blocks of work ahead of them — six hours or so at the target rate. A transaction in that band is not stuck. It is queuing, behind people who paid more.
It has not arrived — what does each case mean?
Five things can be on your screen. The useful move is to identify which one before doing anything, because the right response differs sharply and two of them are “wait”.
| What you see | What it means | What to do |
|---|---|---|
| Your history shows no TXID yet | The transaction has not been broadcast. Internal review, a withdrawal delay after a security change, or a manual check. | Wait, and read the exchange's own status message. There is nothing on chain to look at. |
| The explorer does not recognise the TXID | Either it has not propagated yet, or this is the explorer for a different network. | Confirm which network the withdrawal used, then try that network's explorer. |
| Status: unconfirmed, sitting in the queue | It is broadcast and waiting to be selected into a block. Normal, and the fee decides the position in the queue. | Wait. Compare its fee with the level the network is currently clearing. |
| Confirmed, and the To address is yours | The chain has done its job. Any remaining delay belongs to the receiving platform. | Check the receiving side's required confirmations, and whether a memo or tag was needed. |
| Confirmed, but the To address is not the one you meant | The funds moved, to someone else. This is the one case on this page that is not a waiting problem. | Nothing on the chain can undo it. Report it to the exchange, and to nobody who contacts you. |
Only the last row is an emergency, and it is the only one where acting faster does not help.
The fourth row is the one worth dwelling on, because it is where most real delays end up. A transaction can be comfortably confirmed on the chain and still not be in your account, and the cause is almost always one of three things on the receiving side. It may require more confirmations than the sender waited for. It may need a memo or destination tag that was left blank, in which case the funds arrived at a shared address with no note saying who they belong to. Or the deposit was sent on a network that the receiving platform does not support for that asset, which is the serious version and shades into the last row.
Which mistakes do careful people still make?
| Mistake | Why it fails | Instead |
|---|---|---|
| Searching the address instead of the TXID | An address page lists every transfer that address has ever been part of. On an exchange's hot wallet that can be thousands, and yours will not be obvious among them. | Search the TXID. It identifies one transaction and nothing else. |
| Using an explorer for the wrong network | The same coin exists on many chains, and some chains share an address format, so the search simply returns nothing and the blank result reads like proof the money vanished. | Match the explorer to the network you selected on the withdrawal form, not to the coin. |
| Judging by the clock instead of the confirmation count | Block timestamps are declared by whoever mined the block, inside a tolerance, so an explorer's age column can even run backwards between two blocks. | Read the confirmation count. It is an integer that only ever goes up. |
| Sending it a second time | The usual cause of a slow transfer is a queue, and a queue clears. A duplicate does not cancel the first attempt; it commits a second amount to the same uncertainty. | Change nothing until the explorer shows the first one confirmed. |
| Accepting help from whoever answers first | Posting a TXID publicly advertises both a loss and an owner. The replies that follow are the second attack, not the rescue, and the fee is always payable up front. | Use the exchange's own support channel, reached from inside the app you logged into. |
When is this guide wrong?
Four situations break the assumptions above, and in each one the explorer is not the tool to reach for.
Transfers that never touch the chain. Moving funds between two accounts on the same platform, or between two wallets a single custodian controls, is usually a bookkeeping entry rather than a broadcast transaction. No TXID is produced because no transaction exists. Searching for one is looking for a record of an event that did not happen.
Batched withdrawals. Exchanges commonly bundle many customers’ withdrawals into a single transaction with many outputs. Your TXID will be correct, but the total amount shown may be far larger than yours and the output list long. Find your own address in the list rather than reading the headline figure and concluding something is wrong.
Networks that do not work this way. The ten-minute arithmetic in this guide is Bitcoin’s. Other networks produce blocks in seconds, and some settle with a finality rule where confirmations stop accumulating meaning after a fixed point. Layer-two systems and payment channels may not publish an individual transfer to a public chain at all. The method — find the ID, match the explorer to the network, read status before clock — still holds. The timings do not transfer.
The address was wrong. If the transfer confirmed to an address you did not intend, this guide stops being useful at the moment you establish that. Nothing in the diagnostic sequence recovers funds; it only tells you where they went. Report it through the platform’s own channel and disengage from anyone who approaches you.
What survives all four is the sequencing. Establish whether a TXID exists, then whether the network has seen it, then whether a block holds it, then how many blocks sit on top. Each answer makes the next question worth asking, and the majority of transfers are resolved by the second step with nothing to do but wait.
FAQ
My exchange says the withdrawal is complete, so why has nothing arrived? Because the two words describe different events. Complete on the sending side means the platform released the transaction and handed it to the network. Arrived means the receiving side has seen it, buried it under enough blocks to satisfy its own threshold, and credited the balance. Between those two moments sits the chain, and on a busy day that gap can run to an hour or more without anything being wrong. The transaction ID is what lets you tell a normal wait apart from a real problem.
How many confirmations do I actually need? Whatever the receiving platform says it needs, which is a number it publishes for each coin and network pair and which is frequently higher than the number the sender waited for. There is no universal figure. What matters mechanically is that each additional confirmation is one more block built on top of yours, and undoing your transaction would mean rebuilding every block above it, so the cost of reversal climbs steeply with each one.
The explorer has never heard of my transaction ID. Is the money gone? Almost always no, and importantly it means the chain is not where the delay is. An explorer can only show transactions that were broadcast to the network, so a TXID it does not recognise usually means the sending platform has not released it yet, or that you are searching an explorer for a different network. Check that you have the right explorer for the network you selected, then check your withdrawal history again. Contact the sender, not a third party.
Can I speed up a transaction that is stuck unconfirmed? Not from the receiving end, and usually not at all when an exchange sent it. The fee was fixed at the moment of broadcast, and the techniques for bumping it are held by whoever controls the sending wallet. If an exchange sent it, that is the exchange. What you can do is read the fee level against what the network is currently clearing, which tells you whether you are looking at a short queue or a long one.