Confirmation Progress

Overview

Confirmation Progress shows how close a transaction is to satisfying the active confirmation rule. A common display is current confirmations divided by Required Block Confirmations.

The count usually increases as new canonical blocks build on the containing block. A reorganization can move the transaction to another block, reset part of the count, or remove it entirely.

Progress should not be derived from local height alone. The system must verify the containing block hash and canonical chain status using synchronized node or provider data.

For deterministic-finality networks, progress can use stages such as included, safe, or finalized rather than a simple block count. The user interface should reflect the actual protocol model.

Payment tracking should store progress updates as evidence while allowing duplicate events. Crossing the threshold can trigger a Payment State Transition, but asset, amount, and execution validation must already be complete.

Progress displays should avoid false precision. A counter such as 2 of 3 is meaningful on a block-depth policy, but a deterministic-finality protocol may not advance linearly. Interfaces can instead show observed, included, safe, and finalized stages. Internal APIs should expose the raw evidence so different products do not interpret one generic percentage differently.

Polling frequency should balance timely updates with provider limits. Event-driven callbacks can reduce delay, but periodic reconciliation is still required to recover progress updates lost during webhook outages or deployment failures.

Progress history is useful for diagnosing whether delays came from block production, provider indexing, webhook delivery, or internal state processing.

A progress reset caused by reorganization should generate a distinct event and customer message rather than silently lowering the visible count.