Crypto Confirmation Policy

Overview

How it works

What matters in practice

A confirmation policy specifies which blockchain evidence is sufficient before a payment changes business state. It should identify asset, network, amount/value tier, contract validity, reorganization tolerance and when to escalate. Bitcoin confirmation depth is different from an Ethereum finalized checkpoint or a rollup sequencer acknowledgement, so a single 'three confirmations' rule does not fit all chains. Policy changes should be versioned and applied consistently to historical decisions. Emergency network incidents may require temporarily raising thresholds or pausing fulfillment, but staff must see why an order remains pending.

Build the rule as a decision table rather than a single integer setting. At minimum, specify supported chain, asset or contract, value band, observed inclusion state, finality signal, reorganization response and exception owner. A merchant might temporarily suspend acceptance after a material chain incident, but that change should not retroactively rewrite the evidence collected for older orders. Test the policy with mempool replacements, reorgs and invalid token transfers.

For an implementation test, simulate a deposit that appears in one block and disappears after a reorganization. Verify that the system reverses provisional confidence without issuing the product twice. Also test what happens when two RPC endpoints disagree on block height; the application should resolve the disagreement against its trusted finality rules rather than choose whichever endpoint replied first.

Related glossary concepts

Amount-Based Confirmation Threshold; Asset-Based Confirmation Threshold; Crypto Payment Confirmation