One-Confirmation Payment

Overview

Before inclusion, the transaction may be replaced, dropped, or conflict with another transaction. The first confirmation shows that a block producer included it and that validating nodes accepted the block initially.

In proof-of-work systems, one block can still be reorganized if a competing branch becomes stronger. Additional blocks reduce that probability. In proof-of-stake systems, the first included block may also be separate from a later finalized checkpoint.

A merchant can choose one-confirmation acceptance for low-value digital goods, reversible services, or trusted customers. High-value physical delivery, withdrawals, and easily resold goods usually justify stronger settlement evidence.

The payment monitor should verify transaction success, exact asset, recipient, amount, block hash, and canonical status. Token transfers require checking the correct contract event rather than only the outer transaction.

If a reorganization removes the block, the invoice should return to confirming or review. Systems that cannot reverse fulfillment should understand the residual loss exposure.

One-confirmation payment is a risk-policy choice designed for speed. It does not change the network’s consensus guarantees or make the transaction final by definition.

Merchants can reduce exposure by limiting order value, delaying withdrawals, and monitoring network health after fulfillment. If the business action is reversible, one confirmation may offer a reasonable user-experience trade-off. If fulfillment cannot be undone, deeper confirmation is usually safer. The decision should be based on expected loss and actual protocol behavior rather than a generic rule copied from another payment provider.

Policies should be reviewed after major reorganizations or consensus incidents. Residual risk must remain visible.