Read any Ethereum transaction, field by field

Every Ethereum transaction explorer shows roughly the same page when you paste in a hash: a status badge, a block number, two addresses, a value and a fee. The layout differs between Etherscan, Blockscout, Blockchair and our own live Ethereum explorer, but the underlying data is identical, because it all comes from the same public chain. Learn to read it once and you can read it anywhere.

This guide goes through the transaction details page top to bottom. For each field we explain what it is, where it comes from and what it tells you when something goes wrong. Halfway down you will find a worked example: a real USDT transfer from 24 September 2026, decoded number by number. If you have a hash of your own that is giving you trouble, jump straight to the troubleshooting section.

The top of the transaction page: hash, status, block and timestamp

Transaction hash

The hash is a 66-character string: 0x followed by 64 hexadecimal characters. It is a Keccak-256 fingerprint of the signed transaction, so it exists the moment your wallet signs, even before the network has seen it. That is why your wallet can hand you a hash instantly, and also why a hash that never reached a block will show “not found” forever. Hashes are network-specific in practice: a transaction on Sepolia will not appear on a mainnet explorer, and mixing the two up is the most common cause of a “missing” transaction.

Status

Three states matter. Success means the transaction was included in a block and executed without reverting. Failed (Etherscan sometimes adds the reason, such as “Out of gas” or a revert message) means it was included, the fee was charged, but every state change was rolled back. Pending means the transaction is still waiting in the mempool. Since the Byzantium upgrade in 2017, the status is a simple 1 or 0 in the transaction receipt, and explorers translate it for you.

Block and confirmations

The block number tells you where the transaction lives in the chain. The confirmation count is simply the number of blocks produced since then, including its own. One confirmation means the transaction is in the most recent block. Since the Merge, blocks arrive every 12 seconds, and Ethereum reaches finality after about two epochs, roughly 12.8 minutes. After that, reversing the transaction would require destroying a huge amount of staked ETH. Exchanges pick their own confirmation thresholds, so an on-chain success can still sit as “pending” on your exchange for a few minutes.

Timestamp

The timestamp belongs to the block, not to the moment you pressed send. Explorers show it in UTC, often with a relative “2 mins ago”. If you need to prove when a payment happened, the block timestamp is the value to quote, together with the block number.

From, To, value and token transfers

From is always an externally owned account, the address whose private key signed the transaction. To is either another wallet or a contract. Explorers mark contracts with a small document icon or a “Contract” label, and verified ones often show a name tag such as Tether: USDT Stablecoin. If the To field reads “Contract Creation”, the transaction deployed a new contract and the new address appears alongside it.

Value is the amount of ETH, and only ETH, that moved directly from sender to recipient. This is where many people get confused. When you send 100 USDT, the value field shows 0 ETH, because you did not send ether. You called the transfer function on the USDT contract, and the contract updated its internal balance sheet. The real movement of tokens shows up in a separate section, labelled ERC-20 Tokens Transferred on Etherscan and Token transfers on Blockscout, where you see the actual sender, the actual recipient, the amount and the token. Our token explorer guide explains how to confirm the token itself is genuine.

Fees and gas on the transaction page, explained with EIP-1559

The fee block looks intimidating because it packs six or seven numbers together. It becomes simple once you know that every Ethereum fee is one multiplication: gas used × effective gas price.

Gas limit is the most gas the sender allowed the transaction to burn through. Gas used is what it actually consumed. A plain ETH transfer always uses exactly 21,000 gas, a typical ERC-20 transfer lands somewhere between about 45,000 and 65,000, and a swap on a decentralized exchange can use 150,000 or more. Etherscan shows the two side by side with a percentage, for example 80,000 | 46,109 (57.64%). You only pay for gas used; the rest of the limit is never charged.

Since the London upgrade of August 2021, EIP-1559 splits the price per unit of gas into two parts. The base fee is set by the protocol for each block; it rises when blocks are more than half full and falls when they are emptier. The base fee is burnt, removed from the ETH supply for good. The priority fee, or tip, goes to the validator that proposed the block. When signing, your wallet sets a max fee (the ceiling you are willing to pay per gas) and a max priority fee. The price you actually pay, the effective gas price, is the base fee plus whichever is smaller: your max tip, or the gap between your max fee and the base fee.

