Multi-Confirmation Acceptance

Overview

Multi-Confirmation Acceptance waits for a defined block depth before moving the payment to an accepted state. It is common for Bitcoin-style networks where reversal risk decreases as additional blocks build on the transaction.

The policy uses a Confirmation Rule and tracks Confirmation Progress until the threshold is reached. Reorganizations can reduce progress, so the containing block must remain canonical.

The confirmation count should come from current network or provider configuration. Different assets can require different counts because block time, security, and provider risk differ.

Multi-confirmation acceptance can be tiered by amount. Small digital purchases may use fewer confirmations, while large irreversible deliveries use more. The risk model should be documented rather than hidden in code.

The approach differs from deterministic finality, where an explicit finalized state can be more meaningful than accumulating arbitrary block counts. Payment interfaces should communicate expected delay and current progress clearly.

Waiting for additional blocks does not repair a transaction that failed execution or paid the wrong destination. The policy should first establish semantic payment validity and then accumulate settlement evidence. This ordering prevents a deeply confirmed but incorrect transfer from being promoted automatically simply because its confirmation counter reached the threshold.

Merchants should measure abandonment and fulfillment latency alongside loss reduction. An overly conservative threshold can damage conversion or service delivery without providing meaningful additional security on a network with explicit finality.

The selected count should be periodically compared with current provider recommendations and observed chain behavior instead of remaining permanently fixed.

Confirmation thresholds should be reviewed after material changes in network security, block production, or provider policy.