One-Confirmation Acceptance
Pronunciation: WUN kon-fur-MAY-shun ak-SEP-tuns
Also known as: Single-Confirmation Acceptance, First-Block Acceptance
Definition
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.
Overview
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.
Key Takeaway
One-confirmation acceptance acts after first block inclusion and should be limited to cases where residual reorganization risk is explicitly acceptable.
Sources
- Bitcoin Developer Guide: Block Chain — Bitcoin Developer Documentation (2026-08-02)
- OxaPay API Reference: Supported Currencies — OxaPay (2026-08-02)
- OxaPay API Reference: Payment Status Table — OxaPay (2026-08-02)