How to Read a Cryptocurrency Transaction Status: TXID, Confirmations, Fees and Failures

A transaction status becomes easier to read when you treat it as a chain of evidence rather than a single label. Start with the asset and network, identify the transaction by its TXID, check whether it entered a block, and then verify what the transaction actually did. This matters because “sent,” “confirmed,” and “credited” describe different stages—and may be reported by different systems.

Essential transaction-status glossary

Cryptocurrency transaction: Exact meaning: a signed instruction submitted to a blockchain network, such as transferring an asset or calling a smart contract. In plain English: it is the network-level action behind a payment, withdrawal or token transfer. Where it appears: in a wallet history, exchange withdrawal record or blockchain explorer. Decision affected: whether you should wait, investigate the transaction on-chain or contact the service processing the deposit or withdrawal. Ethereum, for example, defines transactions as cryptographically signed instructions that update network state. ^[1]
Blockchain: Exact meaning: an ordered record of blocks whose data is linked and validated according to a network’s consensus rules. In plain English: it is the ledger where confirmed transactions are recorded. Where it appears: in project documentation and explorer descriptions of blocks, heights and confirmations. Decision affected: whether a transaction is merely announced to the network or has become part of its accepted history. Blocks contain ordered transactions and reference earlier blocks, creating the chain used to verify transaction history. ^[2]
Network: Exact meaning: the blockchain environment on which an asset and its transactions exist. In plain English: it is the route used to send the asset. Where it appears: in wallet send screens, deposit instructions, withdrawal forms and explorer names. Decision affected: which address format, fee asset and explorer you must use. An asset ticker alone is not enough: the sending and receiving sides must support the same network.
Coin: Exact meaning: the native asset of a blockchain, generally used to pay that network’s transaction fees. In plain English: it belongs to the network itself—BTC on Bitcoin and ETH on Ethereum are familiar examples. Where it appears: in wallet balances, fee estimates and transaction records. Decision affected: whether the wallet has the native asset required to submit a transaction.
Token: Exact meaning: an asset represented through rules or a contract on an existing blockchain rather than serving as that blockchain’s native coin. In plain English: the token travels using another network’s infrastructure. Where it appears: in token-transfer records and, on smart-contract networks, under a contract address. Decision affected: which network must be selected and which native coin may be needed for the fee.
Address: Exact meaning: an identifier used as a transaction’s source or destination. In plain English: it tells the network where the asset is coming from or going. Where it appears: as “from,” “to,” “sender,” “recipient” or “deposit address.” Decision affected: whether the transaction reached the intended destination. Check the complete address before signing; malware and address-poisoning scams can exploit users who compare only a few characters. Cryptocurrency transfers are generally not reversible through a conventional chargeback process. ^[3]
Memo or Tag: Exact meaning: an additional destination identifier required by some receiving services or asset networks. In plain English: the address may identify the service, while the Memo or Tag identifies your account within that service. Where it appears: in deposit instructions and transaction details when applicable. Decision affected: whether a correctly addressed transfer can be assigned automatically to the intended customer. Never invent this value or reuse one from an unrelated deposit instruction.
Transaction fee: Exact meaning: the amount paid for network processing and inclusion of a transaction. In plain English: it pays for blockchain resources; it is not necessarily a fee retained by the receiving wallet or exchange. Where it appears: in the wallet confirmation screen and explorer transaction details. Decision affected: why the received amount may differ from the amount deducted and why a transaction may remain pending when network demand or fee-selection rules affect priority.
Gas: Exact meaning: on Ethereum and compatible execution environments, gas measures the computational work required by a transaction. In plain English: the operation consumes units of work, and the gas fee pays for those units. Where it appears: as gas used, gas limit and fee-per-gas values. Decision affected: whether you are looking at an execution cost rather than the amount transferred. Gas fees can still be charged when an included smart-contract transaction fails because the network performed computational work. ^[4]
TXID or transaction hash: Exact meaning: the cryptographic identifier of a particular transaction. In plain English: it is the reference number used to locate the transaction on the correct network. Where it appears: in wallet history, withdrawal details, support correspondence and an explorer search field. Decision affected: whether a claimed payment can be checked independently. Copy a TXID; never share a seed phrase or private key to “verify” a transfer.
Pending or unconfirmed: Exact meaning: the transaction has been broadcast or recognized by a service but has not yet been included in an accepted block. In plain English: the network may know about it, but it is not confirmed on-chain. Where it appears: in wallets and explorers, sometimes alongside “in mempool.” Decision affected: whether waiting is appropriate or whether the sender must investigate a fee, nonce or broadcast problem. A mempool is a node’s collection of valid transactions that have not appeared in a block, and different nodes may have different views of it. ^[5]
Block: Exact meaning: a validated batch of transactions added to the blockchain. In plain English: once a transaction is placed in a block, it has received its first on-chain inclusion. Where it appears: as a block number, block height or block hash. Decision affected: whether the transaction is still pending or has begun accumulating confirmations.
Confirmation: Exact meaning: evidence that a transaction is included in a block, often strengthened as later blocks build on that history. In plain English: more confirmations generally mean greater confidence that the recorded transaction will remain in the accepted chain. Where it appears: as a confirmation count or a finalized/safe status, depending on the network. Decision affected: whether a wallet or service considers a deposit sufficiently settled. There is no universal confirmation threshold: the network, asset, receiving service and risk controls determine what is required. Bitcoin documentation distinguishes a broadcast transaction with zero confirmations from one included in a block, while Ethereum also exposes concepts such as justified and finalized blocks. ^[6]
Success or failure: Exact meaning: on programmable blockchains, this reports whether the requested top-level execution completed and applied its intended state changes. In plain English: a transaction can be included in a block yet fail during execution. Where it appears: in a transaction receipt or an explorer status field. Decision affected: whether a token transfer or contract action actually occurred. Ethereum receipts use a status code to distinguish success from failure, and a receipt is not available while the transaction remains pending. ^[7]
Credited or completed by a service: Exact meaning: an internal platform status indicating that the service has recognized and processed an on-chain transaction. In plain English: the blockchain may have confirmed the deposit before the service updates your account or completes an exchange order. Where it appears: in an exchange, payment processor or custodial wallet account. Decision affected: whether the issue is still on-chain or has moved to the service’s processing stage. Verification requirements can depend on the operation and the results of compliance checks, so current conditions should be reviewed before creating an order.

