How to read a transaction hash

What a transaction hash actually is

A transaction hash, often shortened to tx hash or txid, is the cryptographic fingerprint of a single transaction. The chain takes the transaction's serialized bytes - sender, recipient, amount, nonce, gas, signature, any calldata - and runs them through a hash function. The output is a fixed-length value that identifies that exact transaction and nothing else.

Two important properties fall out of that definition. First, the hash is deterministic: the same transaction bytes always produce the same hash. Second, it is collision-resistant for practical purposes: changing even one byte of the transaction produces an entirely different hash. That is why a tx hash is safe to use as a permanent reference.

You can think of it as a tracking number. It does not carry the transaction's contents - it just points to them, the way a parcel barcode points to a delivery record.

What format to expect by chain family

The hash function and encoding differ per chain family. The three you will see most often:

EVM chains (Ethereum, Base, Arbitrum, Optimism, Polygon, BSC, and more)

EVM transaction hashes use Keccak-256 over the RLP-encoded transaction. The result is 32 bytes, displayed as a 0x prefix followed by 64 lowercase hexadecimal characters - 66 characters total. Example shape:

0x0000000000000000000000000000000000000000000000000000000000000000

That zero hash is not a real transaction, just the empty placeholder you sometimes see in tooling. A real EVM tx hash is a random-looking jumble of 64 hex characters. tx.taxi recognises this shape via the regex ^0x[a-fA-F0-9]{64}$ and treats it as an EVM transaction candidate.

Solana

Solana transactions are identified by their first signature rather than a content hash. That signature is 64 bytes of ed25519 output, encoded in base58. The result is typically 87 or 88 characters long, made up of mixed-case alphanumerics with no 0x prefix. It looks roughly like:

4Nd1mYABCDefGHIjklMNOpQRStUvwxYZ12345678abcdefGHIJKLMNopQRStuVwxYZ12345678abcdefghIJKLMN

(Format only - not a real signature.) tx.taxi routes signatures of that shape to Solana and onward to Solscan.

UTXO chains (Bitcoin, Litecoin, Dogecoin, Dash, Zcash, Bitcoin Cash)

UTXO chains use SHA-256d (double SHA-256) over the serialized transaction. The result is 32 bytes, but historically displayed as 64 lowercase hex characters with no 0x prefix. Example shape:

0000000000000000000000000000000000000000000000000000000000000000

Bitcoin's txids and block hashes share that shape, which is why the classifier needs context to disambiguate. Other UTXO chains share the convention.

Other formats worth knowing

• XRP Ledger uses uppercase 64-character hex hashes for transactions and ledger entries.
• TON transactions use base64 hashes plus a logical time and account address, so a "tx hash" on TON often means a tuple, not a single string.
• Aptos and Sui use 32-byte hex digests, displayed with a 0x prefix, similar to EVM but produced by different hash functions.
• Aleo transaction IDs start with the at1 bech32m prefix.

What you learn from looking one up

Once you have the hash and the right chain, an explorer page tells you:

• Status - confirmed, pending, dropped, or reverted.
• Block - which block included it, and how many confirmations have piled on since.
• Timestamp - when that block was produced.
• Parties - the sender address, the recipient address, and on EVM chains the contract called (if any).
• Value - the native amount transferred plus any token transfers visible in the receipt.
• Fee - gas used, gas price, total cost in the native unit.
• Calldata - on smart-contract calls, the decoded function and its arguments (when the contract is verified).
• Event logs - on EVM, the topics and data of each log emitted, used by indexers downstream.

If the page says "transaction not found", you are most likely looking at the wrong chain or the wrong network (mainnet vs testnet). Paste the same hash at tx.taxi to get a fresh routing decision.

Finding your tx hash in the first place

Wallets surface the hash in different places, but every one of them shows it somehow. After you sign and broadcast a transaction, look for:

• A confirmation toast or modal with a "view on explorer" link - the URL of that link contains the hash.
• The activity, history, or transactions tab of the wallet - tap an entry to see its detail view, which lists the hash.
• A copy-to-clipboard button labelled "tx hash", "transaction ID", "txid", or "signature".

Hardware wallets typically display the hash on the host app, not on the device screen. Exchanges show it under withdrawal history once the withdrawal is broadcast. If your wallet only shows you a shortened form like 0x1234...abcd, click or tap to expand the full 66-character string.

Paste it at tx.taxi

The fastest workflow: copy the full hash, hit tx.taxi/, paste, press enter. The classifier looks at the prefix, length, and character set, picks the most likely chain, and 302-redirects you to the matching /tx/ page on the configured explorer. If two chains share the same format - 32-byte hex on Bitcoin and EVM, for example - tx.taxi can show a quick disambiguation step rather than guessing wrong.

That is the whole point: the hash already encodes which chain produced it. You should not have to remember which explorer to open.

Common mistakes when handling tx hashes

A handful of mistakes come up over and over when people share or paste transaction hashes. They are easy to avoid once you know what to look for:

• Trimming the hash. Wallets often display a shortened form like 0x1234...abcd. That is for display only - the actual stored hash is the full 66 characters. Always expand and copy the complete value before sharing or pasting.
• Mixing testnet and mainnet hashes. Sepolia, Goerli, Holesky, and other Ethereum testnets are separate networks with their own histories. A tx hash from one testnet will not resolve on mainnet's explorer.
• Confusing the L1 tx hash with the L2 tx hash. When you transact on an EVM L2, your transaction has its own L2 hash, but the L2's sequencer also bundles many transactions into a single L1 batch with a different hash. See what is an EVM L2 for the distinction.
• Pasting URL-encoded values. If you copy a hash out of an address bar that had it percent-encoded, the % characters will trip the classifier. Decode first.
• Confusing a block hash with a tx hash. On EVM they have the same 66-character 0x hex shape. Pasting the wrong one gives a "not found" page from the explorer because each kind goes to a different endpoint. See block hash vs tx hash.

If a paste does not resolve, the fix is almost always one of these.

Sharing a tx hash safely

A tx hash is public. Sending one to a friend, a support agent, or a developer reveals only the transaction's on-chain record - sender, receiver, amount, contract called, logs emitted. It does not expose private keys, signing seeds, or future intent. There is no harm in pasting one into a chat, a ticket, or a public forum.

That said, the address tied to the transaction is also revealed, which is unavoidable once anything has been broadcast. If you care about on-chain privacy, treat the hash and the address as a pair: anyone who has one can find the other.