So when an explorer shows Burnt & Txn Savings Fees, it is showing base fee × gas used (burnt) and max fee minus effective price, times gas used (the savings, money you authorised but did not spend). Gwei is just a unit: one gwei is a billionth of an ETH. If you want to know what gas costs right now, rather than what it cost for a past transaction, use our Ethereum gas tracker.

Nonce, input data, event logs and internal transactions

The nonce is a counter attached to the sender. The first transaction an address ever sends has nonce 0, the next has nonce 1, and so on. The network processes transactions from one address strictly in nonce order, with no gaps. That rule prevents replaying the same signed transaction twice, and it is also the root cause of most “stuck” transactions, as you will see below. Etherscan also shows the position in block, the index of the transaction among its neighbours.

Input data is the payload sent to a contract. The first four bytes, such as 0xa9059cbb, are the method ID, a truncated hash of the function signature, in this case transfer(address,uint256). Explorers look that up and show a friendly Method badge. If the contract is verified, they can decode every argument too; otherwise you get raw hex. A plain ETH transfer has empty input, 0x. Some people put a short text message in the input of an ETH transfer, and explorers can show it as UTF-8.

Logs, or events, are records a contract writes while it runs. The ERC-20 Transfer event, with topic 0xddf252ad…, is how explorers know tokens moved. Swaps, approvals, NFT mints and bridge deposits all leave their own events. When a transaction does something complicated, the Logs tab is often the clearest account of what happened.

Internal transactions are not transactions at all in the strict sense. They are calls and ETH transfers that a contract performs during execution, for example a router paying out ETH at the end of a swap, or a multisig forwarding funds. They have no hash of their own and do not appear in the block’s transaction list. Explorers reconstruct them by tracing the execution, which is why some lightweight explorers do not show them. If you received ETH from a contract and cannot find it in the normal list, check the internal transactions tab. Deep tracing is covered in our smart contract explorer guide.

Transaction types 0 to 4: legacy, access lists, EIP-1559, blobs and EIP-7702

Etherscan lists the type under Other attributes; Blockscout shows it as a small label. Most wallets send type 2 today, but you will meet the others.

Type 3 blob transactions are sent almost exclusively by rollups posting their data to Ethereum. Next to normal gas they carry blobs of about 128 KB each, priced in a separate blob-gas market with its own base fee that is also burnt. The blob contents are not in the transaction itself, only commitments called versioned hashes, and consensus nodes prune the blobs after roughly 18 days. Our blob explorer guide shows where to look them up.

Type 4 set-code transactions arrived with the Pectra upgrade on 7 May 2025 through EIP-7702. They contain an authorization list: signed permissions that let an ordinary wallet point to smart contract code, gaining features such as batched calls or sponsored gas. On the page you will see the authorizing address, the delegate contract and a nonce for each entry. Treat them with care. A legitimate wallet upgrade looks exactly like this, and so does a scam that tricks someone into delegating their account to a draining contract.

Ethereum transaction explorer example: a real USDT transfer, decoded

Theory is easier with numbers. Here is a real mainnet transaction from the morning of 24 September 2026, a small USDT payment. Paste the hash into the search box below to follow along; the numbers are identical in every explorer.

Hash: 0x81c4d670213878bb8418354448b579669753b070459995b0b668a3dc579d217b

Status and position. Success, included in block 26,046,159 at 08:34:11 UTC, at position 144 of the block’s 156 transactions. That block used 14.16 million gas out of a 59.94 million limit, about 24% full, which is why the base fee kept drifting down that morning.

From and To. The sender is a regular wallet (0xF58e…F978). The To field is not the recipient but the USDT contract, 0xdAC17F958D2ee523a2206206994597C13D831ec7. The value is 0 ETH. The token transfers section shows the real payment: 30.165 USDT from 0xF58e…F978 to 0x2314…Bb4a.

