Finality Delay

Overview

Finality Delay occurs when the finalization mechanism does not complete on schedule. In voting-based proof-of-stake systems, too little participating stake or conflicting network views can prevent the required supermajority from finalizing checkpoints even while blocks continue to be proposed.

The delay can be a liveness problem rather than a safety failure. The chain may avoid finalizing conflicting blocks but temporarily stop strengthening settlement guarantees. This distinction matters because operators should not treat newly produced blocks as equivalent to normally finalized history.

Local infrastructure can create an apparent delay. An unsynchronized consensus client, stale API, indexer backlog, or polling failure may report old finality while the protocol is healthy. Finality Detection should compare current network evidence and data-pipeline status before escalating a consensus incident.

Payment systems need predefined behavior during a delay. They may continue displaying pending transactions, pause high-value fulfillment, restrict withdrawals, or use a temporary higher-risk state. The business response belongs in the Finality Policy rather than being improvised during an outage.

Metrics should compare actual Time to Finality with expected network ranges and separate protocol, provider, and internal processing time. After recovery, systems should reconcile blocks and payments processed during the delay, document the cause, and verify that no stale state was treated as final.

Alerts should use duration and severity thresholds appropriate to the network. A few missed slots may be normal, while several epochs without finality can require operational restrictions. The incident record should capture validator participation, node health, provider status, and affected payment decisions.

Recovery criteria should be documented before restrictions are removed.