Crypto confirmations measure a transaction's depth in the current canonical chain. Finality is a chain-specific settlement condition, while exchange credit is the venue's decision to make a deposit usable. A confirmed transaction is not automatically finalized or credited. Check the exact network, successful transfer, chain settlement evidence and receiving venue's current deposit policy separately.
Four checks behind a deposit status
A wallet saying “sent” describes the sender's view. An explorer saying “success” describes an on-chain outcome. Neither is the receiving exchange's account ledger. Start by identifying the current canonical chain: the accepted branch whose blocks your observation follows.
| Check | Evidence to retain | What it does not establish |
|---|---|---|
| Inclusion | Transaction's canonical block hash, height and execution result | That intended assets arrived or the block is finalized |
| Confirmation depth | Inclusion height, current head height and counting convention | That the exchange has posted the deposit |
| Chain settlement | Protocol finality evidence, or the chosen proof-of-work acceptance depth | That the asset and network are supported |
| Account availability | Receiving venue's deposit record and available balance | That trading and withdrawal permissions are identical |
Broadcast comes before these checks. A transaction hash lets you look for an attempt; it does not prove that a block contains it. If a sender is a multisig wallet, collecting signatures is also separate from executing its transfer. The multisig threshold and signer independence guide addresses that authorization boundary.
Confirmation counting needs a definition. Kraken's processing documentation counts the inclusion block as confirmation one and adds one for each subsequent block. Under that convention, depth equals current head height minus inclusion height plus one, provided the inclusion block remains on the canonical branch. Kraken's confirmation explanation is a venue example, not a universal settlement guarantee.
Bitcoin: follow a three-confirmation deposit
Bitcoin's proof of work makes revision of accepted history progressively more demanding as work accumulates. Competing valid branches can exist, and nodes follow the branch with the greatest accumulated work. A height alone does not uniquely identify a block during a fork; retain its hash too. This is probabilistic settlement rather than a checkpoint that becomes unconditionally irreversible after a particular count. See the Bitcoin developer guide on forks and proof of work.
As reviewed on 28 October 2026, Kraken's deposit processing FAQ states that Bitcoin deposits are credited after three confirmations. That is a dated venue requirement. Check the current policy for the exact receiving account and network before relying on it.
Here is a hypothetical Bitcoin deposit using that three-confirmation threshold. All timestamps, block heights and posting delays are invented. Assume a supported deposit, correct destination, sufficient amount, no account hold and no reorganization. This is not a measured Kraken transfer or a promised processing time.
| Hypothetical time, UTC | Observed event | Confirmation count | Account evidence |
|---|---|---|---|
| 09:00 | Transaction broadcast | 0 | No spendable deposit |
| 09:04 | Included at height 1,000,000 | 1 | Threshold not reached |
| 09:11 | Head reaches 1,000,001 | 2 | Threshold not reached |
| 09:27 | Head reaches 1,000,002 | 3 | Threshold reached; posting still to verify |
| 09:28 | Head unchanged; receiver posts deposit | 3 | Trading balance now verified |
At 09:27, the calculation is 1,000,002 − 1,000,000 + 1 = 3. Three confirmations require two additional blocks after inclusion. From first inclusion to the threshold, 23 minutes elapsed in this invented path; from broadcast to verified credit, 28 minutes elapsed. Neither duration follows mechanically from the count.
If a reorganization removes the inclusion block and the transaction is absent from the replacement branch, the old depth no longer applies. If it is later included again, calculate from its new inclusion block. Increasing wall-clock age does not preserve an obsolete confirmation count.
This distinction matters when capital must arrive before another action. The transfer-latency guide follows the wider journey from execution to spendable inventory; the settlement check here is one component of that journey.
Ethereum: inspect finalized state separately
Ethereum mainnet uses proof-of-stake checkpoint finality. Its documentation describes checkpoint votes representing at least two-thirds of staked ETH. Finality has explicit consensus assumptions and economic protection: conflicting finalized histories imply at least one-third of staked ETH is subject to slashing. It is a stronger property than observing another block at the head. Ethereum's proof-of-stake documentation explains that mechanism.
Crucially, Ethereum can keep processing transactions while finality lags or stalls. The Ethereum Foundation's explanation of the unfinalized chain distinguishes the current head from the finalized history. A rising confirmation counter therefore cannot, by itself, prove that finality advanced.
Ethereum's JSON-RPC documentation distinguishes latest, safe and finalized block tags. A technical check can retrieve the transaction receipt, inspect its inclusion block, and query the finalized head with eth_getBlockByNumber. The receipt's block must be the finalized block or an ancestor of it. Do not silently treat a latest or safe observation as finalized.
Consider a second hypothetical example. Let H be the inclusion height, 25,000,100. All observations below refer to one consistent canonical branch, and the transfer succeeded. The fictional receiver requires finality followed by internal posting. This is an invented policy, not Kraken's Ethereum requirement.
| Observation | Current head | Finalized head | Depth | Deposit state |
|---|---|---|---|---|
| First inclusion | H | H − 80 | 1 | Included; unavailable |
| Finality has stalled | H + 64 | H − 80 | 65 | Still not finalized |
| Finality catches up | H + 96 | H + 16 | 97 | Finalized; not yet posted |
| Receiver posts credit | H + 97 | H + 16 | 98 | Available in the account |
At the second observation, 25,000,164 − 25,000,100 + 1 = 65 confirmations, but the finalized head is still 25,000,020. The deposit lies beyond finalized history. At the third, the finalized head is 25,000,116, a descendant of the deposit's block under the stated branch assumption. The deposit is now finalized even though account posting still waits.
The offsets make the logic reproducible; they do not estimate normal finality time or an exchange service level. In an actual investigation, compare block hashes and ancestry as well as heights. Two providers with inconsistent chain views cannot be reconciled safely by choosing whichever reports the larger number.
This example uses Ethereum mainnet's settlement model. A rollup sequencer response, a layer-one posting, a bridge completion and a destination exchange credit can be separate events. Do not transplant this table's labels onto another network without its own documentation.
Enough blocks can still leave the deposit unavailable
First check execution. Ethereum's receipt specification distinguishes top-level success from failure and records the block hash and number. A failed transfer can be deeply confirmed without delivering its intended assets. For a successful token call, also verify the correct token contract, recipient and actual transfer amount; success alone is not an exchange balance statement.
Before inclusion, an Ethereum nonce gap or competing replacement is a sender-side issue. The EVM transaction nonce guide explains how to resolve those attempts. Waiting for confirmations cannot resolve a transfer that has not entered the chain.
Then check deposit identity. Finality establishes settlement on the chain being inspected. It cannot make that chain an accepted deposit route or turn a wrong asset into the supported one. Use the wrong network versus wrong address guide when a valid-looking destination obscures a network mismatch.
Finally, read the venue's status definition. Kraken's deposit status documentation says Credited allows trading while withdrawals are not yet available; Successful allows both. On hold requires manual support review. Not every asset uses the intermediate Credited state. Those labels belong to Kraken and should not be assigned to another exchange's interface.
A receiving service may also have a processing incident. Treat an unmet confirmation condition and an account-side posting delay as different findings. Paying a higher fee on a new transfer does not change the venue's ledger entry for the original one.
Build one deposit evidence record
Use the following worksheet before deciding what to investigate next. Record observations with timestamps and keep unknown stages explicitly unknown.
| Question | Evidence to record | Next check if unresolved |
|---|---|---|
| Which deposit route? | Asset, native coin or contract, network, receiving address and any required memo | Compare with the destination's current instructions |
| Did this transfer execute? | Transaction hash, outcome, actual recipient and received amount | Reconcile the sender's attempts and on-chain result |
| Is inclusion still canonical? | Inclusion block hash and height; observation endpoint and time | Recheck after a changed or missing receipt |
| What settlement condition applies? | Depth convention or finalized ancestor evidence; policy date | Use that chain's rule and the venue's stated threshold |
| What can the account use? | Deposit ID, status, available trading balance and withdrawal availability | Inspect processing status or the venue's support path |
Keep the chain record and account record together. If the transaction is not included, investigate the sending attempt. If it is included but has not met the relevant settlement condition, observe that condition. If settlement evidence is complete while account credit is missing, provide the receiving venue with the network, transaction hash, destination, amount and timestamps.
The useful outcome is a precise statement of the first unmet check: an unsupported deposit route, an unsuccessful transfer, no canonical inclusion, settlement still pending, or settled funds awaiting account credit. That tells you which system needs attention and what evidence it needs.