> ## Documentation Index
> Fetch the complete documentation index at: https://docs.allium.so/llms.txt
> Use this file to discover all available pages before exploring further.
# Transaction finality
> What it means for a transaction to be irreversible, and how many confirmations Allium waits before treating a block as settled on each chain.
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](/guides/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.
| Mode | What it does |
| :------------ | :------------------------------------------------------------------------------------------------------------------------- |
| **Latest** | Reads from the tip of the chain with no confirmation delay. Lowest latency, and may include blocks that are later reorged. |
| **Confirmed** | Waits a per-chain confirmation depth before publishing a block, so a reorged block never reaches it. |
The [Realtime APIs](/api/developer/overview) 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.
| Product | Which mode |
| :------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------- |
| [Realtime APIs](/api/developer/overview) | Latest, reconciled by the confirmed pass |
| [Datastreams](/datastreams/overview) and [Beam](/beam/overview) | Confirmed by default; latest when the source is configured for pre-finality data (`is_zerolag` on the Beam API) |
| [Datashares](/datashares/overview) and [Data Catalog](/historical-data/overview) | Confirmed, plus continuous reconciliation against the canonical chain |
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](/guides/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 [support@allium.so](mailto:support@allium.so) first.
### EVM chains
| Chain | Confirmations | Approximate wait |
| :-------------- | ------------: | ---------------: |
| Abstract | 100 | \~60s |
| Apechain | 50 | \~47s |
| Arbitrum | 300 | \~1.3 min |
| Avalanche | 2 | \~2s |
| Base | 15 | \~30s |
| Berachain | 100 | \~3.3 min |
| Blast | 10 | \~20s |
| BNB Smart Chain | 15 | \~7s |
| Celo | 2 | \~2s |
| Core | 100 | \~5 min |
| Ethereum | 12 | \~2.4 min |
| Gnosis | 300 | \~25 min |
| Ink | 100 | \~1.7 min |
| Linea | 900 | \~2.3 h |
| Mantle | 10 | \~20s |
| Monad | 2 | under 1s |
| Optimism | 120 | \~4 min |
| Plasma | 100 | \~1.7 min |
| Polygon | 50 | \~1.2 min |
| Ronin | 200 | \~6.7 min |
| Scroll | 50 | \~6 min |
| Sei | 2 | under 1s |
| Soneium | 100 | \~3.3 min |
| Sonic | 100 | \~2.8 min |
| Tron | 10 | \~30s |
| Unichain | 12 | \~12s |
| Worldchain | 100 | \~3.3 min |
| zkSync | 10 | \~1.1 min |
### Non-EVM chains
| Chain | Confirmations | Approximate wait | Notes |
| :------------- | ------------: | ---------------: | :------------------------------------------------------------------- |
| Aptos | 50 | \~2s | |
| Bitcoin | 0 | None | Ingested at the tip; reorged records are flagged and corrected |
| Bitcoin Cash | 10 | \~1.7 h | |
| Canton Network | 120 | \~2 min | One block per second |
| Cardano | 10 | \~3.4 min | |
| Celestia | 10 | \~28s | Deterministic finality; the depth is a safety margin against RPC lag |
| Cosmos | 10 | \~57s | Deterministic finality; the depth is a safety margin against RPC lag |
| Dogecoin | 10 | \~11 min | |
| dYdX | 10 | \~7s | Deterministic finality; the depth is a safety margin against RPC lag |
| Injective | 10 | \~6s | Deterministic finality; the depth is a safety margin against RPC lag |
| Litecoin | 10 | \~25 min | |
| Near | 4 | \~2s | |
| Osmosis | 10 | \~13s | Deterministic finality; the depth is a safety margin against RPC lag |
| Solana | 1 slot | under 1s | Ingested at `confirmed` commitment rather than a block count |
| Starknet | 10 | \~17s | |
| Stellar | 0 | None | Deterministic finality on commit |
| Sui | 0 | None | Deterministic finality on commit |
| TON | 10 | \~4s | Masterchain blocks |
| XRP Ledger | 10 | \~39s | |
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
| Use case | Recommendation |
| :----------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Dashboards, analytics, monitoring | Latest is fine. A reorged block moves a chart by a rounding error. |
| Balance and portfolio display | The Realtime APIs are built for this — served at the tip, corrected behind you if a block is reorged. |
| Crediting funds, releasing assets, payouts | Wait past the chain's confirmation depth above rather than acting on your first read, and add your own margin if your exposure per transaction is large. |
| Accounting, audit, reporting | Read from [Datashares](/datashares/overview) or the [Data Catalog](/historical-data/overview), which are built from settled data and reconciled by [data quality checks](/historical-data/overview/data-quality-verification). |
## Next steps
* [Reorgs](/guides/reorgs) — what Allium does when a confirmed assumption breaks
* [Consensus mechanisms](/guides/consensus) — why finality differs by chain
* [Rollups and L2s](/guides/rollups) — soft confirmation vs settlement on an L2
* [Data freshness](/historical-data/overview/data-freshness) — end-to-end latency for batch data