Inclusion comes first
A broadcast transaction is initially pending. A validator or miner must include it in a block before it becomes part of the network history.
Each later block adds confidence
A confirmation commonly refers to the transaction block and the blocks built after it. Because block production and finality differ by network, confirmation counts should not be compared as if they were identical.
Services set their own thresholds
Wallets, exchanges and payment services decide when to credit a deposit. Their threshold can depend on the network, asset, value and internal risk controls, so check the receiving service rather than relying on one universal number.
Record status precisely
When documenting a transfer, record the observed confirmation count, block number, timestamp and source explorer. Avoid describing a pending transaction as completed.
Finality is network-specific
Different networks reach confidence in different ways. Proof-of-work chains build confidence as blocks are added, while other systems may describe finalized checkpoints or commitment levels. A confirmation number from one network cannot be converted directly into the same level of confidence on another. Use the terminology and documentation of the actual network.
Why an exchange may still wait
A receiving service can require more time after the explorer shows success. It may wait for additional blocks, screen the deposit, validate a memo or token contract, or process credits in batches. The blockchain status and the service’s account status are separate facts. Record both rather than describing the transfer simply as missing.
How to document changing status
When a transaction is pending, record the observation time and explorer used. If the status changes, preserve the earlier observation and add a new entry instead of overwriting it. Include the block number, confirmation count and service status. This produces a timeline that another person can review without guessing what was visible at each stage.