Finality Policy

Overview

A Finality Policy connects blockchain settlement evidence to business action. The network defines how blocks become safer or final, while the merchant or payment provider decides what evidence is required before marking a payment acceptable for a particular workflow.

For Deterministic Finality, the policy can require an authenticated finalized checkpoint or certificate. For Probabilistic Finality, it can require a defined number of confirmations, conflict checks, and current fee or reorganization conditions. One threshold should not be copied across unrelated chains.

Risk factors include transaction value, asset type, customer action, delivery reversibility, bridge dependence, validator concentration, and current network health. A low-value digital service can accept earlier than a treasury withdrawal or physical shipment, provided the organization explicitly accepts the residual risk.

The policy should define behavior during Finality Delay, provider disagreement, reorganization, maintenance, or manual override. It should also distinguish detected, included, confirmed, finalized, credited, and fulfilled states so a single status label does not hide different responsibilities.

Implementation requires one authoritative configuration, monitored evidence, audit history, and regular review. Changes should be versioned and tested against historical incidents. OxaPay payment states can be mapped into an internal policy, but the merchant should not assume that provider status and internal order state have identical meaning.

Policy ownership should be explicit across product, finance, risk, and engineering teams. Engineering implements the evidence checks, but the accepted residual risk is a business decision. Periodic review should use real reorganization, outage, congestion, and delayed-finality incidents.

The approved policy version should be attached to every automated settlement decision.