Connection map: from asset selection to a verifiable result

The terms form one continuous process:

Asset → exact network → destination address and optional Memo/Tag → signed transaction → network broadcast → TXID → pending pool → block inclusion → confirmations or finality → verified transfer result → service credit or order completion.

Identify the asset. Determine whether you are sending a native coin or a token. For tokens, verify the network and, when relevant, the contract identity rather than trusting the ticker alone.
Match the network on both sides. The receiving service must explicitly support the same asset on the same network. A familiar-looking address is not proof of compatibility.
Verify the destination. Compare the full recipient address with the current deposit instruction. Add a Memo or Tag only when the receiver specifies one, and confirm that it belongs to this deposit.
Review and sign. The wallet uses a private key to authorize the transaction. The seed phrase and private key should remain inside your secure wallet workflow; they are not transaction-tracking credentials. Ethereum and Bitcoin security guidance both warn that anyone obtaining these secrets may control the associated assets. ^[8]
Record the TXID. After submission, copy the transaction identifier from the wallet or sending service. Search for it only on an explorer for the selected network.
Read the inclusion state. If the transaction is pending, it has not yet reached the decisive block-inclusion stage. If a block number is shown, verify the confirmation count or finality status.
Check the outcome, not just the headline. Confirm the network, sender, recipient, asset, amount and execution result. On smart-contract networks, “included” does not automatically mean “successful.”
Separate blockchain settlement from platform processing. If the on-chain details are correct but a deposit is not credited, retain the TXID, network, address, Memo or Tag, amount and order identifier for the receiving service’s support process. Do not send another transaction merely because the platform status has not updated.

How to interpret common status labels

Transaction labels and the next useful check
Displayed status	What it usually indicates	What to check next
Created, signing or submitted	The wallet or service has prepared or accepted the request, but this alone does not prove network broadcast.	Look for a TXID. If none exists, check the sending application rather than the receiving service.
Pending or unconfirmed	The transaction has not been included in a confirmed block.	Confirm that the TXID appears on the correct network, then review the fee and any wallet-provided replacement or cancellation options. Do not use instructions from unsolicited “recovery” contacts.
Confirmed or included	The transaction is recorded in a block.	Check the number of confirmations, the recipient and the transferred asset. The receiving service may require additional settlement depth.
Success	The recorded transaction completed its top-level execution successfully.	Verify the actual token-transfer or balance-change details rather than relying only on the green status label.
Failed or reverted	The transaction was included, but its requested execution did not complete as intended.	Review the receipt and any available error information. The network fee may still have been consumed. Do not repeat the action until the cause is understood.
Dropped, replaced or cancelled	A wallet or service believes the pending transaction was removed, superseded or replaced by another transaction.	Look for a replacement TXID and compare the sender account’s transaction sequence. These labels are interface-dependent, so verify the result on-chain.
Completed by service	The platform says its own processing stage is finished.	Compare the resulting account balance or exchange outcome with the order details. This is not a substitute for checking the TXID when one should exist.

