How to Use a Block Explorer as a Transaction Receipt
A verification guide for checking status, network, recipient and token movement.
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
A block explorer is the closest thing crypto has to a bank statement, and the most common mistake is treating it as a confirmation screen instead. A receipt has one job: it tells you what actually happened, to whom, on which network, and what it cost. Getting that from an explorer takes about ninety seconds and four lookups, and it is the difference between “the interface said it went through” and “I can show you the record.” This guide walks through those lookups in the order that catches problems earliest.
The reason this matters more than it looks: almost every loss report in DeFi begins with a plausible interface and ends with an unverifiable claim. The interface is controlled by whoever wrote it. The block record is not. When the two disagree, the block record is the one that describes where your funds actually are.
Start with the transaction hash, not the address
Everything else depends on this one identifier. A transaction hash, usually shown as
0x followed by 64 hexadecimal characters, is the unique name of a single
transaction on one network. It is not an account address, and it is not a block
number, though it is usually displayed next to both.
If you do not have the hash, you do not have a receipt. Wallets differ in how recoverable this is: some copy it to the clipboard automatically, some keep a transaction history with a link, and some bury it. MetaMask shows recent activity in the wallet’s Activity tab with an explorer link per row. If a hash has been lost entirely, you can still reconstruct a partial picture from your address, but you lose the ability to see confirmation count, gas actually paid, and the full internal call trace — which is where a token approval or a router path becomes visible.
Lookup one: is it final, and on the network I meant?
A transaction hash is meaningless outside its own network. The same 64 characters on Ethereum mainnet, Arbitrum, Base, Optimism and Polygon refer to entirely different transactions. Wallets frequently route across a bridge or an L2 automatically, so the network you selected and the network the transaction landed on are not always the same thing. Confirm the network name shown in the explorer’s header before reading anything else.
Then check status. Explorers present this as Success, Failed, or Pending. A failed transaction still consumed gas — this trips people up repeatedly, because a failed swap feels like nothing happened while the balance shows the fee is gone. Understanding that distinction is the whole point of reading a receipt.
For finality, look at the confirmation count. On Ethereum mainnet, a handful of confirmations is generally treated as settled for ordinary purposes; the number required grows with the value at risk. On most Layer 2 networks, finality is inherited from the settlement layer, so an L2 transaction can show as confirmed while still being reversible in theory. Reading a receipt well means knowing which kind of network you are looking at.
Lookup two: who received it, and how much
Read the recipient field against what you intended. This is a single comparison and it catches an entire category of problem: an address that was correct when you read it and was replaced by the time you signed, usually through clipboard poisoning where a malicious dApp quietly puts its own address in your clipboard and your paste lands there.
Then confirm the value. The transaction shows what left your account and, in the logs or internal transactions section, what arrived. For a plain transfer these match. For a swap, a bridge, or anything routed through a router, the addresses in the top-level fields are contracts, not the final destination — the meaningful movements sit under internal transactions or token transfer logs. Set the explorer to show those, or you are reading a routing instruction rather than a result.
The check that catches the most: does the token that arrived match the token you expected? A transaction that sends the right amount of the wrong asset looks identical at the top level and is irreversible once confirmed.
Lookup three: what did it cost
The fee field shows gas used multiplied by the gas price, denominated in the native asset. Gas used tells you how much computation the transaction required; a very high number on a simple operation often means the transaction did more than you expected, which is worth understanding rather than ignoring.
A more useful signal sits next to it. If you sent a transaction to a specific contract, the explorer can show the function that was called, and the decoded arguments. This is where an approval that you believed was a swap reveals itself as a spend-permission call with an allowance of unlimited tokens. Reading the calldata is the only reliable way to know what you actually signed.
Lookup four: what the transaction touched
Token approval transactions are quiet. They move no tokens and still cost gas. The way to see them is the approval checker built into most major explorers, or the permissions section of your wallet. For any address that has signed a transaction, review which contracts are approved to move which tokens, and how much.
The distinction that prevents most future loss: an approval is not a transfer. It grants a contract permission to move your tokens on your behalf, up to a limit, until revoked. Users routinely sign an approval to enable a swap, forget it, and later have it exploited when the protocol they approved turns out to be compromised or abandoned. A receipt review is when you discover the approval exists at all.
For anything routed through an aggregator, the internal transaction list shows every intermediate hop. A route that includes an unfamiliar router or an address that received a disproportionate share of the output is worth pausing over.
Recording it so the receipt is still useful later
Explorers prune. Some keep full transaction data indefinitely, some keep only transaction hashes and basic fields after a retention window, and third-party indexers go out of business. If a record matters — an exchange support ticket, a dispute, a tax question, a report to a protocol — capture it while it is there: the hash, the block number, the timestamp, the fee, the recipient, and a screenshot of the transaction page.
Store the hash even when everything looks fine. It costs nothing and it is the only part that stays valid. A receipt you did not save is not evidence.
What this does and does not prove
A block explorer proves what was recorded. It does not prove a transaction was intentional, that a contract behaves as its authors described, or that funds ended up somewhere useful. Those are separate questions, answered by reading the contract, not the receipt.
The two hard limits are worth stating plainly. First, a transaction is final once confirmed: there is no chargeback, and no support line that reverses it. Second, a transaction on a valid hash is a transaction you broadcast — the explorer cannot tell you whether you intended to send it, only that it exists. Reading a receipt tells you what happened, which is the precondition for everything else you might do next.