Original topic illustration: ChainView BTC866 original topic diagram · ChainView BTC866 Editorial · CC BY 4.0
What a confirmation represents
A confirmation describes inclusion in the currently accepted chain. Subsequent blocks usually increase the cost of replacing that history, but confirmation counts are not universal guarantees. Networks differ in consensus, block intervals, and security assumptions. Six confirmations on one network cannot simply be treated as equivalent assurance on another.
Why temporary forks happen
Propagation delays can expose nodes to competing valid tips. A reorganization changes the selected history, potentially returning a transaction to the mempool or replacing it with a conflict. Record old and new block hashes, common ancestors, and affected transactions. Explorer indexing delays should be ruled out before concluding that a genuine reorganization occurred.
Different kinds of finality
Proof of work typically adds assurance through accumulated work; proof-of-stake systems may use checkpoints and finality votes. Economic finality depends on penalties and participation assumptions, not flawless software. Distinguish head, justified, finalized, and application-complete statuses. An exchange interface may mark its own workflow complete without describing the consensus state.
Offline and degraded conditions
After downtime, nodes must resynchronize and verify state. Partitions, client faults, or low validator participation can delay inclusion or finality. Monitor peers, synchronization, and finality lag instead of extrapolating routine block times. Applications may need to suspend low-confirmation acceptance until the degraded conditions have been understood and resolved.
Why applications wait longer
Exchanges, bridges, and merchants can add confirmation thresholds based on value and risk. A finalized transfer may still await account review, a memo, or maintenance. Separate chain status from business crediting using the transaction hash. Before irreversible delivery, verify amount and conditions through trusted infrastructure rather than relying on a wallet notification alone.
Design a finality log
Log network, hash, first-seen time, inclusion height, block hash, finality state, and application credit time. Preserve both pre- and post-reorganization observations. Public historical examples or testnets are sufficient for learning. The purpose is to locate the layer causing a delay, not to suggest a magic confirmation number removes every risk.
Worked review example
Suppose a transaction enters block 100, then a branch change returns it to waiting. Keep the old block hash, replacement tip, and eventual inclusion height rather than only a final success screenshot. Separately record platform crediting. The illustrative timeline distinguishes reorganization from business processing, showing which stage created delay. It does not prescribe a universal acceptance threshold; that depends on consensus, value, recipient policy, and observed network conditions.