Do not confuse these related concepts

Asset and network

Asset is what you are transferring; network is the blockchain environment carrying it. The same ticker may be presented across more than one network or token implementation. Confusing them can lead to a deposit that the receiving service cannot detect or automatically credit. Before sending, match both the asset and network shown in the current deposit instructions.

Coin and token

A coin is native to its blockchain, while a token relies on an existing network. The practical consequence is fee selection: sending a token may require a separate balance of the network’s native coin. A token balance by itself may therefore be insufficient to submit the transfer.

Address and TXID

An address identifies a source or destination; a TXID identifies one transaction. Searching an address may reveal many activities, while searching a TXID should isolate the relevant transfer. When requesting help, provide the TXID—not a screenshot containing sensitive wallet data.

Seed phrase and private key

A seed phrase can restore a wallet and may control multiple derived accounts; a private key authorizes actions for a particular account or key context. Neither is needed to check transaction status. Anyone asking for either secret to release, synchronize, validate or recover a transaction should be treated as a likely phishing or theft attempt. ^[8]

Fee and gas

A fee is the amount paid for network processing. Gas is a measurement of computation used on Ethereum-style networks; the monetary fee is calculated from gas consumption and the applicable price per unit. Confusing the two can make a normal explorer record look like an unexplained second transfer.

Confirmation and success

A confirmation concerns inclusion and settlement confidence. Success concerns execution outcome. A failed smart-contract transaction can have a block number and confirmations because the network permanently recorded the failed attempt. Always inspect both fields where the network supports execution receipts.

Transaction and exchange order

A blockchain transaction moves an asset or executes an on-chain instruction. An exchange order is a service-level request that may involve deposit detection, rate calculation, compliance checks, conversion and payout. One order can therefore be associated with more than one TXID, and a confirmed deposit does not by itself prove that every later order stage is complete.

Liquidity, slippage and network confirmation

Liquidity describes how readily an asset can be exchanged, while slippage is the difference between an expected execution value and the value produced under applicable market or pricing conditions. Neither explains whether a blockchain transfer is confirmed. If an exchange result differs from an initial estimate, review the order terms; if the transfer is missing, review the network and TXID.

Practical example: checking an exchange deposit

Suppose you create an order to exchange BTC for another currently available asset. First, confirm that the specific direction and destination network are offered at that moment; support for an asset does not imply that every pair or network is available. Copy the deposit address from the active order, verify it in the sending wallet, and retain the order identifier.

After sending BTC, open the wallet’s transaction details and copy the TXID. Use it to check whether the transaction is pending or included in a Bitcoin block. Compare the destination and amount with the order instructions. Once the required blockchain confirmations have accumulated, the exchange may still display a separate processing state while it completes its internal checks and payout.

If the blockchain shows the correct confirmed deposit but the order does not advance, collect the TXID and order details before contacting support through the official channel. If you have not created the transaction yet, you can check the currently available exchange direction first. Do not assume that every asset combination or network is supported, and review the current verification requirements before creating the order.

Transaction-status checklist

Confirm the asset and exact network before searching for the transaction.
Copy the TXID from the wallet or sending service; do not type it from memory.
Use an explorer that corresponds to the selected network.
Check whether a block number or height is present.
Read the confirmation count or finality indicator.
Compare the complete destination address, not only its beginning and ending.
Verify the asset, amount and, for tokens, the relevant token identity.
Check the execution result on smart-contract networks.
Confirm any required Memo or Tag against the original deposit instructions.
Distinguish the network fee from the transferred amount and any service-level charges shown in the order.
Distinguish on-chain confirmation from wallet synchronization, exchange crediting or order completion.
Never disclose a seed phrase, private key or wallet password to track or recover a transaction.

If a TXID cannot be found, recheck the network and copy the identifier again before concluding that the transaction disappeared. A wallet may have created a local record without successfully broadcasting it, an explorer may be indexing a different network, or the value supplied may not be a TXID. When the transaction is visible and confirmed but the intended recipient or asset is wrong, stop sending further funds and contact the relevant wallet or service through a verified support channel. Blockchain confirmation proves what the network recorded; it does not correct an incorrect address, network or Memo/Tag.