How to Read a Block Explorer After Sending Crypto

**A transaction receipt should answer the user’s question. A block explorer should verify the answer—not become the place where the user has to reconstruct it.**

You press Send. The wallet shows a green tick. But the recipient still cannot see the funds.

Was the transaction submitted, confirmed, finalized, or merely signed? Did it go to the correct network? Did the token move, or did only a contract call succeed? Is the wallet balance delayed, or did the transfer fail?

“Sent” collapses too many states into one reassuring word.

Block explorers exist to expose what a blockchain recorded. Ethereum describes them as portals to real-time data about transactions, blocks, accounts and other onchain activity. That makes an explorer the best independent place to verify a transfer—but only if you know which fields matter.

This guide gives you a practical reading order. You do not need to decode every hexadecimal field. You need to answer seven questions.

## 1. Are you looking at the right network?

Start with the network, not the status badge.

The same-looking address can exist on several EVM networks. A transaction completed on Base does not appear in an Ethereum mainnet explorer just because both networks use `0x` addresses. Solana uses a different address system and a different explorer.

Before interpreting anything, verify:

- the source network shown by your wallet;
- the network supported by the explorer URL;
- whether you are viewing mainnet or a test network.

If the transaction hash cannot be found, a wrong explorer is often a better first hypothesis than “the funds disappeared.”

## 2. Does the transaction hash match?

The transaction hash—or signature on Solana—is the transaction’s lookup key. It is not a secret. It is the identifier you can use to retrieve the public record.

Copy it directly from the wallet’s activity screen. Then compare at least the first and last six characters after pasting it into the explorer. This protects against opening the wrong transaction from history or a copied chat message.

If no hash exists, the wallet may not have broadcast the transaction. A signed intent and a submitted transaction are not the same thing.

## 3. What does the status actually say?

The exact labels differ across chains and explorers, but the underlying distinction is important:

- **Pending or processed:** the network has seen the transaction, but the result is not yet strong enough to treat as permanent.
- **Confirmed or included:** the transaction has entered an accepted block or received the network’s required votes.
- **Finalized:** the network has reached its strongest normal settlement state.
- **Failed or reverted:** the transaction was processed but did not complete the intended state change.
- **Dropped or expired:** the submitted transaction was not successfully included within the valid window.

Ethereum’s transaction lifecycle separates broadcast, inclusion in a block and later finality. Solana likewise distinguishes `processed`, `confirmed` and `finalized`. Faster block or slot production can reduce waiting time, but it does not make those states interchangeable.

That is the practical insight behind today’s research: **network speed is not a substitute for state clarity.** Solana’s current work on lower slot times makes the interface feel faster; it also makes accurate status language more important, not less.

## 4. Who sent what to whom?

Next, inspect the parties and the asset movement.

Check:

- `From`: the address that initiated the transaction;
- `To`: the recipient or contract called;
- token transfer details or balance changes;
- amount and token symbol;
- token contract or mint address when the asset name is ambiguous.

The top-level `To` address is not always the final recipient. In a swap, bridge or cross-chain route, it may be a router or contract. The meaningful asset movement can appear in token transfers, instructions, events or balance changes further down the page.

This is why a successful contract call does not automatically prove that the expected asset reached the expected destination address.

## 5. Did the intended action succeed—or only the transaction?

An explorer may show “Success” because the source-chain call executed correctly. That still does not answer every cross-chain question.

A cross-chain journey can contain several observable stages:

1. the source transaction is submitted;
2. the source transaction is confirmed;
3. an intermediary route or bridge processes the message;
4. a destination transaction is created;
5. the destination asset arrives;
6. the destination wallet or app refreshes its balance.

One green badge cannot responsibly represent all six.

If the source transaction succeeded but the destination balance is missing, look for a destination transaction hash or route-status link. Then verify that transaction on the destination network. Do not repeat the transfer simply because the wallet UI has not refreshed.

## 6. What fee was actually paid?

Explorers normally show the network fee charged by the source transaction. Depending on the chain, this may include gas used, gas price, base fee, priority fee or a simplified total.

Read this as the recorded network cost—not automatically the full cost of a swap or cross-chain route. Price impact, protocol fees, destination execution costs and differences between quoted and received amounts may live elsewhere.

The useful comparison is:

- what the interface estimated before signing;
- what the source transaction paid;
- what the destination address ultimately received.

That comparison turns an explorer from a troubleshooting tool into a trust check.

## 7. Has the recipient’s balance actually changed?

Finality and arrival are connected, but they are not identical user questions.

The explorer can confirm that a state change was recorded. The recipient still needs the correct network selected, the correct token visible and an updated account state. Some wallets cache balances or hide unfamiliar tokens.

Before escalating or retrying:

- verify the destination address character by character;
- open that address on the destination explorer;
- inspect token transfers or balance changes;
- confirm the token contract or mint;
- refresh the wallet or add the verified token if needed.

Only retry when the previous attempt’s state is understood. Repeating an uncertain transfer can create a second valid transaction rather than repair the first.

## A 60-second block-explorer checklist

When a transfer looks stuck, check in this order:

1. **Network:** Is this the explorer for the chain you used?
2. **Hash:** Does it match the transaction shown by your wallet?
3. **Status:** Pending, confirmed, finalized, failed or expired?
4. **Parties:** Are the sender and destination addresses correct?
5. **Asset movement:** Did the intended token and amount move?
6. **Destination leg:** Is there another transaction to verify?
7. **Balance:** Did the destination address—not only the wallet interface—receive it?

This order matters. It stops users from treating a delayed interface, a pending transaction and a failed route as the same problem.

## The sharper product principle

Block explorers are essential public infrastructure. But sending ordinary users to one without context is not a complete product experience.

A wallet already knows the network, transaction hash, expected recipient and intended outcome. It should use that context to show a readable post-sign receipt:

- submitted is not confirmed;
- confirmed is not necessarily finalized;
- source success is not destination arrival;
- explorer evidence should be one tap away;
- failure should explain the next safe action.

At Biti.pro, this is the standard we are building toward: clarity should continue after signing. The product is pre-launch, so this article describes the experience and principles guiding the work—not a claim that every state and recovery path is already shipped.

**A green tick should not end the explanation. It should begin a receipt the user can verify.**

Join the Biti.pro waitlist to follow the product as we build clearer self-custody journeys from intent to arrival.