Input data. It begins with 0xa9059cbb, the transfer method, followed by two 32-byte words: the recipient address padded with zeros, and 0x1cc4808. That hex number is 30,165,000 in decimal. USDT uses 6 decimals, so the contract reads it as 30.165 USDT. One Transfer event in the logs confirms the same three facts: sender, recipient, amount.

Gas. The wallet set a gas limit of 80,000 and the transfer used 46,109, or 57.6%. Type 2, nonce 19, meaning this was the twentieth transaction this wallet had ever sent.

Fees. Base fee 0.1503 gwei, max priority fee 0.0029 gwei, max fee 0.1540 gwei. The effective gas price was 0.1503 + 0.0029 = 0.1532 gwei. Multiply by 46,109 gas and you get 0.00000706 ETH, just under two US cents at the day’s price of about $2,680. Of that, 0.00000693 ETH, roughly 98%, was burnt, and a tiny 0.00000013 ETH went to the validator as a tip. The “savings” were a rounding error, because the wallet set its max fee very close to the base fee.

Two things stand out. First, fees in 2026 can be astonishingly low: the same transfer during the 2021 NFT boom could easily have cost tens of dollars. Second, nearly the whole fee was burnt rather than paid to the validator, which is what EIP-1559 intends when blocks are not congested.

Troubleshooting: pending, stuck, failed and dropped transactions

Pending for a long time

A transaction stays pending when its max fee is below the current base fee, or its tip is too small for validators to bother. Check the base fee on the gas tracker and compare it with your max fee. If the base fee drops again, the transaction may still go through on its own. If you need it now, use your wallet’s speed-up option, which re-sends the same transaction with the same nonce and a higher fee. Most nodes require the replacement to raise the fees by at least about 10%.

Stuck because of a nonce gap

If nonce 20 is pending, nonce 21, 22 and 23 will wait behind it, however high their fees. You will see this as a queue of pending transactions that never move. The fix is to deal with the lowest pending nonce: speed it up, or cancel it by sending a zero-ETH transfer to yourself with the same nonce and a higher fee. A mempool explorer is the best place to watch what is waiting.

Failed: out of gas

If gas used equals gas limit exactly (100%) and the status is failed, the transaction ran out of gas. Raising the gas price would not have helped; the limit was too low. This happens mostly when someone edits the wallet’s suggested limit by hand. You lose the fee but nothing else. Send again with the wallet’s default limit.

Failed: execution reverted

A revert means the contract deliberately refused, with gas used well below the limit. Explorers often show the reason string: “Transfer amount exceeds balance”, “Too little received” on a swap whose price moved beyond your slippage setting, or a mint that sold out. The transaction page tells you it failed; the contract’s code tells you why.

Dropped and replaced

Etherscan labels a transaction Dropped & Replaced when another transaction with the same sender and nonce was mined instead. That is normal after a speed-up or cancel: the original hash dies and a new hash carries the result. Look up the replacement, which Etherscan links to. A simply dropped transaction, evicted from the mempool without replacement, never happened at all and costs nothing.

“I sent it to a contract address”

Seeing the USDT or USDC contract in the To field of your token transfer is normal, as the example above showed. Worry only if the token transfers section shows the recipient as a token contract, meaning you pasted the token’s address as the destination. Tokens sent that way are usually unrecoverable. Before any large transfer, check the destination with our address explorer guide.

Which Ethereum transaction explorer should you use?

For everyday checks, any of them will do, and the choice comes down to what you need next. Etherscan has the richest labels and revert messages and is the explorer most wallets link to; our Etherscan review covers its limits. Blockscout is self-hostable, shows EIP-7702 and blob details quickly and has a keyless API; see the Blockscout review. Blockchair suits people who follow several chains and value privacy. Developers debugging their own transactions often prefer a local tool like Otterscan, described in our open-source explorer guide. For a ranked comparison, see the best Ethereum explorers of 2026, and if the explorer interface itself is still new to you, start with our beginner’s tour of a block explorer.

For official definitions of every field, the ethereum.org transactions documentation is the canonical reference.