Finality Detection

Overview

Finality Detection converts protocol evidence into an operational decision. On a deterministic-finality network, software may verify a commit certificate or finalized checkpoint. On a proof-of-work network, it may measure confirmations and apply a risk threshold based on Probabilistic Finality.

The data source must be current and chain-specific. A node can expose a finalized block tag, a consensus client can report finalized checkpoints, or a TON payment processor can verify that a shardchain transaction was included in a finalized masterchain block. Reading only the latest observed block is not enough.

Detection should preserve the chain, block hash, height, evidence type, and observation time. If two providers disagree, the application should not silently select the most favorable answer. It should evaluate synchronization, source trust, and whether the providers are describing different stages of the same transaction.

Protocol finality and Payment State remain separate. A finalized transfer can still be the wrong asset, amount, or destination, while a merchant can choose to accept a payment before protocol finality under a defined risk limit. The finality detector supplies evidence to the business state machine rather than replacing it.

Monitoring should continue for unusual conditions such as Finality Delay, API lag, invalidated traces, or consensus incidents. A robust implementation records when finality was first detected and can re-evaluate the result if the source later reports a serious protocol exception. Routine duplicate notifications must remain idempotent.

Production systems should test detection against normal finalization, delayed finality, provider outages, and historical reorganizations. A detector should expose the evidence it used rather than return only a boolean value, allowing finance and support teams to review why a payment was released.