What is a block explorer and how to use it
When a payment hits a blockchain, it does not land in an inbox you log into or a dashboard some company controls. It lands on a public ledger, visible to anyone in the world, permanently. A block explorer is the interface that lets you — and anyone else — read that ledger without running your own node, writing any code, or trusting a third party to tell you what happened. For a broker, attorney, or advisor who is moving money on a deal, knowing how to use one is not a technical skill. It is a professional one.
What a block explorer actually is
Think of a blockchain as a database that no single entity owns. Every transaction ever executed is stored in that database, in order, grouped into blocks, linked together in a chain. The database is public and replicated across thousands of computers simultaneously. A block explorer is a web interface that reads from that database in real time and presents it in a human-readable format.
When someone sends cryptocurrency — whether that is USDC from one wallet to a closing attorney’s account, or a split payment going to three wallets at once — that event gets recorded on the blockchain within seconds. A block explorer captures that event and displays it: who sent it, to whom, how much, what time, what fee was paid to process it, and whether the network confirmed it.
There is one explorer for every major blockchain, and sometimes several competing ones. On Ethereum and Ethereum-compatible networks, Etherscan is the most widely used. For Solana, Solscan and the Solana Explorer are both common. For Bitcoin, Blockstream.info and Mempool.space are the standard references. For chains like Polygon, Base, or Arbitrum — which are all EVM-compatible — there are dedicated explorers that work identically to Etherscan, because they read the same data structure. The network a payment runs on determines which explorer you go to. When someone sends you a transaction hash, the hash itself usually tells you nothing about the chain — you need to know which network the payment was sent on before you can look it up on the right explorer.
The anatomy of a block explorer page
Every explorer looks slightly different, but they all surface the same underlying data. Understanding the fields means you can use any explorer on any chain without relearning anything. Here is what you will see when you pull up a transaction.
The transaction hash
This is the unique identifier for the transaction — a long string of letters and numbers, typically starting with “0x” on Ethereum-compatible chains. It is generated cryptographically at the moment the transaction is broadcast. No two transactions can share a hash. It is not assigned by any company, it is not a reference number a platform made up — it is produced by the math of the transaction itself. When someone says “here is the hash,” they are handing you the key that unlocks the full record.
Status
Status is the first thing you check. There are two states that matter: Pending and Success. A pending transaction has been broadcast to the network but has not yet been included in a confirmed block. This is a normal state for transactions that are very recent or were submitted with a low gas fee during a congested period. A success status means the transaction has been picked up by a block, validated by the network, and finalized. On most EVM chains, a transaction is considered irreversible after a small number of confirmations — typically 12 to 35 blocks, which passes in minutes.
There is a third state you may see: Failed. A failed transaction means the network attempted to process it but something went wrong — usually a smart contract error, an out-of-gas condition, or an incompatibility. The fee was still consumed, but no funds moved to the recipient. This is rare for simple transfers, more common with complex contract interactions. A failed transaction with a zero-value transfer is very different from a pending one — pending means wait, failed means the money did not move, full stop.
Block number and confirmations
Each block has a sequential number. When your transaction is included in block 22,481,305, and the chain is currently at block 22,481,330, you have 25 confirmations. More confirmations mean more blocks have been stacked on top of yours, making it progressively more computationally expensive for anyone to rewrite history and reverse the transaction. For practical purposes in a professional context — a completed deal, a closing, a wire equivalent — twelve or more confirmations on Ethereum is functionally final. Bitcoin is typically considered settled after six confirmations, which can take an hour.
Timestamp
The exact date and time the block was mined, recorded in UTC. This is the legal timestamp of the payment. If there is ever a dispute about when a payment was made — not when it was initiated, not when an email was sent, not when a platform said it processed — the block timestamp is the immutable record. It cannot be altered retroactively. It cannot be adjusted after the fact. You can see it, your counterparty can see it, their attorney can see it, and it will say the same thing to all of them.
From and To addresses
The From field is the wallet that initiated the transaction. The To field is the wallet that received it. On a simple transfer, the To field will be a single wallet address. On a smart contract interaction — for instance, a payment router that splits funds to multiple wallets in one transaction — the To field will show the contract address, not the end recipient. You would then look at the internal transactions or token transfer logs to see where the funds actually landed. More on that below.
Value
The amount sent. For native blockchain currency — ETH, MATIC, SOL — this shows directly in the Value field. For stablecoins and ERC-20 tokens like USDC or USDT, the value often shows as zero in the main field, because the transfer happens through the token contract, not as a native transfer. The real number appears in the Token Transfers section lower on the page.
Transaction fee / Gas fee
This is the fee paid to the network — not to any platform or service, to the network itself — for processing the transaction. It is denominated in the chain’s native token. On Ethereum it can run anywhere from a few cents to several dollars depending on network congestion. On Layer 2 networks like Base or Arbitrum, fees are typically fractions of a cent. This field matters when you want to reconcile the exact amount received against the amount sent — the fee comes out of the sending wallet, not the receiving wallet, so the recipient gets the full amount unless the contract is coded otherwise.
Token transfers
This section is where stablecoin payments actually live. If someone sent you 50,000 USDC, you will see a token transfer event showing: the sending address, the receiving address, the token (USDC), the contract address for USDC, and the exact amount, down to the decimal. If there were multiple recipients — a split payment, a fee disbursement to several parties — each transfer will appear as a separate line in this section, all linked to the same parent transaction hash. One transaction, multiple lines, every wallet confirmed.
Internal transactions
When a smart contract executes and moves funds as part of its logic — rather than a direct wallet-to-wallet send — those movements appear as internal transactions. These are sometimes called “traces.” They are not top-level transactions, but they are fully part of the blockchain record. If you are using a payment router that splits ETH or the native currency of a chain to multiple addresses simultaneously, you will see those individual sends listed here. For a closing attorney reviewing a disbursement, this tab is where you verify each recipient received their exact allocation.
Input data
This field shows the raw data attached to the transaction — the instructions passed to a smart contract. For a direct wallet transfer it is usually empty or reads as “0x.” For a contract call it is encoded function data. Most professionals will never need to decode this themselves, but the existence of this field means the contract call is fully auditable. Anyone with the ABI — the contract’s interface definition — can decode exactly what function was called with exactly what parameters.
How to look up a transaction step by step
Suppose someone on a deal tells you the payment has been sent. They give you a transaction hash. Here is exactly how you go from that string of characters to a verified confirmation.
Step one: identify the network. Before you go anywhere, confirm which blockchain the payment was sent on. A transaction hash from Ethereum looks identical to one from Polygon or Base — they are all 66-character hex strings starting with 0x. You cannot open an Ethereum hash on Solscan and find anything. Ask the sender if it is not obvious: “Which network? ETH mainnet, Base, Polygon?” Most payment tools will tell you, and the wallet used will have a record.
Step two: go to the right explorer. Ethereum mainnet → etherscan.io. Base → basescan.org. Polygon → polygonscan.com. Arbitrum → arbiscan.io. Solana → solscan.io or explorer.solana.com. Bitcoin → mempool.space or blockstream.info. Each of these is a free, public tool requiring no login.
Step three: paste the hash. Copy the hash exactly — including the “0x” prefix if present — and paste it into the search bar on the explorer. Hit enter. The explorer retrieves the transaction record from the blockchain and displays it.
Step four: check status first. Before anything else, look at the status. Success means confirmed. Pending means wait. Failed means the funds did not move and you need to go back to the sender.
Step five: verify the recipient address. Copy the destination wallet address you were expecting to receive funds — your wallet, or your client’s, or the designated closing account — and compare it character by character against the To field, or against the Token Transfers section if it is a stablecoin. The addresses should match exactly. One wrong character means the payment went elsewhere.
Step six: verify the amount. Confirm the amount in the Value field (native currency) or the Token Transfers section (stablecoins) matches the agreed figure. Note the token. 50,000 USDC is not the same as 50,000 USDT, even if both are “stablecoins.” The token contract address tells you which one.
Step seven: note the timestamp. Record the UTC timestamp from the block for your deal file. If the deal required payment by a certain time, this is your proof.
Step eight: save or share. The URL of the transaction page on any explorer is permanent and shareable. Anyone with that URL can view the same record. There is no expiration, no login required, no gated access. You can paste it into an email, drop it in a deal room, or print it as an exhibit.
What to do when something looks wrong
You paste the hash and the transaction shows a recipient address that does not match the wallet you were expecting. Stop. Do not assume it will sort itself out. Blockchain transactions are final. If funds went to the wrong address, they did not bounce back — they are in that wallet. The first step is to identify whether the wrong address belongs to anyone in the deal chain. Sometimes there are multiple wallets in play: a hot wallet, a cold wallet, a platform custodial address. Confirm with the sender what wallet they were paying to. If the address is genuinely unrecognized, that is a serious discrepancy requiring immediate escalation.
You paste the hash and see a failed transaction. This is the most common misunderstanding. People see that a transaction was “sent” and assume it went through. Failed means the network rejected the execution — funds did not move to the recipient despite the attempt. The sender needs to resubmit. Do not release anything or proceed with any deal milestone based on a failed transaction.
You paste the hash and nothing comes up. Either you are on the wrong explorer for the network, you have a typo in the hash, or the transaction has not been broadcast at all. Try an alternative explorer for the same chain. If still nothing, go back to the sender for confirmation.
You see the hash returns a transaction but the amount is zero or the token transfer section is empty for what should have been a stablecoin transfer. You may be looking at the wrong tab, or the sending platform may not have actually executed the transfer yet — some platforms “queue” transactions internally before hitting the chain. The hash only exists when the transaction is actually on-chain. If the hash is real and the token transfers show nothing, the contract may have executed but transferred nothing, which points to a contract-level failure.
Reading multi-recipient transactions
Split payments are increasingly common in deals where fees, commissions, and disbursements need to go to multiple parties simultaneously. When a single transaction routes funds to several wallets, the explorer shows this clearly — but you have to look at the right section.
On a token transfer, you will see multiple rows in the Token Transfers section, each row showing the USDC (or whatever token) flowing from the contract address to a distinct recipient wallet. If four parties are getting paid from one transaction, there are four rows. Each row shows the exact amount that particular wallet received. There is no ambiguity about who was paid what — the math is public.
This is where a tool like Shaka earns its place in a professional’s workflow. When a deal closes and the payment goes through Shaka’s routing contract, every recipient — the lead broker, the co-broker, the referral fee recipient, the closing attorney — receives their exact allocation in a single on-chain transaction. The explorer shows the full distribution in one place. No one needs to wait for a wire to settle, no one needs to chase a second transfer, and there is no “we’ll send your portion tomorrow.” One hash, multiple rows, every party confirmed.
For any professional who has ever had to prove that a disbursement was made — to a client, to a licensing body, to a dispute resolution panel — this is the record. Not a PDF someone generated, not a screenshot from a platform that can be edited, but a cryptographic record on a distributed network that no single party controls.
Saving and using explorer records professionally
A transaction hash and its explorer URL belong in every deal file where payment was made on-chain. Here is how professionals use this in practice.
For your own records: keep the hash, the explorer URL, and a screenshot of the transaction page (with status, timestamp, addresses, and amounts visible) in your deal folder. Store it the same way you would store a wire confirmation.
For counterparty confirmation: share the explorer URL directly. There is no account required to view it. Anyone can open the link and see the same data you see. If a co-broker wants proof their split was sent, you send them the hash. If a client’s attorney wants proof of disbursement, same answer.
For dispute resolution: the explorer record is neutral. It was not generated by you, by your platform, by your bank, or by the other side’s bank. It was generated by the network itself. If you are ever in a position where someone is disputing whether a payment was made, the blockchain record cuts through the noise immediately. The timestamp, the amount, the recipient — all of it is there, and none of it bends.
For compliance and audit: if your deals are subject to any audit requirement — real estate commission records, legal fee documentation, financial advisor documentation of compensation — the on-chain record is a cleaner audit trail than most traditional payment systems produce. Every transfer is timestamped, immutable, and independently verifiable by any third party.
Chain-specific nuances worth knowing
On Bitcoin, the explorer layout is different because Bitcoin does not use the same account model. Bitcoin transactions consume “inputs” (unspent outputs from previous transactions) and produce “outputs” (new unspent outputs going to recipient addresses). This means a single Bitcoin transaction can have multiple inputs and multiple outputs by design — the UTXO model. When you look up a Bitcoin transaction, you verify the output going to the target address, not a single To field the way EVM chains work. Mempool.space makes this readable, showing each output address and the BTC amount it received.
On Solana, transactions are faster and the explorer layout reflects a different architecture. Solana transactions include “instructions” that map to program calls, and token transfers show up in a similar fashion to EVM chains but within a different UI. Solscan generally provides the cleaner interface for non-technical users, with clear sections for SOL transfers and SPL token transfers (Solana’s token standard).
On Layer 2 chains like Base, Optimism, and Arbitrum, you get the speed and low cost of a rollup with the full EVM explorer interface. The only additional element you may see is an L1 batch confirmation — the periodic checkpoint where the Layer 2 state is settled onto Ethereum mainnet. For practical payment verification purposes, the L2 confirmation is what matters and what you read.
The question of finality
Professionals used to wire transfers have an intuition for finality: the wire arrives, it is settled, done. Blockchain transactions operate on a similar finality model, but the mechanics are different. There is no reversible hold period, no recall window, no chargeback mechanism. Once a transaction reaches a sufficient number of confirmations — and for most chains this is a matter of minutes — it is done in a way that wire transfers are not even done. A wire can, under narrow circumstances, be recalled. An on-chain transaction cannot be reversed by any party, including the sender.
The explorer is where you confirm that finality has been reached. A success status plus confirmations above the chain’s threshold is the professional definition of a closed payment. Not “submitted,” not “initiated,” not “in process” — confirmed. The number in the confirmations field is your signal.
Understanding this matters for deal timing. If a payment on-chain is made before midnight of a closing date, the timestamp in the block is the record. If there is any ambiguity about deal timing, the blockchain does not leave room for interpretation. The explorer will show you the exact UTC time, and that time is what it is.
Every professional moving money in a deal — broker, agent, attorney, advisor — benefits from knowing how to read this record. It is not about distrusting your counterparties. It is about having a standard of certainty that no other payment infrastructure currently provides, and being able to demonstrate that certainty to anyone who asks.
