Time to Finality

Overview

Time to Finality measures how long an operation waits before the system considers reversal no longer acceptable under its trust model. The metric must state its start event and finality condition. Broadcast-to-finality, inclusion-to-finality, and application-detection time are different measurements.

On deterministic-finality protocols, the endpoint can be a quorum certificate, finalized checkpoint, or masterchain commitment. On probabilistic systems, the endpoint is normally a policy threshold based on confirmation depth and risk. The result therefore depends on both protocol behavior and the chosen Finality Policy.

Block time is not the same metric. A chain can produce blocks quickly but require several voting rounds or checkpoints for finality. Conversely, a BFT chain can finalize each block as part of commitment, making finality closely follow block production when the network is healthy.

Observed time also includes data delivery. Node synchronization, indexer lag, API polling intervals, and webhook processing can make an application recognize finality after the protocol achieved it. Teams should measure protocol time separately from Finality Detection latency.

Payment design uses time to finality to set checkout messaging, inventory holds, withdrawal availability, and service-level expectations. Average values are insufficient because Finality Delay can create long tails. Dashboards should include percentiles, failure periods, and the exact networks and transaction classes measured.

For customer-facing estimates, the system should avoid promising one exact duration when the network provides a distribution. A more accurate message states the expected range, current status, and whether the transaction is merely included, sufficiently confirmed, or finalized under the provider’s policy.

The measurement window should also exclude unrelated application processing when protocol comparison is the goal.