Confirmation Threshold

Overview

Understand the idea

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.

What actually happens

A confirmation threshold is a merchant or platform rule specifying when a transfer has enough network assurance for a particular action. It might be expressed as a block depth, a finalized checkpoint or a provider-defined risk state. The threshold exists because a transaction can be broadcast, observed or included without being sufficiently settled for every commercial purpose.

Policy design starts with the specific chain and transaction type, then considers order value, fraud exposure, delivery reversibility and customer experience. A digital download may accept lower assurance than a costly irreversible shipment. The monitor checks required destination and value, observes finality, then transitions to the appropriate order state when the policy is met. If a reorganization removes the evidence, the state machine must permit review or reversal where business obligations still allow it.

Decisions and failure cases

Thresholds are not universal safety guarantees. Attack incentives, chain security, bridge mechanics and settlement dependencies can change. The threshold should be versioned and logged so an auditor can reconstruct why an order was released on a certain date.

Related concepts

Confirmation, Payment Paid, Threshold-Signed Transaction.

Further reading

Ethereum: Gas and Fees.