What Is a Transaction Hash (TXID)? Crypto Guide 2026

Every single crypto transaction you have ever made or will ever make has its own unique fingerprint. That fingerprint is called a transaction hash, also known as a TXID or tx hash. It is a long, intimidating-looking string of letters and numbers that most beginners glance at once and ignore. That is a mistake. Sooner or later, you will need one. When your deposit at an exchange is missing, when you want to prove you paid someone in USDT, when you want to inspect what a smart contract just did with your wallet, the TXID is the only piece of information that matters.

Despite being one of the most fundamental concepts in crypto, transaction hashes are poorly explained almost everywhere. Most help articles will tell you it is a "unique identifier for a transaction" and leave it at that. That answer is technically correct but practically useless. It does not help you when Binance asks for your TXID to investigate a missing deposit, or when an OTC counterparty sends you a screenshot of a TXID claiming they paid you. You need to know how the hash is actually generated, what data it exposes on a blockchain explorer, why it cannot be faked, and how to read one across different chains.

In this guide, you will learn exactly how transaction hashes work under the hood, the precise format differences between Bitcoin, Ethereum, Solana, and Tron TXIDs, every single field a TXID exposes on a block explorer, the step-by-step process to find your TXID on Coinbase, Binance, Kraken, MetaMask, Phantom, and Trust Wallet, how to use a TXID to dispute a missing deposit, why a transaction hash cannot be forged or replayed, and the increasingly common scams using fake TXID screenshots in peer-to-peer trading. By the end, you will read TXIDs the way a mechanic reads a VIN number.

What Is a Transaction Hash?

A transaction hash, abbreviated as TXID (transaction ID) or tx hash, is a unique cryptographic identifier assigned to every transaction that gets broadcast to a blockchain. It is the receipt, the tracking number, and the search key for a transaction all rolled into one. Once a transaction is broadcast, the TXID is the only string you need to find out absolutely everything that is publicly knowable about it.

The best analogy is an airline ticket confirmation number. When you book a flight, the airline gives you a six-character booking reference. With that string you can look up the passenger name, the route, the seat number, the time, the price, and the current status of the flight. Anyone with the booking reference can pull up that data. The reference itself does not let you change the booking or steal the seat, it only lets you look it up. A TXID works the same way. With a TXID you can see who sent what to whom, how much, when, on which block, with how much gas, and whether the transaction succeeded or failed. You cannot do anything with the TXID besides look it up, which is exactly what makes it safe to share.

Every chain assigns these IDs in roughly the same way. The network takes all the data inside a transaction (sender, recipient, amount, nonce, signature, gas parameters, and any contract call data) and feeds it into a cryptographic hash function. The output is a fixed-length string that uniquely fingerprints the entire transaction. Change a single byte of the underlying transaction and the hash changes completely. This is the property that gives TXIDs their power as identifiers.

How a Transaction Hash Is Computed

The mechanism behind a transaction hash is a cryptographic hash function. A hash function takes any input of any length and produces a fixed-length output that looks completely random but is deterministic, meaning the same input always produces the same output. The two hash functions you will encounter constantly in crypto are SHA-256 (used by Bitcoin) and Keccak-256 (used by Ethereum and most EVM chains). To go deeper into the math, see our complete guide to hashing in crypto.

