How a transaction hash is made
A hash function turns input of any size into a fixed-size fingerprint. Feed it the same signed transaction and you always get the same output; change one byte, such as the amount or the nonce, and the output changes completely.
Ethereum shows transaction hashes as 0x followed by 64 hexadecimal characters, which is 32 bytes. ethereum.org gives an example starting 0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017.[1]
Since EIP-2718, a typed Ethereum transaction is encoded as a one-byte TransactionType followed by a TransactionPayload, and the EIP says signatures for new types should include the type byte in the signed data. A legacy transaction and an EIP-1559 (type 2) transaction are therefore different byte strings and produce different hashes.[2]
In the transaction lifecycle ethereum.org describes, the hash is generated when the transaction is submitted, before it is broadcast or included in a block. Wallet, node, and explorer all run the same function on the same bytes, so they arrive at the same identifier independently.[1]
Hash outputs are designed to be one-way: you cannot recover the transaction from the hash. The hash is a lookup key; the data itself lives in the nodes, and an explorer fetches it by that key.
Ethereum transactions come in several types built on EIP-2718, including the EIP-1559 dynamic-fee type (0x2) and blob transactions (type 3) introduced by EIP-4844 for rollups. Your wallet chooses the type, and it affects both the fee fields and the resulting hash.[1]
Bitcoin: txid and wtxid
In Bitcoin, the txid is the transaction's own identifier, and every input points back to earlier coins by txid plus an output index, called vout. That is how the UTXO model links spending to earlier outputs.[3]
BIP 141 (SegWit) kept the txid as the double SHA-256 of the transaction without witness data, and defined a new wtxid that includes the witness. If a transaction has no witness inputs, wtxid and txid are equal.[4]
Removing signatures from the txid fixed transaction malleability: a third party could no longer change a signature's encoding and thereby change the txid of an unconfirmed transaction.[4]
One Bitcoin transaction can pay many recipients, so the txid alone does not tell you which output is yours. Explorers list each output with its index; the pair of txid and vout is what identifies a coin you can spend.[3]
SegWit also changed how block space is counted: BIP 141 replaced the 1 MB block size limit with a block weight limit of 4,000,000, in which base data counts four times as much as witness data. That discount is why Bitcoin fee rates are quoted per virtual byte.[4]
Solana: the signature is the ID
Solana does not compute a separate hash. The first signature on a transaction, a 64-byte Ed25519 signature from the fee payer, serves as the transaction ID. Explorers display it in base58, which for 64 bytes works out to about 88 characters.[5]
Solana transactions are capped at 1,232 bytes, derived from the IPv6 minimum MTU, and each signature costs a base fee of 5,000 lamports. A transaction's recent blockhash is valid for 150 slots; after that the transaction is rejected unless it uses a durable nonce.[5]
Because the signature is the identifier, a Solana transaction's ID is known as soon as it is signed. If an instruction fails, the whole transaction is reverted, but the fees are still charged.[5]
| Chain | What identifies the transaction | Typical display |
|---|---|---|
| Bitcoin | Double SHA-256 of the non-witness serialization (txid) | 64 hex characters |
| Ethereum | Hash of the typed, signed transaction | 0x + 64 hex characters |
| Solana | First Ed25519 signature (64 bytes) | Base58, about 88 characters |
Worked example: tracing a deposit
You withdraw 0.5 ETH from an exchange to your wallet. The exchange gives you a hash like the 66-character example above. Paste it into an Ethereum explorer and check four fields: status, block number, to address, and value.[1]
If status reads Success, the block number is set, and the to address matches yours, the 0.5 ETH is on chain. The fee line shows gas used times the effective gas price; under EIP-1559 that price is the priority fee plus the base fee.[6]
If the explorer finds nothing, the transaction was never broadcast or was dropped from mempools. If it shows Pending, it has not been included yet. Neither case is fixed by resending funds; ask the sender for the correct hash or wait for the nonce to clear.
For a Bitcoin deposit, the same check uses confirmations instead of a status field. The explorer shows how many blocks sit on top of the one containing your transaction; the Bitcoin whitepaper shows that the chance of an attacker reversing it falls exponentially as blocks are added, and the recipient decides how many to wait for.[7]
See also: Etherscan · Blockscout · Solscan · Etherscan alternatives
What a hash does and does not prove
A hash confirms that a specific transaction exists. It does not identify a person, and it does not confirm that an exchange credited your account: exchanges apply their own crediting rules.
The same hash on the wrong network finds nothing. An Ethereum hash pasted into an Arbitrum or Base explorer returns no result, because each chain has its own history even when the address format is identical.
Scammers sometimes send a real transaction hash to prove a payment that went to a different address or was later replaced. Check the to address and the status on the explorer yourself rather than trusting a screenshot of a hash.
See also: Chain ID in the glossary
Where to find a transaction hash
In a self-custody wallet, open the activity or history tab and select the transaction; most wallets link straight to an explorer page that shows the hash. In an exchange, the hash appears in the withdrawal details once the exchange has broadcast the transfer.
Developers can query any Ethereum transaction with the JSON-RPC method eth_getTransactionByHash, which returns the transaction's fields, and eth_getTransactionReceipt, which returns the result after inclusion, including whether it succeeded and how much gas it used.[8]
A receipt only exists after the transaction is in a block: ethereum.org notes that the receipt is not available for pending transactions. If eth_getTransactionByHash returns the transaction but eth_getTransactionReceipt returns null, the transaction is still pending.[8]
An exchange deposit that does not appear usually has one of three causes: the hash belongs to a different network, the transaction is still pending, or the exchange requires more confirmations. The hash lets you tell these apart quickly.
On Solana, the same lookup works with the transaction signature through the RPC method getTransaction. The result includes the slot, the fee in lamports, and an error field for failed instructions.[5]
See also: Ethereum RPC endpoints · RPC endpoint in the glossary
The bottom line
Treat the transaction hash as the receipt number for any on-chain transfer. Save it when you send funds, check status and destination on the explorer for the right chain, and remember that on Ethereum a different transaction type or nonce gives a different hash, so a replaced transaction has a new ID.[2]
Educational content, not financial advice. Crypto assets are volatile; do your own research.