Zero-Confirmation Acceptance

Overview

Zero-Confirmation Acceptance acts on an unconfirmed transaction observed by one or more nodes. The payment has been broadcast but has not yet gained canonical block inclusion.

The transaction can be replaced through mechanisms such as Replace-by-Fee (RBF), conflict with another spend, disappear from mempools, or remain unconfirmed because its fee is too low.

Risk controls can inspect input conflicts, fee rate, transaction structure, network propagation, customer history, amount, and delivery reversibility. These controls reduce risk but do not create blockchain finality.

Zero-confirmation acceptance is usually unsuitable for high-value goods, irreversible withdrawals, or networks with weak pending-transaction visibility. Low-value digital services can choose it under explicit loss limits.

The payment state should remain distinct from Confirmed Transaction and continue monitoring until inclusion or failure. If the transaction is replaced, the system must reverse or suspend any provisional credit according to policy.

Merchants should define a maximum aggregate exposure, not only a per-payment limit. Many small unconfirmed transactions can create significant total loss if an attacker targets the same policy repeatedly. Real-time monitoring should track provisional credits by payer, address, device, and conflicting inputs and automatically disable zero-confirmation acceptance during abnormal conditions.

A provisional order should carry a visible risk state across inventory, account balance, and support tools. If only the payment service knows the transaction is unconfirmed, another system may allow withdrawal or irreversible use before settlement.

Any provisional credit should be nonwithdrawable and clearly separated from settled balance until the transaction enters a canonical block and satisfies the later confirmation rule.