Minimum Block Confirmations

Overview

Minimum Block Confirmations establishes a lower boundary for confirmation-based acceptance. A policy can state that no payment is considered confirmed below this count, even if another rule would otherwise allow early fulfillment.

The minimum differs from Required Block Confirmations. Required confirmations are the exact threshold used for a specific asset or transaction, while the minimum is a floor that dynamic policy cannot go below.

The value should reflect network behavior. Proof-of-work chains use block depth as a risk proxy, while deterministic-finality networks may use finalized status rather than an arbitrary count.

A minimum can be combined with amount-based rules. Low-value payments may use the floor, while higher-value payments require more confirmations or manual review.

Configuration should be versioned and tested against reorganization and double-spend scenarios. User interfaces should not label a transaction final merely because it crossed the minimum if the business requires additional checks.

A configured floor should remain consistent with the merchant’s broader Finality Policy.

A minimum is particularly useful when other systems can request an override. Even if a risk engine recommends immediate credit, the floor can block that action for networks where unconfirmed transactions are unacceptable. Any authorized exception to the floor should be treated as a separate override with stronger approval and clear loss limits.

The floor should be exposed in operational documentation and monitoring so teams can detect any code path that credits below it. A hidden inconsistency between invoice, static-address, and payout services can create unequal risk.

Network incidents should be able to raise the effective threshold automatically without lowering the configured safety floor.