> ## 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.

# Consensus mechanisms

> How blockchains agree on a single history, and what each consensus family means for the data you read.

A blockchain has no central database. Thousands of independent nodes each hold a copy of the ledger, and **consensus** is the rule set they use to agree on which transactions happened and in what order.

The mechanism a chain picks determines three things you care about as a data consumer: how fast a block appears, how confident you can be that it will stay, and whether "the latest block" means the same thing to everyone.

## The main families

| Family                                   | How blocks get produced                                                                                         | Finality                                                                                                    | Examples                                         |
| :--------------------------------------- | :-------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------- | :----------------------------------------------- |
| **Proof of Work (PoW)**                  | Miners race to solve a hash puzzle; the winner proposes the next block                                          | Probabilistic — confidence grows with each block on top                                                     | Bitcoin, Litecoin, Dogecoin, Bitcoin Cash        |
| **Proof of Stake (PoS)**                 | Validators are selected to propose blocks in proportion to staked capital; misbehaviour is punished by slashing | Economic — an explicit checkpoint makes blocks irreversible                                                 | Ethereum, Solana, Cardano, Avalanche             |
| **BFT / instant finality**               | A known validator set votes on each block; a supermajority commits it before the next one starts                | Immediate — a committed block is final                                                                      | Cosmos chains (CometBFT), Aptos, Sui, XRP Ledger |
| **[Rollup](/guides/rollups) sequencing** | A single sequencer orders transactions offchain, then posts them to a settlement layer                          | Two-stage — soft confirmation from the sequencer, hard finality when the settlement layer accepts the batch | Arbitrum, Base, Optimism, zkSync, Starknet       |

<Info>
  [Rollups](/guides/rollups) are not a separate consensus mechanism so much as a separate trust assumption. A rollup inherits finality from the chain it settles to — usually Ethereum — which is why rollup blocks appear in under a second but take much longer to become truly irreversible.
</Info>

## Why this changes your data

**Block time sets your best-case latency.** A chain that produces a block every 400ms can deliver an event faster than one that produces a block every 10 minutes. No pipeline improves on the chain's own cadence.

**Finality style sets your confirmation cost.** On a BFT chain, a committed block will never be discarded, so Allium can serve it immediately. On a PoW chain, the most recent blocks are genuinely uncertain, so serving them immediately means occasionally serving data that gets undone. See [Transaction finality](/guides/finality).

**Fork frequency sets your correction rate.** Chains with fast blocks and probabilistic finality fork often — usually by a single block, resolved within seconds. Each fork is a set of transactions that briefly existed and then did not. See [Reorgs](/guides/reorgs).

**Block structure differs by family.** A PoW chain like Bitcoin has blocks of UTXO-based transactions with no smart-contract execution trace. Ethereum has blocks, transactions, logs, and traces. Solana has slots, and not every slot produces a block. Cosmos chains emit typed events rather than EVM logs. This is why Allium's per-chain schemas are not identical — see the [Data Catalog](/historical-data/overview).

## Two mechanisms worth knowing in detail

<AccordionGroup>
  <Accordion title="Ethereum: proposal and finalization are separate" icon="ethereum">
    Ethereum validators propose one block per slot, and slots are grouped into epochs of 32. Validators vote on epoch boundaries, and once two consecutive epochs have been justified by a supermajority of stake, the earlier one is **finalized** — reverting it would require an attacker to burn a large fraction of all staked ETH.

    So an Ethereum block passes through three states: proposed (visible immediately, revertible), justified, and finalized (roughly 13 minutes later). Most applications do not wait for finalization; they wait for a fixed number of confirmations, which is what Allium does by default.
  </Accordion>

  <Accordion title="Solana: commitment levels, not confirmations" icon="s">
    Solana does not express confidence as a block count. It exposes three **commitment levels** on its RPC interface:

    * `processed` — the node has seen the block; it may not be voted on
    * `confirmed` — a supermajority of the cluster has voted for the block
    * `finalized` — the block is rooted and will not be rolled back

    Allium ingests Solana at the `confirmed` commitment level, which is the standard choice for near-realtime data: it excludes unvoted forks while avoiding the extra delay of waiting for a root.
  </Accordion>
</AccordionGroup>

## Next steps

* [Rollups and L2s](/guides/rollups) — the trust model behind every L2
* [Transaction finality](/guides/finality) — how long Allium waits per chain
* [Reorgs](/guides/reorgs) — what happens when consensus discards a block