What "confirmed" actually means for stablecoin payments: a chain finality field guide

"Confirmed" is the most overloaded word in a crypto billing system. Customers see it on a receipt and assume the money is theirs. Merchants see it on a dashboard and assume the subscription is paid. Engineers see it in a webhook payload and assume they can provision access. All three are making the same implicit bet: that the transaction won't disappear from the canonical chain later. That bet is correct most of the time. The interesting work is the rest of the time.

This post is the field guide for what confirmed means on each of the four EVM networks where OpenSettle settles — Base, Ethereum, Polygon, and Arbitrum — and how to pick the right wait for your risk tolerance. We don't quote a single global number because the right answer is chain-dependent and amount-dependent. We quote the mechanics.

The two finalities

Every chain has at least two answers to "is this transaction final":

• Soft / probabilistic finality: the transaction is in a block and the chain is building on top of it. With each new block on top, the probability of a re-org that excludes it drops. On most chains under normal conditions, soft finality after a handful of blocks is "fine for the coffee shop" but not "fine for a five-figure invoice."
• Economic / cryptoeconomic finality: after some chain-specific event, reverting the transaction would require an attacker to forfeit a large staked asset or successfully fork the L1. This is the "the transaction will not disappear" guarantee that lawyers like.

Which one your billing system waits for depends on what you're settling. The threshold should be a function of amount, not a constant.

Base

Base is an OP-Stack rollup that posts state roots to Ethereum mainnet. From the customer's perspective, blocks are produced every two seconds and a deposit feels effectively instant. From a settlement perspective, there are two clocks: sequencer-confirmed (the Base sequencer included the transaction in a block) and L1-finalized (the corresponding state root is included in an Ethereum block that itself reaches PoS finality).

For most subscription amounts, sequencer-confirmation on Base is the right wait. For very large one-off invoices, waiting for L1 finality is the prudent choice. OpenSettle emits payment.confirmed at the sequencer-confirmation depth; for the rare deposit where you want L1 finality before you act, hold your own additional wait on top of it.

Ethereum

Ethereum's PoS consensus gives a deterministic finality. A block is finalized when an epoch boundary is crossed and at least two-thirds of validators have voted to finalize it. In normal operation that's roughly two epochs after inclusion, around 13 minutes. After finalization, reverting requires either a successful attack on the consensus layer or a coordinated minority slash that's economically irrational for the attacker.

The practical upshot: Ethereum is the slowest of the four chains to reach the strict finality bar, but when it gets there the bar is the highest in the entire EVM ecosystem. For high-value invoices where the merchant wants to be done thinking about a payment, waiting for finalization is cheap insurance.

Polygon

Polygon PoS has its own validator set and produces blocks quickly. Finality is probabilistic: the chance of a re-org drops as additional blocks accumulate on top of the deposit. Polygon also commits to Ethereum mainnet at intervals — a checkpointed Polygon block is effectively final once the checkpoint hits Ethereum.

We treat Polygon settlement with a deeper confirmation depth than Base for the same dollar amount. The marginal wait is small (still in seconds, chain-dependent), and Polygon's re-org probability profile is different enough from an L2-sequencer model that the conservative default is worth the extra wait.

Arbitrum

Arbitrum One is a Nitro rollup with a sequencer model similar in spirit to Base. The sequencer orders transactions and posts batched calldata to Ethereum. Transactions are effectively confirmed once the sequencer includes them; L1-finalization happens when the corresponding batch is included on Ethereum and reaches PoS finality there.

Like Base, the right wait for Arbitrum depends on the deposit. Sequencer-confirmation is fine for routine subscription cycles. L1-finality is the right wait for the kind of payment that would prompt a CFO call if it reversed.

How OpenSettle picks the wait

OpenSettle emits payment.confirmed once a deposit reaches the confirmation depth we treat as safe for that chain's risk profile — deeper on probabilistic chains, shallower on fast-finality L2s. We don't emit a separate finality event. Instead, if a deeper reorg ever displaces a confirmed deposit, you get payment.reorg_suspected and then payment.reorged (covered below) as the authoritative rollback signal. For a very high-value deposit where you want to wait for cryptoeconomic finality before you act, hold your own additional wait on top of payment.confirmed — the confirming block number is in the payload.

How long to wait before you act on a payment is your call, and it should be a function of the amount. Provision instantly under a threshold; hold an extra wait above it. OpenSettle gives you the inputs — the payment.confirmed event with its block number, plus payment.reorg_suspected and payment.reorged if the chain disagrees later — so the policy lives in your code, tuned to your product, not buried in ours.

Reorgs are real and rare

A re-org is when the chain head briefly extends on one fork and then switches to another. For payments, a re-org of the right depth can roll back a deposit. We treat this as a state transition, not an error: payments move into reorg_suspected when the chain reader detects head divergence at the relevant depth, and into reorged if the deposit is no longer on the canonical chain after a verification window. Merchants get explicit webhooks for both. We cover the implementation in detail in the post on reorg-safe payment confirmation.

The honest summary on settlement timing: stablecoin payments confirm in seconds (chain-dependent), but "confirmed" is not "final." Build your product so the gap is something you handle on purpose, not something you discover at 3am when a high-value deposit unwinds.