Skip to main content
A transaction is final when it can no longer be reversed or reordered. Getting a transaction included in a block is not the same as it being final: on most chains the newest blocks can still be discarded, and every transaction inside them goes with them. That gap matters whenever you act on onchain data. Crediting a customer account, releasing goods, or closing the books all require a decision about how much confirmation is enough.

​
Two kinds of finality

Probabilistic finality applies to Proof of Work and most Proof of Stake chains. Nothing declares a block final; instead each subsequent block makes reversal exponentially more expensive. You choose a confirmation depth — the number of blocks you wait on top of the one you care about — and that choice is a risk/latency trade-off, not a protocol rule. Deterministic finality applies to BFT chains such as Cosmos chains, Aptos, Sui, and XRP Ledger. A supermajority of validators votes to commit each block before the next one is produced, so a committed block is final immediately and waiting adds nothing but latency.
Rollups have both. A rollup sequencer gives you a soft confirmation in well under a second, but the transaction is only as final as the settlement layer that has accepted its batch. An optimistic rollup like Arbitrum, Base, or Optimism carries a multi-day challenge window before its state is settled on Ethereum; a ZK rollup like zkSync, Scroll, or Starknet settles once its validity proof is verified. For reading rollup activity this rarely matters — for L1 withdrawal accounting it does.

​
How Allium applies finality

Allium ingests every chain twice, at two different points on the latency/certainty curve. The Realtime APIs use both. They serve from the tip, which is what gives them a p50 freshness of 3-5 seconds, and the confirmed pass reconciles behind them — so any record the chain later reorged is corrected rather than left standing. You get tip-of-chain latency without permanently keeping reorged data. Confirmation depth is tuned per chain from that chain’s own reorg behaviour, and is deliberately conservative on chains where forks are common. Realtime reorg detection runs regardless of mode — see Reorgs.

​
Confirmation depth by chain

The number of blocks Allium waits before treating a block as confirmed, and roughly how long that takes. The wait is the confirmation depth multiplied by the chain’s own block cadence, measured over the last seven days of Allium’s block data — so it moves with the chain and is an average, not a bound.
These are current operating defaults, not contractual guarantees. We retune them as chains change their consensus parameters or their observed reorg depth. If you are building a settlement process against a specific number, confirm it with [email protected] first.

​
EVM chains

​
Non-EVM chains

A high confirmation count does not mean a long wait. Arbitrum produces blocks roughly every 250ms, so its 300 confirmations clear in about half the time as Ethereum’s 12. The depth means nothing without the chain’s block cadence next to it, which is what the wait column is for.

​
Choosing a depth for your own use case

​
Next steps