One-Confirmation Acceptance

Overview

What it means in plain English

One-confirmation acceptance is a policy that accepts a payment after its transaction appears in one accepted block and passes all payment-validity checks. It provides more assurance than zero-confirmation acceptance but can remain vulnerable to short reorganizations, conflicting branches, or protocol-specific execution issues. The policy is appropriate only when the network and business risk justify acting before deeper confirmation or finality.

How it works and why it matters

One-Confirmation Acceptance treats first canonical block inclusion as sufficient for a defined action. The system must verify the containing block, transaction success, asset, amount, destination, and reference before accepting.

The policy should not be described as universal finality. On probabilistic networks, a one-block transaction can still be removed by a reorganization.

One-confirmation acceptance can be reasonable for low-value, reversible, or low-risk services, while larger payments require Multi-Confirmation Acceptance or explicit finalized status.

The decision should consider current network health, detected conflicts, fee conditions, and whether the transaction is replaceable before inclusion. A static rule can become unsafe during unusual conditions.

The payment record should store that one-confirmation policy was applied. If the merchant later increases Required Block Confirmations, historical transactions should remain explainable under their original rule.

The policy should define the exact downstream action allowed at one confirmation. Provisional service access may be acceptable while withdrawal or irreversible shipment remains blocked. Splitting permissions by risk allows faster customer experience without pretending that first inclusion gives the same assurance as deeper confirmation or finalized consensus.

During known reorganization risk, node disagreement, or provider degradation, the policy should automatically escalate to a higher threshold. The decision engine should not continue one-confirmation treatment simply because it is the default.

Operational limits should cap both individual payment value and total exposure awaiting deeper confirmation. The policy should be suspended during chain instability or node disagreement.

The merchant should also define whether refunds, internal balance use, or external withdrawals remain restricted until deeper settlement. This layered control prevents an early accepted payment from becoming fully liquid before the residual chain risk has declined.

Worked example

A small order accepts a Bitcoin payment once the transaction appears in one valid block. That is a merchant risk policy, not a permanent finality promise. For an expensive or easily resold item, the same business may require more confirmations.

Practical checks and common confusion

One confirmation is stronger than zero but still subject to reorganization risk. The correct threshold depends on the chain, transaction value, chargeback-equivalent exposure and sensitivity to delay. Do not borrow Bitcoin's confirmation count directly for other networks.

Learn the related concepts

Invoice Repricing Manual Confirmation Acceptance