The flow is conceptually simple. The wallet builds a transaction object containing everything that needs to be on-chain: the sender, the recipient, the amount, the nonce (sequence number for the sender), the gas limit, the gas price, any data payload, and the digital signature proving the sender actually authorized the transaction. The node receiving the transaction serializes that object into a binary blob using a specific encoding (RLP for Ethereum, Bitcoin's transaction format for BTC). That blob is then run through the hash function once or twice depending on the chain. The output is the TXID.

The fact that hash functions are deterministic is the entire reason TXIDs work as identifiers. If you give me a TXID, I can take the original transaction data from the blockchain, run it through the same hash function, and verify the hash matches. If even one bit of the transaction data has been tampered with, the hash will not match, and we know the data is corrupted or fake. This is what makes blockchains tamper-evident.

It is also worth understanding what hashing does not do. A hash function is one-way. You cannot take a TXID and reverse-engineer the transaction data from it. The only way to find the transaction is to look up the TXID against an index of known transactions that blockchain nodes maintain. This is why block explorers exist as a service: they keep a giant searchable database of every TXID and what transaction it points to.

Bitcoin TXID: Format and the Endianness Quirk

A Bitcoin TXID is 64 hexadecimal characters long, representing 256 bits (32 bytes) of data. It is generated by running the serialized transaction through SHA-256 twice in a row, a construction called double-SHA-256 or SHA-256d. The "double" was a defensive choice made by Satoshi to protect against length-extension attacks on SHA-256.

A real Bitcoin TXID looks like this: 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b. That is the very first non-coinbase Bitcoin transaction ever, from Satoshi to Hal Finney in January 2009. You can paste it into any Bitcoin block explorer right now and pull up the original transfer of 10 BTC. It has been searchable for 17 years and counting.

Here is the quirk almost no beginner-level article mentions. Bitcoin TXIDs are computed internally using a little-endian byte order, but they are displayed in block explorers in big-endian byte order. So the hash that node software produces is literally byte-reversed compared to what you copy off blockchain.com. This is purely a display convention dating back to Bitcoin's original source code. The two representations point to the same transaction, but if you are building software that interacts with the Bitcoin RPC interface, you have to know which order each tool expects. For end users who only ever copy-paste TXIDs between explorers and exchanges, the byte-reversal is completely invisible, but it occasionally bites developers who try to manually decode the data.

Bitcoin TXIDs are also case-insensitive in hex, but explorers conventionally display them in lowercase. Pasting an uppercase version will still work everywhere. Bitcoin Cash, Litecoin, Dogecoin, and most other Bitcoin-derived chains use the exact same 64-character lowercase hex format because they inherited the codebase.

Ethereum Tx Hash: Format and Keccak-256

Ethereum tx hashes are also 256 bits long, but they use a different hash function and a different display convention. Ethereum uses Keccak-256, which is the original Keccak submission to the SHA-3 competition (not the slightly modified standardized SHA-3-256 that NIST eventually published). The transaction data is RLP-encoded, hashed once with Keccak-256, and the result is displayed in hex with a 0x prefix to indicate hexadecimal.

An Ethereum tx hash looks like this: 0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b. That 0x prefix is the giveaway that you are looking at an Ethereum-style hash rather than a Bitcoin TXID. Every EVM-compatible chain follows the same convention: Polygon, BNB Chain, Arbitrum, Optimism, Base, Avalanche C-Chain, Linea, Scroll, and dozens of others all produce tx hashes with the 0x + 64 hex character format.

One nice property of Ethereum hashes versus Bitcoin TXIDs is that they have no endianness mismatch. The hash you see in the RPC response, the hash you see in the explorer, and the hash you put back into the network for tracing are all the same string in the same order. The 0x prefix is also helpful because it lets parsers immediately recognize the value as hex without ambiguity.

Solana, Tron, and Cosmos: Other Chain Formats

Not every chain follows the BTC or ETH formatting. Solana in particular is a wildly different beast. Solana TXIDs are the signature of the transaction, base58-encoded, and they end up being around 87 to 88 characters long. They mix uppercase and lowercase Latin letters and digits, but they exclude the characters 0, O, I, and lowercase l because those are visually ambiguous in base58. A Solana signature might look like 5UfgccYAhP1zsvN3KrR3qdwAEoFD9oM57V47kuCu2hYE7XfTzGW5gQpBkAaKuY1MNQ1qDpDfu6gN6szwh1MxmKaH. There is no 0x prefix, no hex, and no leading zeros.

Tron uses a 64-character lowercase hex format that looks identical to a Bitcoin TXID. There is no prefix. Cosmos and chains in the Cosmos ecosystem (Osmosis, Celestia, dYdX v4) typically use 64-character uppercase hex hashes computed with SHA-256 over the encoded Tendermint transaction. NEAR uses base58 encoded hashes. Polkadot and Kusama use 0x-prefixed hex like Ethereum but compute the hash with Blake2b-256 instead of Keccak-256.

The practical takeaway is that you can almost always tell what chain a TXID belongs to just by looking at it. A 0x prefix means an EVM chain. A 64-char lowercase hex with no prefix is probably Bitcoin or Tron. An 87-to-88 character mixed-case alphanumeric string with no special characters is Solana. This pattern recognition saves a lot of time when troubleshooting deposits across multiple networks.

What Data You Can See from a TXID on a Block Explorer

This is where most beginner articles fail you. They tell you that you can "look up" a transaction, but they do not list everything you can actually see. The TXID is the key to a treasure chest of data, and you should know exactly what is inside. For practical walkthroughs, see our Etherscan and Solscan tutorial.

The "from" and "to" addresses tell you who sent and received. The amount and token symbol tell you what was moved. Status confirms whether the transaction was actually executed by the network or whether it reverted (paid gas but did nothing). The block number tells you in which block the transaction was finalized, and the timestamp tells you when that block was mined or attested. Confirmations count how many additional blocks have been added on top, and that number is what exchanges use to decide a deposit is "safe."

Gas and gas fees tell you exactly how much the sender paid. Logs and events are emitted by smart contracts and tell you what happened beyond a simple transfer (a swap on Uniswap will emit Swap events, an approval will emit an Approval event). Internal transactions are the value movements between contracts inside one outer transaction. Input data is the raw encoded call data that can be decoded if the contract source is verified.

How to Find Your TXID on Coinbase, Binance, and Kraken

If you just sent crypto from an exchange and need the TXID, here is the exact path on each of the three biggest centralized exchanges. The steps are essentially the same pattern: open your account history, find the withdrawal or deposit, click into it, and look for the on-chain hash field.

One thing to know is that some exchanges delay the visibility of the TXID until the withdrawal is actually broadcast. If you just clicked "withdraw" and the status is still "processing" internally, you will not see a TXID yet because there is no on-chain transaction yet. The exchange is still doing its internal compliance checks, batching the withdrawal, or just sitting in a queue. The TXID only appears once the funds actually leave the exchange wallet.

How to Find Your TXID in MetaMask, Phantom, and Trust Wallet

Self-custody wallets are usually faster and more transparent because every transaction you sign goes straight on-chain and you see the TXID immediately. Here is how to find it in the three most popular non-custodial wallets.

In MetaMask, open the extension or mobile app, click your account, and scroll to the Activity tab. Each transaction in the list is clickable. Click the one you want, and a detail panel slides out with the full transaction data. At the bottom there is a "View on block explorer" button that takes you straight to Etherscan (or the appropriate explorer for the chain you are on). The TXID is shown there both in the URL and in the page itself, ready to copy. If you only need the hash without leaving the wallet, click the three dots menu and select "View activity log details" to see the raw hash.

Phantom (the Solana-first wallet, now multi-chain) works similarly. Open the wallet, tap the activity icon or recent transactions list, and tap the transaction you care about. The detail view shows the signature (which is the Solana equivalent of a TXID) and a button to view it on Solscan or Solana Explorer. Solana signatures are long base58 strings, so you will want to copy them rather than try to retype them.

Trust Wallet, common on mobile, lists transactions per asset. Tap a token, scroll down to History, tap a row, and you get a "View on Explorer" button at the bottom. The TXID is also shown in the details panel above that button. Because Trust supports many chains, the explorer it opens varies depending on the network of the transaction (BscScan for BNB Chain, PolygonScan for Polygon, Tronscan for Tron, etc.).

If you ever revoke permissions through Trust or MetaMask, that revocation is also a transaction and produces its own hash. See our guide on crypto approval transactions for why this matters.

Confirming a Deposit at an Exchange Using a TXID

The single most common scenario in which someone urgently needs a TXID is when a deposit at an exchange is missing or stuck. Here is the workflow that actually resolves it.

First, retrieve the TXID from the sending side. If you sent from a self-custody wallet, follow the MetaMask, Phantom, or Trust Wallet steps above. If you sent from another exchange, follow the Coinbase, Binance, or Kraken steps. Get the full hash on the clipboard.

Second, paste the TXID into a block explorer for the correct chain. This is critical. If you sent USDT on Tron and try to look it up on Etherscan, you will get nothing because Etherscan only indexes Ethereum mainnet. USDT on Tron lives on Tronscan. USDT on BNB Chain lives on BscScan. USDT on Polygon lives on PolygonScan. Pick the right explorer for the network you used.

Third, verify three things on the explorer page. The "To" address should match the deposit address the exchange gave you. The status should say Success. The number of confirmations should be equal to or greater than what the exchange requires (typically 1 for Solana, 6 for Bitcoin, 12 to 32 for Ethereum, varies for other chains). If all three are true, the transaction is done from the blockchain's perspective. Anything missing is on the exchange's side, not the network's.

Fourth, if confirmations are met but the exchange has not credited the deposit, open a support ticket and attach: (a) the TXID, (b) a screenshot of the explorer page showing Success and confirmations, (c) the deposit address you sent to, (d) the timestamp. With these four pieces of information, the support team can locate the deposit in their internal ledger within minutes. Without the TXID, they cannot do anything for you, and the ticket will languish.

The exchange might tell you the deposit was sent to the wrong network (e.g. you sent ERC-20 USDT to a BEP-20 deposit address). Some can recover these "wrong network" deposits with a manual process and a fee. Others cannot. The TXID is what allows them to even attempt the recovery.

Why TXIDs Cannot Be Faked

Here is the property that makes transaction hashes useful as proof of payment. They are deterministic and cryptographically bound to the transaction data. If someone tries to construct a "fake" TXID, they would need to either:

(1) Find a hash collision in SHA-256 or Keccak-256. This is the cryptographic equivalent of winning every lottery on Earth simultaneously for the rest of human history. Modern hash functions have no known feasible collision attacks. Producing a fake TXID that matches a real one is not happening.

(2) Forge a transaction and broadcast it. This fails because every transaction must be signed by the private key of the sender. Without the private key, no signature, no valid transaction, no TXID. The signature is part of the data being hashed, so changing the sender invalidates everything.

(3) Replay an old transaction. Modern chains have replay protection built in. Ethereum uses the nonce (a counter that increments with every transaction from that account) to prevent the same transaction from being included twice. Bitcoin uses the fact that UTXOs can only be spent once. Solana uses recent blockhash references. You cannot just rebroadcast yesterday's transaction and pretend it is new.

This determinism is what makes TXIDs admissible as proof in legal disputes, exchange tickets, and accounting reconciliation. The hash is mathematically tied to a single specific event that happened at a specific time and was signed by a specific wallet. It cannot point to anything else.

Mempool vs Confirmed: When the TXID Becomes Real

A transaction goes through two phases. First, after you sign and broadcast it, it enters the mempool. The mempool is the network-wide queue of unconfirmed transactions waiting to be included in a block by validators or miners. During this phase, the TXID already exists and is searchable, but the transaction has not been finalized. It can still fail, be dropped, or be replaced.

Once a validator includes the transaction in a block and that block is added to the chain, the transaction is "confirmed." Each additional block added on top of it is one more confirmation. The more confirmations, the more economically expensive it would be to reverse the transaction through a chain reorganization, which is why exchanges and merchants set confirmation thresholds before crediting deposits.

On Bitcoin, six confirmations (roughly an hour) is considered very safe. On Ethereum mainnet, twelve confirmations (about two and a half minutes) is the standard, though many exchanges have raised this to 32 or more after the merge to align with finality. On Solana, finality is much faster but expressed differently because Solana uses a different consensus model. The block explorer will show you exactly how many confirmations a TXID has at any time.

If a transaction sits in the mempool with too low a fee and never gets included, it will eventually be dropped by nodes (typically after 14 days on Bitcoin, sooner on Ethereum). The TXID will then become "not found" again. This is rare in 2026 thanks to better fee estimation in wallets, but it still happens during fee spikes.

Common Scams: Fake TXID Screenshots in P2P Trading

This scam is rampant in OTC and peer-to-peer trades, and it has fooled experienced traders. The setup: you agree to a P2P trade, the counterparty claims they sent the crypto and sends you a screenshot of an explorer page showing a green Success status and your address. You release your side of the trade. Then you realize the screenshot was either fake, the wrong transaction, or a tiny test amount with the screenshot zoomed in to look bigger.

More sophisticated variants involve sending a real on-chain transaction that looks legitimate but is for a worthless lookalike token. The classic is sending you USDD or USTC instead of USDT, hoping you do not notice the slightly different ticker. Always confirm the token contract address on the explorer matches the official USDT contract for that chain.

Another variant uses "zero-value" transactions or address poisoning where a scammer sends a 0-value transfer from a vanity address that mimics one of your real counterparties, so the scam address appears in your transaction history and you accidentally copy-paste it later. Always verify full addresses, never just the first and last few characters.

Replace-By-Fee (RBF) and TXID Malleability

Two technical wrinkles affect Bitcoin TXIDs specifically: replace-by-fee and historical transaction malleability.

Replace-by-fee is a feature where the sender of an unconfirmed Bitcoin transaction can broadcast a new version of the same transaction with a higher fee, and miners will preferentially include the higher-fee version. The new transaction has a different TXID because the data is different (the fee changed). If you are watching the mempool for a deposit and the sender does an RBF, you will see the original TXID disappear and a new TXID appear with the same logical transfer. This is intentional. It is a feature, not a bug. Most modern wallets show RBF replacement as a chain of related TXIDs.

Transaction malleability was a historical bug in Bitcoin where the signature part of a transaction could be tweaked by a third party (without invalidating it) in a way that changed the TXID before confirmation. This caused several incidents in Bitcoin's early days, notably the Mt. Gox saga. SegWit, activated in 2017, fixed this by moving the signature data outside the part that gets hashed for the TXID. Post-SegWit, Bitcoin TXIDs are not malleable. Ethereum never had this problem because of how it serializes and hashes transactions.

Using TXID as Proof of Payment

Because TXIDs are cryptographically unforgeable and tied to specific on-chain events, they make excellent proof of payment. If you owe someone in crypto, paying them and sending the TXID is functionally equivalent to a bank wire reference number, except it is verifiable by anyone with internet access and is impossible to fake.

Tax authorities in most jurisdictions accept TXIDs as evidence of crypto transactions for capital gains reporting. Auditors use them to reconcile crypto holdings. Courts in several jurisdictions have admitted TXIDs as evidence in fraud and asset recovery cases. Some merchants explicitly request the TXID after checkout to log the payment in their order system.

The one trade-off is privacy. Blockchain ledgers are public by default. Anyone with the TXID can see the from address, the to address, the amount, and any other transactions either address has ever made. If you give your TXID to someone, they now have a link to your wallet. That is fine for one-off proofs, but it is a privacy concern if you use the same wallet for both personal and business activity. For sensitive payments, consider using a freshly generated address.

TXIDs in Smart Contract Interactions

Not every transaction is a simple transfer. When you interact with a smart contract (approving a token spend, swapping on Uniswap, minting an NFT, voting in DAO governance), you are creating a transaction that calls a function on a contract. That transaction still gets a single TXID, but the explorer page for it shows much richer data than a simple send.

In particular, the Logs / Events tab on Etherscan-style explorers shows every event the contract emitted as part of executing your transaction. A Uniswap swap will emit a Swap event with the input and output amounts and the pool address. An ERC-20 transfer will emit a Transfer event. An ERC-721 mint will emit a Transfer event from the zero address. These events are how indexers, dApps, and aggregators reconstruct what is happening on-chain at the application layer.

If the contract is verified on the explorer (meaning the source code has been uploaded and matches the deployed bytecode), the Input Data tab will show a human-readable decoded function call: the function name and each argument with its value. This makes complex contract interactions debuggable. Without verification, you only see opaque hex data.

Internal transactions are another category. When your transaction calls a contract that in turn calls another contract, the inner contract-to-contract calls do not get their own outer TXID, but they are recorded as internal transactions under the same outer TXID. Explorers expose these in a separate tab. This is how you can audit complex DeFi flash transactions all from one starting hash.

Frequently Asked Questions

Conclusion

A transaction hash is the most important piece of information in any crypto transfer you will ever make, and yet it is the one most beginners ignore until something goes wrong. Now you know what it actually is: a cryptographic fingerprint computed by SHA-256 or Keccak-256 over your transaction data, tied uniquely and tamper-proof to that one event on-chain. You know how to read the format across Bitcoin, Ethereum, Solana, and Tron, what fields it unlocks on a block explorer, and how to extract it from any major wallet or exchange.

The next time a deposit goes missing, you will not panic. You will pull the TXID from the sending platform, paste it into the right explorer, verify the to-address, status, and confirmations, and either confirm the network did its job (and the exchange owes you the credit) or identify exactly where the failure was. The next time someone tries to flash a screenshot at you in a P2P trade, you will paste the hash into the explorer yourself and verify the amount and destination match before releasing anything. And the next time you interact with a smart contract, you will know how to read the logs and events to confirm exactly what your transaction did.

The transaction hash is the single most powerful tool for self-sovereignty in crypto. Public ledgers only mean anything because every transaction is permanently identifiable, auditable, and reproducible from its hash. Learn to use them well, and you will spend a lot less time arguing with support agents and a lot more time actually getting on with whatever you wanted to do on-chain.

Related Guides

• What Is Hashing in Crypto: SHA-256 and Cryptographic Hash Functions Explained (2026)
• Why Is My Crypto Transaction Pending? Complete Troubleshooting Guide (2026)
• What Is UTXO in Crypto? Unspent Transaction Output Explained 2026
• Why Did My Crypto Transaction Revert? Causes and Fixes
• What Is Propy (PRO)? The Blockchain Real Estate Transaction Platform Explained in 2026