Etherscan connects Ethereum transactions with address, token and contract records

Transaction hashes connect an action to its block

A transaction lookup joins the sender, destination and execution status to one identifier, so related records remain traceable. For an included transaction, the hash identifies its signed instructions and the block number locates its place in Ethereum's history. Contract calls may also produce token transfers and event logs, the structured records a contract emits during execution. Those records belong to the transaction and can describe several actions within it. For a token payment, the transaction's destination can be the handling contract; transfer records separately identify the token recipient.

Block pages add wider network context, including timestamps, included transactions, gas usage and the base fee per gas. Their transaction count covers transactions included directly in the block. ETH movements inside contract execution appear separately as internal transactions; they do not represent additional independently signed transactions.

Address histories and token pages answer different questions

An address page collects activity around an Ethereum address, while a token page follows one token contract across holders and transfers. The address view includes its ETH balance, token holdings and separate activity categories. Token transfers and transfers of non-fungible tokens (NFTs) have their own records, so a balance alone cannot explain every movement. An address can represent an account someone controls or a smart contract running programmed rules.

Balances and public labels

Public name tags add identifying context to an address. The address itself remains the exact identifier. Sharing it exposes its public balances and transaction history to anyone performing a lookup.

Tokens and NFTs

Token pages show a contract's transfer activity, reported supply and holder distribution. ERC-20 describes a common standard for interchangeable tokens; ERC-721 represents individually identified NFTs. ERC-1155 supports multiple token types within one contract. NFT records can include the contract address, token ID and ownership details. A familiar name or symbol does not establish a token's identity, since unrelated contracts can reuse them.

Displayed prices and project descriptions add information beyond blockchain records. Non-standard token mechanics can also make a reconstructed transfer history diverge from a balance. For those contracts, a contract balance query may clarify the discrepancy.

What does a transaction's status confirm?

Transaction status distinguishes a pending submission from successful or failed execution; block information separately describes inclusion and confirmation. Pending means the explorer has seen a transaction awaiting block inclusion. Dropped means its connected nodes stopped retaining that pending transaction. A replacement uses the same sending account and nonce, the account's transaction sequence number. A confirmed replacement supersedes the earlier submission.

Included transactions

Successful execution

Success means execution completed without reverting the transaction as a whole. Token-transfer records describe the assets and recipients involved. Confirmation counts increase as later blocks extend the chain. Finality is a separate consensus milestone for the containing block, beyond its initial inclusion.

Failed execution

A failed included transaction reverts its execution changes while still charging for consumed gas. Its failure reason may identify a contract rejection or exhausted gas. The failed action remains visible in the transaction history.

---

Matching a token payment to the intended receipt

For a standard ERC-20 payment, receipt requires the intended amount to reach the intended address in the correct token. Match the network and token contract before using the transaction hash to inspect its token-transfer details.

View full-size image

• The transaction belongs to the Ethereum network you expected.
• The emitting token contract matches the token you intended to receive.
• The transfer names the intended recipient and expected token amount.
• The containing transaction has succeeded and shows its inclusion block.
• The recorded confirmations satisfy any requirement the receiving service applies.

Once these conditions match, the recorded transfer supplies evidence of the on-chain receipt. A receiving service may still apply deposit minimums or restrictions on accepted tokens before crediting an account. The explorer's record does not establish that separate account credit.

Gas fields separate execution cost from transfer value

Gas details explain the computation a transaction consumed and the price paid for each unit, separately from the asset it moved. Gas used measures consumed units; the gas limit caps how much the transaction can use. An Ethereum transaction's execution fee equals gas used multiplied by its effective gas price. Gas prices often use gwei. One ETH equals 1,000,000,000 gwei.

For EIP-1559 transactions, the base fee follows network demand and the priority fee compensates the validator. Ethereum burns the base-fee portion. The maximum fee per gas sets a ceiling; it does not necessarily equal the effective price charged. The Gas Tracker estimates prevailing fee conditions before submission, while a completed transaction records actual usage. Estimates change with demand and cannot establish a fixed inclusion time.

Contract tools separate code inspection from signed changes

Contract pages expose deployed bytecode and, where available, verified source code and a readable interface to its functions. Contract verification checks whether submitted source compiles to matching deployed code. Matching code can still contain unsafe logic or privileged controls; verification does not establish that anyone audited the contract. An application binary interface, or ABI, describes how software encodes function calls and decodes returned data. It helps the explorer present functions and parameters in a readable form.

Read Contract queries public data without changing blockchain state or charging transaction gas. Write Contract submits state-changing calls through a connected wallet and requires a signed transaction. The selected function and its parameters determine the effect, which can include moving assets or altering permissions.

An ERC-20 token approval grants a spender address an allowance, the amount it may transfer from the approving address. The approval checker exposes token permissions and offers revocation for supported approvals. Revocation requires an on-chain transaction and a gas fee. An allowance describes spending authority; it does not represent a completed token transfer.

Analytics and API access extend individual lookups

Analytics summarize activity across time, while API access supplies structured blockchain data for applications and repeated queries. Address and token charts reveal patterns beyond one transfer. Network statistics expose broader transaction activity and gas usage. Filters narrow visible histories to relevant records, although the explorer can only display the data its indexing and supported features expose.

The Etherscan API V2 uses an API key and a chain ID to select a supported network. Endpoints cover balances, transaction histories, token transfers and contract information. Chain coverage, request limits and access to specialized endpoints depend on the plan. The same API key can serve supported chains, but identical address text does not imply identical balances or contracts across networks.

Cross-chain transaction views link activity through supported bridge integrations. Their coverage does not encompass every bridge or route. A transfer record on one chain alone cannot establish whether the corresponding action completed on another.