Crypto Deposit Confirmations: Finality and Exchange Credit

After a wallet broadcasts a transaction, it may have a transaction hash before any block includes it. Nodes can keep different views of unconfirmed transactions, so an explorer may not display the hash immediately. While the transaction is waiting outside a block, it has zero confirmations. That status says it has not yet been recorded in the canonical chain; it does not say the receiving exchange has accepted the deposit.

When a valid block includes the transaction, it receives its first confirmation under the common counting convention. The network has recorded an on-chain event, but an application still has to detect it, check the asset and destination, and apply its own credit policy. Bitcoin's payment-processing guide distinguishes a broadcast payment from one that has been confirmed.

For Bitcoin, the block containing a transaction is one confirmation; each block built on top adds another. More blocks make replacing that history through a reorganization progressively harder, but confirmation depth is probabilistic protection rather than a promise that a transaction can never be reorganized. The Bitcoin Developer Guide explains how competing tips and later blocks affect the chain.

Bitcoin's protocol targets an average block interval of about ten minutes over time. Individual blocks can arrive much sooner or later, so three confirmations do not mean a guaranteed thirty-minute wait. Fee level, network conditions, block timing, and the receiving service's processing are different influences. A confirmation count is a chain observation, not an arrival-time estimate.

Networks do not all use the same confirmation model. On proof-of-stake Ethereum, a transaction is first included in a block; consensus can later mark checkpoints justified and finalized. Ethereum's transaction lifecycle and proof-of-stake finality guide describe these protocol states. A Bitcoin block count, an Ethereum finalized checkpoint, and a status shown by another chain are not interchangeable units.

Even a protocol-level finality label answers only a network question: how the chain treats that block under its consensus rules. It does not mean a particular exchange has credited the deposit, cleared a review, or enabled withdrawals. For bridges and wrapped assets, the source chain, bridge, and destination chain can each have their own completion conditions; see the cross-chain bridge guide.

An exchange chooses when to recognize a deposit in its internal account ledger. It may require a minimum number of network confirmations, wait for its node or indexer to observe them, and apply separate checks before trading or withdrawals are available. Those thresholds can differ by asset, network, service, account status, and time. There is no single confirmation count that applies to every crypto deposit.

Status labels can also represent different steps. Kraken, for example, describes a deposit as “Credited” when it has enough confirmations to be used for trading, while its “Successful” state indicates that withdrawals are also available. Coinbase explains that a deposit can remain “Pending” until its required confirmations are observed. These are examples of each provider's own process, not universal definitions; check the current status page for the service receiving your funds.

Suppose, purely as an example, a service asks for three Bitcoin confirmations. If a transaction is included in block 850,000, the common count is one. Inclusion in block 850,001 makes it two; block 850,002 makes it three. The transaction's count can therefore reach the service's stated threshold only after later blocks are produced.

This example does not recommend three confirmations or describe any platform's current policy. The next block has no guaranteed arrival time, and the exchange may need additional time to detect and process the deposit after the threshold is met. A reorganization can also change which recent block contains a transaction. Read the receiving platform's live requirement instead of turning an old estimate into a promise.

Start with the exact asset and network used by the sender, then obtain the transaction hash. Search that hash on an explorer for the same network. Check whether it is visible, included in a block, how many confirmations the explorer reports, and whether the transaction or smart-contract call succeeded. For an Ethereum transaction, a successful receipt is an on-chain execution result; it is not proof that a centralized exchange has posted the funds to your account.

Next, compare the destination address and any required memo or tag with the receiving platform's deposit instructions. Confirm that the platform supports that asset on that network, that the amount meets its minimum, and that the deposit address belongs to the intended account. The crypto transfer checklist covers network, address, and memo checks. Never share a recovery phrase or private key to investigate a public transaction.

If the transaction has enough confirmations for the current platform requirement but the account still does not show it, check the service's deposit-status page, maintenance notices, account notifications, and supported-network list. An on-chain transaction and an exchange's internal account entry are connected, but they are not the same record. A platform may need time to index the transaction or may place a deposit on hold for review.

Contact the receiving platform through its official support channel if its instructions say to do so. Keep the transaction hash, asset, network, amount, destination address, any memo or tag, and approximate send time available. Do not send a duplicate transfer just because the first one is pending, and do not pay an unsolicited “recovery” contact. If a transfer used an unsupported network or omitted a required memo, recovery is platform-specific and may not be possible.