Confirmation Threshold

Overview

Thresholds make automated workflows predictable. A payment monitor counts confirmations or observes protocol finality and changes the invoice state when the configured condition is met. The system should retain the block hash and rule version that caused the transition.

Risk-based thresholds can vary by value, customer, asset, or delivered product. A merchant may use lower thresholds for refundable services and higher ones for irreversible fulfillment. Network incidents can justify temporary increases.

The implementation must handle reversals. If a reorganization reduces the confirmation count below the threshold, the payment should enter a review or re-evaluation state rather than silently remaining settled. Systems that immediately transfer or withdraw funds after crossing the threshold should understand the residual risk.

A threshold also differs from a target. The threshold is the minimum acceptance condition; the target is the expected time or fee objective for reaching it. Clear terminology improves monitoring, customer messaging, and incident analysis.

Threshold selection should be tested against expected loss, transaction value, and fulfillment reversibility. Using a very high threshold can create poor conversion and support volume, while a threshold that is too low increases reversal exposure. Businesses can use tiered rules rather than one number for every order. The system should also allow a manual hold when network conditions make the normal threshold unreliable.

Thresholds should be represented as configuration rather than hidden code constants. This allows controlled updates, audit history, and separate settings by network or asset. Validation prevents accidental values such as zero confirmations for high-risk workflows. This makes review easier.