Crypto Confirmation Policy: Why the Wait Varies

A crypto confirmation policy decides when a payment is ready to credit. Paymos reads two inputs: the network the payer chose and the invoice's dollar value. Every network carries its own confirmation depth for each amount band, so a small invoice clears shallower than a large one on the same chain. Those depths are configuration rather than an estimate, which is why this post can print them. What they are not is a clock — the minutes behind a count belong to the chain's block production, and an integration should release goods on the confirmed invoice state rather than on a timer.

What does a confirmation policy decide?

A confirmation policy turns a raw chain event into a payment outcome. On most networks that means counting blocks built on top of the block holding the payment. On a network that issues an explicit finality signal, the policy reads the signal instead. The merchant sees one thing either way — the invoice state — and never has to run the evaluation itself.

The policy exists because a recent chain observation is not a settled payment. A reorg — a chain reorganization — can replace recent blocks, so a wallet showing one confirmation has proved inclusion, not permanence. Depth buys probability. A protocol finality signal buys a stronger guarantee under that protocol's own rules. The integration boundary sits at the confirmed invoice state, not at a block explorer a support agent happens to be reading.

Why does the safe wait depend on the amount?

The amount is the value exposed if a recent block is displaced. Security is a property of the network; the size of the loss is a property of the invoice. A policy that ignores the second one has to pick a single wait for both, and neither answer is right: deep enough for a five-figure transfer makes a $20 order crawl, quick enough for the $20 order underprices the five-figure one.

Banding the invoice's dollar value resolves that. The thresholds are $100, $1,000, and $10,000, and a tier applies up to and including its own threshold. The counts inside those bands differ per network, and some networks use fewer bands than others, because a block does not mean the same thing on every chain.

What does a tiered confirmation policy look like in practice?

Here is the whole rule for the networks where the bands do most of the work. An Ethereum invoice waits 2 confirmations at or below $100, 6 through $1,000, 12 through $10,000, then 32. Tron opens at 2, moves to 6, and caps at 19 above $1,000 — the point at which 19 of its 27 super representatives have solidified the block. Base and Optimism run 5 / 15 / 30 / 100 across the same thresholds. Arbitrum runs 40 / 120 / 240 / 800, which reads as extreme until you account for sub-second blocks: its four horizons land where Base's do.

Several chains need no bands. BSC and Polygon settle on their own finality signal. Solana is scanned at the finalized commitment and confirmed on discovery. TON asks for one block, because every masterchain block there arrives final.

Quoting one of those numbers alone is how the rule gets misstated. "Finality at 19 confirmations on Tron" is accurate above $1,000 and wrong beneath it. Carry the band with the count, or give the whole row. The confirmation guide covers why the same raw count does not represent equal safety on every network.

How long does a tier take in wall-clock terms?

A count becomes a duration only through the network's current block rate. Ethereum's shallow tier runs about 24 seconds at a normal cadence and its deepest a little over six minutes; Tron's shallowest sits near six seconds. Read every one of those as an approximation.

Blocks arrive more slowly when a network is congested, and the arithmetic drifts with them. That is the line between the two halves of this policy: the count is a setting, the time is a forecast. A checkout label, a support macro, or a contract clause that turns the forecast into a promise will be wrong on the first busy afternoon.

How does protocol finality affect confirmation policy?

A proof-of-stake network can issue finality rather than imply it. Ethereum organizes that through Casper FFG checkpoints, which settle history in epochs instead of one block at a time. Paymos still counts blocks on Ethereum — 2 through 32, depending on the band — so the amount stays part of the decision.

Where a chain's finality arrives fast and unconditional, the bands disappear entirely — which is why the four networks listed above run a single tier. Consensus answers there, directly, what a depth count can only make probable. Different models, one merchant-facing outcome: the invoice state.

Why must policy follow current network behavior?

Networks change how fast and how firmly they produce blocks. BSC's Fermi upgrade cut block times, and Polygon's Heimdall v2 shortened its path to finality. Each of those moves the wall-clock meaning of a count without touching the count.

That is the argument against freezing a number in merchant code. When a chain shifts, the depth configuration is ours to adjust; a constant in a merchant repository changes when somebody remembers to open a pull request. The tiers above are a snapshot of settings Paymos maintains, not a clause in an agreement.

When is a hard-coded confirmation count the right call?

Rarely, and never as a stand-in for the invoice state. Reading the table to understand the wait is fair use of it. Building an if around 12 confirmations is not: the constant leaves out the network the payer chose, the band the invoice landed in, and the next change to either.

The integration's job is narrower and outlives all of that. Persist the Paymos invoice identifier, verify the signature on status updates, and make fulfilment idempotent. An order should not leave because a timer expired, because a wallet displayed a block, or because a previous payment on another chain cleared quickly. Those observations help a support agent; they do not replace the confirmed outcome for the invoice in front of them.

How does Paymos apply the policy?

Paymos evaluates the network and the amount together, then reports the result. Smaller payments clear at fewer confirmations, larger ones wait for a stronger threshold, and the elapsed time follows whatever the chain is doing at that moment. The counts move only when Paymos moves them — which is exactly what separates them from the network fee, a price the chain sets and no page here quotes as a fixed amount.

The supported chains page lists the available payment routes. The confirmations explainer covers what a block count proves and where a protocol's own finality is the stronger signal.