How does this tool figure out the chain automatically?

It queries `eth_getTransactionByHash` against **six public JSON-RPC endpoints in parallel** (Ethereum, Optimism, Arbitrum, Base, Polygon, BSC). Five of them return `null` because they do not have the hash in their state, and one returns the transaction object. The first non-null wins and the chain is identified. The fan-out is the whole trick: there is no smart guess, just brute parallel queries that all finish in milliseconds.

What is the difference between "gas" and "gas price"?

**Gas** is the unit of computation, like CPU cycles for the chain. A simple ETH transfer uses 21,000 gas, a complex swap can use 200,000 or more. **Gas price** is how much the sender pays for each unit of gas, expressed in [[gwei||1 gwei = 1 billionth of the chain's native coin]]. The **total fee** is `gasUsed * gasPrice`, paid in the chain's native coin and deducted from the sender even if the transaction reverts.

My transaction shows "failed". What does that actually mean?

In EVM language a failed transaction is one with **status flag 0** in the receipt. It almost always means the contract called `revert()` or a `require()` check returned false. The chain still processed the transaction (block, sender nonce, gas paid) but every state change inside the call was rolled back, including any token transfers. So funds did not move, but the fee was still deducted. The exact reason for the revert is often encoded in the receipt logs.

What about "internal transactions"?

When a smart contract is called, that contract can itself call other contracts. Those nested calls are **internal transactions** (sometimes called "traces"). They do not have their own hash and do not show up in `eth_getTransactionByHash`. To see them you would need a debug tracer or an indexed explorer like Etherscan. This tool only shows the **top-level transaction** plus the Transfer events that the [[logs||structured records emitted by contracts as side effects, machine-readable]] expose.

What is a "method selector"?

When you call a function on a smart contract, the **first 4 bytes** of the transaction input are the keccak256 hash of the function signature, truncated to 4 bytes. So `transfer(address,uint256)` becomes `0xa9059cbb`. This 4-byte prefix is the **method selector**. We send it to **4byte.directory** which keeps an open database of known signatures, so the UI can show you the human-readable name. If the function is obscure or custom, the selector is shown and the name says "unknown".

How do you decode token transfers from the logs?

Every ERC-20 and ERC-721 transfer emits a `Transfer(address indexed from, address indexed to, uint256 value)` event. In the receipt that becomes a **log entry** with **topic0 = `0xddf252ad...`** (the keccak256 hash of the event signature). We filter logs by that topic, then read **topic1** as the from address, **topic2** as the to, and the **data field** as the amount (or token id for NFTs). The token contract is the log's `address` field.

I see the same hash on two chains as "wrapped". What is happening?

You probably looked at a **bridge transaction**. A bridge typically burns or locks tokens on chain A and mints a wrapped equivalent on chain B. The two transactions are completely separate on-chain events with **different hashes** on different chains. This tool reports the chain that holds the hash you pasted. If you want to see the other side, you usually need the bridge UI or a cross-chain indexer.

Why does a hash never appear on more than one chain?

A hash is a fingerprint of the **chain id** alongside every other field. EIP-155 added the chain id to the signed payload to prevent **replay attacks**: a transaction signed for Ethereum cannot be replayed on Polygon because the chain id baked into the signature does not match. So a single hash is unique per chain by construction. Even identical-looking transfers on two chains have different hashes.

Does this tool work for pending transactions?

It can detect a pending transaction (the receipt is missing because the chain has not included it in a block yet), but most useful fields are only available after inclusion. If you query a hash that is still in the [[mempool||pool of submitted but not yet mined transactions]], you will see the sender, recipient, value and chain, but the block, status, gas used and logs come up empty until the block lands.

YourDevToolsPro

TX hash detective

Paste a 0x transaction hash and see which EVM chain it lives on, who was the sender and receiver, how much gas it cost, and what tokens it moved. Auto-detects across six chains. No wallet, no API key.

LiveRuns in your browser

EVM transaction hash detective

Paste a 0x transaction hash. The server queries six public JSON-RPC endpoints in parallel (Ethereum, Optimism, Arbitrum, Base, Polygon, BSC), picks the chain that recognises the hash, and shows status, gas, USD value, token transfers, and the method signature.

What we do with this query

We do not store the hash, the result, or your IP. The result for a single hash lives only in memory for five minutes, so repeated checks do not hammer public RPC nodes. After that the cache entry is gone. No database, no logs.

You can query this endpoint up to 30 times per hour from a single IP. Cached lookups do not count against the limit.

What this tool does

Paste any 0x transaction hash and we figure out which EVM chain it lives on plus everything important about it: block, status, sender, receiver, value, gas, the method that was called, and any ERC-20 or ERC-721 transfers it produced.

You do not need to know the chain in advance. The server fires the same query at six big EVM networks in parallel (Ethereum, Optimism, Arbitrum, Base, Polygon, BNB Smart Chain) and reports back as soon as one of them recognises the hash. No wallet, no API key, no sign-in.

How to use it

Paste a transaction hash in the input box. The format is 0x followed by 64 hex characters. Case does not matter.
Click Find it (or pick one of the sample hashes). The server fans out to all six chains at once and usually answers in under two seconds.
The top banner tells you which chain the hash belongs to, the status (success, failed, pending), and the transaction type (plain transfer, contract call, or contract deploy).
The stats grid shows the block number, block time, value moved in the chain's native coin (with USD equivalent), gas used, gas price in gwei, and the total fee paid.
The From and To cards have copy buttons for each address. The To card also links straight to the ENS resolver in case the address has a name registered.
If the transaction is a contract call, the Method panel shows the selector and the matching function signature looked up at 4byte.directory.
Any ERC-20 / ERC-721 transfer the transaction emitted shows up in the Transfers list (sender, receiver, token contract, amount).
Copy buttons are everywhere: hash, addresses, raw JSON. The raw JSON has every field the chain returned, useful for debugging or piping into another tool.

When this is useful

Seven typical detective scenarios:

You have a hash but no idea which chain it is on: somebody sent you a screenshot, a support ticket, a Discord message. One paste and you know.
Quick "did the transfer succeed?" check: green badge means the chain accepted it, red means it reverted and the recipient never got the funds.
Debug failed contract calls: see the method selector and signature so you know exactly which function the user tried to call before the revert.
Audit a bridge or swap: confirm the source chain, see which tokens moved, what the bridge contract was, and how much gas the whole journey burned.
Triage suspicious activity: paste a hash from a scam report and immediately see the chain, sender, recipient, and any token contracts it touched.
Newsroom / OSINT: a journalist gets a tip with a hash. This tool tells them whether it is real, what chain, and the parties involved without opening five block explorers.
Build a transaction archive: the raw JSON copy gives you a stable record of the on-chain data exactly as the chain saw it, useful for legal disputes or post-mortems.

Questions and answers

A transaction hash is a 32-byte fingerprint of every field in a transaction: sender, recipient, value, data, nonce, gas, chain id, plus the signature. It is written as 0x followed by 64 hex characters, for example `0x9da152e3c4d1fbb71f44c46de76b08fbfaf16ef9b0eafcf7e7c66c9f5dc8aa4f`. Two transactions with even one different bit produce completely different hashes, which is why a hash is a stable unique id for a single on-chain action.

Related tools

Multi-chain address activity

Paste one 0x address and see the balance, transaction count, and USD value on six EVM chains: Ethereum, Optimism, Arbitrum, Base, Polygon, and BSC. No wallet, no sign-in.

ENS and blockchain domain resolver

Type vitalik.eth, name.sol or name.bnb and see the address, avatar, IPFS content hash, and text records (Twitter, GitHub, URL). No wallet, no sign-in.

EVM gas tracker

Live gas prices on 6 EVM chains and the real USD cost of a swap or NFT mint.

ERC-20 / Token Info Lookup

Paste a contract address, pick a chain, get name, symbol, decimals, and total supply straight from the blockchain.