Required Block Confirmations

Overview

Required Block Confirmations is the operational threshold used by a confirmation rule. OxaPay’s supported-currencies response includes a required-confirmations value for each asset and network combination.

The number is not comparable across chains. Block intervals, consensus, reorganization risk, validator finality, and provider architecture differ. Ten confirmations on one network do not equal ten on another.

The configured requirement can be higher than Minimum Block Confirmations and can change through dynamic risk policy. Large payments or degraded network conditions may justify stricter treatment.

Counting begins only after canonical inclusion. A pending transaction has zero block confirmations, and a reorganization can reduce the count or replace the containing block.

The payment record should store the required threshold and actual Confirmation Progress used for acceptance. This prevents later configuration changes from obscuring why the transaction was considered confirmed.

Provider thresholds can represent both network risk and internal processing policy. Merchants should not assume the number is a protocol constant. If an integration adds its own confirmations on top of the provider’s paid state, it should understand whether the provider has already applied the same threshold to avoid unnecessary duplicate waiting.

A provider response can change without a software release, so integrations should monitor configuration differences and alert before applying a new threshold to high-value traffic. Emergency changes should be reviewed after network conditions normalize.

Threshold updates should be logged with effective time and affected networks so payments created before and after the change can be evaluated consistently.

The threshold should be visible in support tools before any operator explains the payment status to a customer.