How to Read a Transaction on a Block Explorer
To read a transaction on a block explorer, paste its transaction ID (txid or hash) into the search box, then check four things in order: the status (unconfirmed, confirmed, or failed), which addresses and amounts went in and out, what fee was paid, and how many blocks now sit on top of it. Everything else on the page explains one of those four.
The trouble is the fields that look like one thing and mean another: a Bitcoin output that is really the sender's change, an Ethereum "Value: 0 ETH" on a transfer that moved twenty thousand dollars of stablecoins, a "Fail" badge that still cost a fee. Below we walk through three real transactions field by field, with every number pulled from public explorer APIs and a public Ethereum node on October 22, 2026, so you can open the same pages and check them.
What an Explorer Is, and What It Is Not
A block explorer is a website that reads a full node and formats the raw chain data for people. mempool.space and blockstream.info do this for Bitcoin; Etherscan does it for Ethereum. They do not hold coins, cannot reverse anything, and have no special authority. Two explorers showing different results means one is behind or looking at a different network.
Explorers also add their own interpretation: name tags for known addresses, decoded function names, dollar values, arrival estimates. These are helpful, but they are the explorer's opinion rather than part of the transaction. When a label and the raw fields disagree, trust the raw fields. If blocks, hashes and nodes are still fuzzy, start with how a blockchain records and links transactions; the protocol and on-chain learning hub collects the rest of the series.
Bitcoin Example 1: The Pizza Transaction
Our first example is the transaction widely known as the "Pizza transaction", txid a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d. Notice what the chain records: coins moving between addresses, a fee, a block. Nothing on-chain says what was bought or by whom. The nickname comes from outside the blockchain, and that is the first lesson of reading an explorer: it shows movements of value, not the story behind them.
| Explorer field | Value for a1075db5... | What it means |
|---|---|---|
| Status | Confirmed, block 57,043 | Included in a block, no longer waiting |
| Timestamp | May 22, 2010, 18:16:31 UTC | The block's time, not the moment it was sent |
| Inputs | 131, all from one legacy address starting 1XPTgDRh | 131 earlier coins spent together |
| Outputs | 1: 10,000 BTC to an address starting 17SkEw2m | No change output |
| Total in | 10,000.99 BTC | Sum of the coins spent |
| Fee | 0.99 BTC (99,000,000 sats) | Total in minus total out |
| Size / Weight / Virtual size | 23,620 bytes / 94,480 WU / 23,620 vB | Legacy transaction, so weight is exactly 4 times size |
| Fee rate | about 4,191 sat/vB | 99,000,000 sats divided by 23,620 vB |
| Version / Locktime | 1 / 0 | No time lock |
| Input sequence numbers | 0xffffffff on all 131 | No BIP-125 replace-by-fee signal |
| Confirmations | 915,611 at our check | Tip 972,653 minus 57,043, plus 1 |
Many inputs does not mean many payers
Bitcoin wallets do not hold a balance the way a bank account does. The Bitcoin developer guide describes each transaction as spending earlier outputs and creating new ones, each output waiting as an unspent transaction output (UTXO) until a later input consumes it. To send 10,000 BTC, this wallet gathered 131 of its existing coins, the largest worth 3,753.88 BTC, all locked to the same address. Many inputs usually means a wallet holding many smaller coins. When inputs come from several different addresses, analysts often assume a single owner, but that is an inference, not something the chain records. Cost-basis metrics such as MVRV are built from exactly these outputs; the MVRV Z-score guide rebuilds the metric on three coins.
An implicit fee and no change
Bitcoin transactions have no fee field. The fee is whatever the inputs hold that the outputs do not claim: 10,000.99 BTC in, 10,000 BTC out, so 0.99 BTC went to the miner of block 57,043. Because nothing came back to the sender, there is no change output. The developer guide notes that most transactions do include a change output, and the next example shows one.
A fee rate of about 4,191 sat/vB looks dramatic, but it reflects a large fee on a large transaction, not a bid for urgency in a crowded market. Fee rate is a price per unit of block space; it says nothing about whether the fee made sense in dollars. How wallets pick a rate for current conditions is covered in our guide to Bitcoin fees and the mempool.
Bitcoin Example 2: A SegWit Payment With Change
The second transaction, txid 6f588f54f64211e6e4c0225756705e6520e35e2999051ffdb1638cfb9a07927c, was mined in block 972,600 on October 22, 2026 at 09:36:44 UTC. It has the three features a 2026 reader meets most: a native SegWit input, a change output, and a replace-by-fee signal. It belongs to an unknown wallet, so we shorten its addresses; the full values are on any explorer.
| Explorer field | Value for 6f588f54... | How to read it |
|---|---|---|
| Status | Confirmed, block 972,600 | A block holding 3,103 transactions |
| Input | 0.0875 BTC (8,750,000 sats) from bc1qa28z...amugu | One native SegWit (P2WPKH) coin |
| Output 0 | 0.01343603 BTC to bc1qc0j6...kscgt | Almost certainly the payment |
| Output 1 | 0.07403577 BTC to bc1qa28z...amugu | Almost certainly change: same address as the input |
| Fee | 2,820 sats | 8,750,000 minus (1,343,603 + 7,403,577) |
| Size | 222 bytes | Includes the witness (signature and public key) |
| Weight | 561 WU | Base size 113 bytes times 3, plus 222 |
| Virtual size | 140.25 vB on mempool.space | Weight divided by 4; BIP-141 rounds this up to 141 |
| Fee rate | 20.1 sat/vB on mempool.space | 2,820 / 140.25; using the rounded 141 vB gives 20.0 |
| Input sequence | 0xfffffffd | Signals BIP-125 replace-by-fee |
| Confirmations | 54 at our check | 972,653 minus 972,600, plus 1 |
Which output is the payment?
An explorer lists outputs without calling one "payment" and another "change", because the chain does not record intent. Here the answer is easy: one output returns to the exact address the coin came from. That is address reuse, which the Bitcoin developer guide advises against because it makes change obvious. Wallets that follow that advice send change to a fresh address, and then you are left with clues, none of which is proof on its own.
| Clue | Suggests | Where it breaks |
|---|---|---|
| An output returns to an input address | That output is change | Only works when the wallet reused the address |
| One output is a round BTC amount | The round one is the payment | Payments priced in dollars are rarely round in BTC |
| One output matches the input's address type | The matching one is change | Fails when both sides use the same format, which is common |
| One output is later spent with the sender's other coins | It was change | Needs later blocks; invisible on day one |
| Output order | Nothing | Many wallets randomize order deliberately |
If you are checking whether you were paid, skip all of this: find your own address in the outputs and read the amount beside it. The clues matter when judging someone else's claim. In this example, a person pointing to the 0.074 BTC output and calling it a payment would be pointing at their own change. Our explainer on what bc1q, bc1p, 3 and 1 addresses mean shows how address formats themselves can give change away.
Size, weight and virtual size now differ
The input carries a witness of two items, a signature and a public key. BIP-141 defines weight as base size times 3 plus total size, so witness bytes count once and everything else counts four times. Solving 561 = 3 x base + 222 gives a base size of 113 bytes, meaning 109 bytes are witness. Virtual size is weight divided by 4. BIP-141 rounds it up to the next integer, 141 vB, while mempool.space displays the unrounded 140.25 vB and computes its fee rate from that, which is why it shows 20.1 sat/vB rather than 20.0. The gap is a display choice, not a discrepancy in the transaction. For the Pizza transaction, with no witness, all three numbers moved together.
The RBF flag no longer means what it used to
BIP-125 says a transaction opts in to replacement if any input has a sequence number below 0xfffffffe. This input uses 0xfffffffd, so it signals; the Pizza transaction's 0xffffffff inputs do not. BIP-125 framed the signal as a warning to recipients that the payment might be replaced before confirming, which led many to treat non-signalling payments as safer. That reading is out of date: Bitcoin Core's policy document records that full replace-by-fee became the default in version 28.0 and that signalling is no longer required. A replacement must still pay at least the total fee of what it replaces, plus an increment for its own size, and it can send the coins anywhere.
So any unconfirmed Bitcoin payment can be swapped out. On mempool.space a replaced transaction shows "This transaction has been replaced by:" with the new txid, plus an "RBF Timeline". If that notice appears on a payment you were promised, read the replacement's outputs. If your address is gone, you were not paid.
Sent, Confirmed, Final
"I sent it" can mean four different things, and many payment disputes start there. The Bitcoin developer guide gives a ladder of confirmation levels; Ethereum adds an explicit finality step.
| What the page shows | Bitcoin | Ethereum | Treat as received? |
|---|---|---|---|
| Not found | Never broadcast, dropped, or replaced | Same | No. Ask for the txid again and try a second explorer |
| Pending / unconfirmed | In the mempool; replaceable by a higher-fee version | Waiting for inclusion; replaceable by a same-nonce transaction | No |
| 1 confirmation | In the latest block, which the developer guide says is replaced fairly often by accident | Included; Etherscan now shows Success or Fail | Low-value only |
| Several confirmations | The guide suggests at least six (about an hour) for high-value payments | Each block adds one | Usually; services set their own thresholds |
| Finalized | No formal finality; each block adds protection | Reverting would cost at least one-third of all staked ETH, per ethereum.org | Yes |
The timestamp on a confirmed transaction is the block's time, not when the sender pressed "send". Confirmation counts also keep rising: our figures were correct when the Bitcoin tip was 972,653. On Ethereum at our check, the latest block was 26,250,390 and the latest finalized block 26,250,314, a gap of 76 blocks, about 15 minutes at one 12-second slot per block. That gap is a snapshot, not a protocol constant, but it shows how far "confirmed" and "final" can sit apart.
Ethereum Example: A USDC Transfer in the Merge Block
Ethereum pages carry more fields because Ethereum transactions can call contracts, move tokens and fail partway. Our example sits in block 15,537,394, where the Paris upgrade (The Merge) took effect on September 15, 2022. Its hash is 0x09b57a092d6cf3939eb4f9f59ef4121fa438b2b1a0544fce1772f42b3944502c. It is a type-2 (EIP-1559) transaction, so it has base-fee and priority-fee fields, and it is a token transfer, which is where most misreadings happen.
Labels are as Etherscan displayed them on October 22, 2026; values were confirmed against a public node with eth_getTransactionByHash and eth_getTransactionReceipt.
| Etherscan label | Value | How to read it |
|---|---|---|
| Status | Success | Executed without reverting; not the same as final |
| Block | 15537394 | 10,712,997 confirmations at our node check |
| Timestamp | Sep-15-2022 06:42:59 AM +UTC | Block time |
| From | 0x2FAF487A... | The account that signed and paid the fee |
| Interacted With (To) | 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 (Circle: USDC Token) | A contract, not the recipient of the tokens |
| ERC-20 Tokens Transferred | 20,270.98 USDC to 0x7eB241f6... | What actually moved, decoded from the log |
| Value | 0 ETH | Counts only ether |
| Transaction Fee | 0.002635103832064956 ETH | Gas used times effective gas price |
| Gas Price | 54.290620188 Gwei | Base fee plus priority fee |
| Gas Limit & Usage by Txn | 76,564 / 48,537 (63.39%) | Cap versus consumption |
| Gas Fees | Base 48.811794595 / Max 1,000 / Max Priority 5.478825593 Gwei | Block base fee and the sender's two caps |
| Burnt | 0.002369178074257515 ETH | Base-fee portion, destroyed |
| Txn Savings | 0.045901896167935044 ETH | Max-fee cost minus actual cost |
| Txn Type | 2 (EIP-1559) | Base fee plus tip pricing |
| Nonce | 4630922 | The account's transaction counter |
| Position In Block | 78 | Index in the block, counting from 0 |
| Input Data | transfer(address to, uint256 value), MethodID 0xa9059cbb | The decoded contract call |
| Logs (1) | One Transfer event | The record that balances changed |
Why "Value: 0 ETH" is not a red flag
Ethereum.org defines Value as the amount of ETH sent, denominated in wei. A stablecoin is not ether; it is a balance kept inside a token contract. To move it, the sender calls the contract's transfer function with zero ETH attached, which is why "To" shows the USDC contract and Value shows zero.
The tokens appear in two places. The input data shows the instruction, and the log shows the result. The ERC-20 standard requires a Transfer event whenever tokens move. Here the log's data field holds 20,270,980,000 base units, and USDC uses 6 decimals (we read this from the contract's decimals function), so that is 20,270.98 USDC. The same raw number on an 18-decimal token would be a tiny amount.
Check the contract address, not the name. Anyone can deploy a token called "USDC". Circle publishes the real Ethereum contract, 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48, on its developer site, and that is the contract this transaction called. A token with the right symbol from the wrong contract is worthless, and it is a standard prop in fake-payment scams.
Gas: four numbers, one fee
Effective gas price = 48.811794595 + 5.478825593 = 54.290620188 gwei. Fee = 48,537 x 54.290620188 gwei = 0.002635103832064956 ETH. Of that, 48,537 x 48.811794595 gwei = 0.002369178074257515 ETH was burned, and 48,537 x 5.478825593 gwei = 0.000265925757807441 ETH went to the block proposer.
At its 1,000 gwei cap and full gas limit, the transaction could have cost 0.076564 ETH. The protocol charges only base fee plus tip and refunds the rest. Etherscan's "Txn Savings" is the gap between the cap and the effective price, times gas used. It is a display convenience: nobody would ever have been charged 1,000 gwei in this block. For comparison, ethereum.org notes a plain ETH transfer needs 21,000 gas; a token transfer runs contract code, so this one used 48,537.
Nonce: the counter behind "stuck" transactions
Ethereum.org describes the nonce as a sequentially incrementing counter of the account's transactions. Each transaction must use the next nonce, and a later one cannot be included until all earlier ones are. A nonce of 4,630,922 marks an extremely busy account, such as a service's hot wallet; an account used for occasional personal transfers would show a far smaller number. The nonce is also how replacement works: a new transaction with the same nonce and a higher fee competes with the pending one, and whichever is included first wins. If one transaction has been pending for hours and later ones are queued behind it, that first one is the blockage.
Input data and logs
The input begins with four bytes, 0xa9059cbb, that select the function. Selectors are short hashes, and different names can collide: the public database at 4byte.directory lists six text signatures for 0xa9059cbb, only one of which is the ERC-20 transfer. Etherscan's decoding is dependable for verified contracts like USDC; on an unverified contract, treat a friendly decoded name as a guess.
The Logs tab shows events the contract emitted. Here there is one: a Transfer event whose first topic (0xddf252ad...) is the standard hash of Transfer(address,address,uint256), followed by sender and recipient topics and the amount in the data field. Because the token contract itself writes it during execution, the log is the cleanest proof a token transfer happened.
Failed Transactions Still Cost Money
The Merge block makes a good classroom: 46 of its 80 transactions have a receipt status of 0, meaning they failed. The block used 29,983,006 of its 30,000,000 gas limit, and every failed transaction in it paid. Ethereum.org's gas page is explicit that the fee is paid whether the transaction succeeds or fails.
| Transaction | Status | Gas limit | Gas used | Effective price | Fee paid |
|---|---|---|---|---|---|
| 0x553a3a38... | Reverted (status 0) | 200,000 | 21,496 | 2,048.811794595 gwei | 0.04404125833661412 ETH |
| 0x732fd021... | Failed (status 0) | 180,000 | 180,000, the entire limit | 200 gwei | 0.036 ETH |
The first reverted after using about 11% of its gas, but its sender had bid a 2,000 gwei priority fee to get in early, so a call that did nothing still cost over 0.044 ETH, most of it tipped to the proposer. The second consumed its whole gas limit before failing, so its sender paid for every unit authorized. Ethereum.org draws the line: a transaction whose limit is below the basic cost is rejected before inclusion and costs nothing, while one that runs out of gas during execution is reverted and still pays for all the gas provided. The first sender's very next transaction, nonce 39 in the same block, succeeded. On an address history the two sit side by side, which is how people come to believe a payment went through when only the fee did.
Internal Transactions: ETH With No Line of Its Own
Etherscan sorts activity three ways. In its own words, a normal transaction is a wallet sending ETH directly to another; an internal transaction is a transfer of ETH carried out through a smart contract as an intermediary; a token transfer covers ERC-20 or ERC-721 tokens. Each has its own tab on an address page.
Internal transactions have no hash, signature or nonce. They are value movements inside a signed transaction's execution, which the explorer reconstructs by tracing it. That explains two common puzzles. ETH arrived from a contract withdrawal, a refund or a batched payout, but no incoming transaction is listed: check Internal Txns. Or someone says "I sent you 2 ETH" and cites a contract call with Value: 0 ETH: open that transaction's Internal Txns tab, and if no 2 ETH movement to your address is there, you were not paid.
Verifying a Deposit Claim: Screenshot Versus Transaction ID
A screenshot of a wallet saying "Sent" proves almost nothing. It can be edited, or it can show a transfer that was later replaced, never confirmed, went to another network, or involved a fake token. A transaction ID points to public data you can check on a site the sender does not control. If someone will not give you a txid, treat the payment as not made. When they do, this takes about two minutes:
The same checks apply to your own transfers. Our walkthrough on withdrawing from an exchange to a wallet you control shows what to watch on the explorer as a withdrawal arrives.
Common Misreadings
| It looks like | What is really happening | The check |
|---|---|---|
| "They paid me twice", seeing two outputs | One output is the sender's change | Find your own address |
| "131 people paid" | One wallet combined many coins | See whether input addresses repeat |
| "Value: 0 ETH, so nothing was sent" | A token moved | Read token lines or Logs |
| "I received USDC" from an unfamiliar contract | Possibly a look-alike token | Compare the contract address |
| "It is on the explorer, so it worked" | It may have failed and paid only gas | Read Status |
| "My ETH arrived but there is no transaction" | It came as an internal transaction | Open Internal Txns |
| "I paid for 76,564 gas" | You pay for gas used, not the limit | Read Gas Limit & Usage |
| "No RBF flag, so it cannot be replaced" | Full replace-by-fee is the node default | Wait for confirmations |
A related trap is the look-alike address. Etherscan's own guide to address poisoning describes attackers generating addresses that match the first and last few characters of one you use, then planting zero-value token transfers or fake look-alike tokens in your history so you copy the wrong address later. Etherscan hides zero-value transfers by default. Compare full addresses, never just the ends. If an explorer shows a token permission you did not mean to grant, our guide to finding and revoking token approvals explains what it allows and how to cancel it.
If the Explorer Shows a Problem
Sometimes careful reading gives a bad answer: coins went to an address you do not recognize, a "payment" was a fake token, or someone wants a fee to "release" a transfer the explorer shows never happened. Save the txid, the explorer URL, the addresses and the time you noticed; those are the details fraud agencies ask for, and our guide on how to report a crypto scam and what evidence to send lists where each country's reports go.
For practice, open the SegWit example above on mempool.space and find the change output yourself, then move a small amount between two of your own wallets and read that transaction the same way. Before you do, the fee-rate section of our mempool and fee-rate explainer will help you choose a fee that confirms without overpaying.
Frequently Asked Questions
Why does my Bitcoin transaction show an output I did not send?
That extra output is almost always change. Bitcoin spends whole coins, so if your wallet used a coin worth more than the payment, the remainder returned to an address your wallet controls. The explorer cannot tell change from payment because the chain does not record intent, but your wallet knows which address is yours and usually hides change from your history.
How many confirmations do I need before I treat a payment as received?
There is no protocol rule. The Bitcoin developer guide says unconfirmed transactions should generally not be trusted without risk analysis, and suggests at least six confirmations, about an hour, for high-value payments. On Ethereum, a finalized block would cost an attacker at least a third of all staked ETH to reverse. Exchanges set their own thresholds per network.
Why does Etherscan show Value: 0 ETH when I sent tokens?
The Value field counts only ether. Tokens such as USDC are balances inside a contract, so sending them means calling that contract with zero ETH attached. The amount appears in the ERC-20 Tokens Transferred line and in the Logs tab. Divide the raw log amount by 10 to the power of the token's decimals to get the readable figure.
Did I lose money on a failed Ethereum transaction?
You lost the gas fee. A failed transaction undoes its state changes, so the tokens or ETH it tried to move stay put, but computation already performed is still paid for. If it ran out of gas, you paid for the whole gas limit; if it reverted early, you paid for the gas used up to that point at the price you set.
What are internal transactions on Etherscan?
They are movements of ETH that happen inside a contract's execution, such as a contract paying out a withdrawal. They have no hash or signature of their own, and explorers reconstruct them by tracing the parent transaction. If ETH reached your address but no incoming transaction is listed, check the Internal Txns tab.
Can a confirmed Bitcoin transaction still be reversed?
A transaction in the most recent block can drop out if a competing block replaces it, which the Bitcoin developer guide says happens fairly often by accident. Each block mined on top makes that less likely, and after several confirmations a reversal would need a large share of the network's mining power. Before the first confirmation, a higher-fee replacement can redirect the coins.
Sources
CryptosEyes publishes general educational research, not investment, legal, or tax advice. The transactions shown are public records used only to illustrate explorer fields; we make no claim about the parties behind them and do not recommend any explorer, wallet, token or service. Confirmation counts and explorer layouts change, so check the live page before relying on any figure.
Source & Review Basis
This article is reviewed against the source types below. Source links are provided to help readers verify primary documents, market context, and methodology independently.
Pizza transaction inputs, output, fee, size and weight; same endpoint used for the SegWit example. Checked October 22, 2026.
Independent cross-check of the SegWit example. Checked October 22, 2026.
Explorer labels and values for the Ethereum example. Checked October 22, 2026.
Normal, internal and token transfers; block confirmations. Checked October 22, 2026.
UTXOs, implicit fee, change outputs. Checked October 22, 2026.
Confirmation levels. Checked October 22, 2026.