Confirmation Rule

Overview

A Confirmation Rule translates blockchain evidence into a state-transition condition. For a proof-of-work asset, the rule can require a defined number of blocks after inclusion. For a deterministic-finality network, it can require authenticated finalized status.

The rule must be network-specific. One confirmation on Bitcoin, Ethereum, TON, or Solana does not represent the same security model or elapsed time. Provider configuration can expose Required Block Confirmations for each supported network.

Confirmation is only one validation layer. The transaction must also pay the correct asset, amount, destination, and reference and must have succeeded under the chain’s execution model.

A rule should define behavior for replacement, reorganization, provider disagreement, and Maximum Confirmation Wait. Without exception states, a delayed transaction can remain stuck indefinitely or be accepted inconsistently.

The active rule and evidence should be stored with the payment. Changing policy later should not make historical acceptance decisions impossible to reconstruct.

Rules should be expressed as machine-readable configuration with test cases, not only prose. A rule can include minimum depth, finalized state, successful execution, conflict absence, maximum wait, and amount tier. Simulations using reorganized blocks, delayed providers, and duplicate callbacks help prove that the implementation follows the documented policy.

Configuration changes should pass staged deployment and shadow evaluation against live transactions before they control fulfillment. Comparing the old and new decisions reveals whether a threshold change unexpectedly delays or accelerates payments.

The rule engine should expose a human-readable explanation for each decision so support and finance teams can understand why a transaction advanced or remained pending.