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

# Rollups and L2s

> What a rollup is, how sequencers and settlement work, and why an L2's data has quirks an L1's does not.

A **layer 1** (L1) is a blockchain that secures itself — Ethereum, Bitcoin, Solana. A **layer 2** (L2) is a chain that borrows security from an L1 instead of establishing its own.

**Rollups** are the dominant kind of L2. Arbitrum, Base, Optimism, zkSync, Scroll, Linea, and Starknet are all rollups settling to Ethereum. They exist because L1 blockspace is scarce and therefore expensive: Ethereum processes on the order of a dozen transactions per second, and when demand exceeds that, fees rise until enough users are priced out.

## How a rollup works

A rollup runs its own execution environment and does the expensive part — executing transactions — off the L1. It then posts the results back to the L1, so the L1 becomes the record of what the rollup did.

<Steps>
  <Step title="You send a transaction to the sequencer">
    Not to the L1. The **sequencer** is the rollup component that receives transactions and decides their order.
  </Step>

  <Step title="The sequencer orders and executes it">
    It returns a receipt within milliseconds. This is a **soft confirmation** — real, and backed only by the sequencer's promise not to reorder.
  </Step>

  <Step title="Transactions are batched and posted to the L1">
    Compressed transaction data goes onto Ethereum, typically as a blob. This is what makes the rollup's history verifiable and reconstructable by anyone.
  </Step>

  <Step title="The L1 accepts the new state">
    Either after a challenge period elapses with no successful fraud proof, or immediately once a validity proof verifies. At this point the rollup's state is settled on the L1.
  </Step>
</Steps>

The compression is where the cost saving comes from. Thousands of rollup transactions are posted to the L1 as one batch, so each user pays a fraction of one L1 transaction's data cost rather than a whole L1 transaction.

## Optimistic vs ZK

The two families differ only in step 4 — how the L1 becomes convinced the rollup computed correctly.

|                      | Optimistic rollup                                             | ZK rollup                                            |
| :------------------- | :------------------------------------------------------------ | :--------------------------------------------------- |
| **Assumption**       | State transitions are valid unless proven otherwise           | Nothing is accepted without a proof                  |
| **Enforcement**      | Anyone may submit a **fraud proof** during a challenge window | A **validity proof** is verified by an L1 contract   |
| **Challenge window** | Typically 7 days                                              | None                                                 |
| **L1 settlement**    | After the window closes                                       | When the proof is verified                           |
| **Trade-off**        | Cheap and simple; slow to settle                              | Fast to settle; proving is computationally expensive |
| **Examples**         | Arbitrum, Base, Optimism, Blast, Ink, Soneium, Worldchain     | zkSync, Scroll, Linea, Starknet                      |

<Info>
  The challenge window is why withdrawing from an optimistic rollup to Ethereum through the canonical bridge takes about a week, while a swap on that same rollup confirms instantly. Two different questions: has the sequencer accepted my transaction, and has Ethereum accepted the rollup's state.
</Info>

## What a rollup is not

**A sidechain is not a rollup.** A sidechain has its own validator set and its own consensus, and posts nothing to an L1 for security. It is an independent chain with a bridge attached. If its validators collude, no L1 can save it. Polygon PoS and Ronin work this way.

**A chain that posts data elsewhere is not a full rollup.** Rollups get their guarantees from posting data to the L1 so anyone can reconstruct and challenge their state. A chain that proves to Ethereum but stores its data with a separate committee or an alternative data-availability layer has a weaker guarantee, and is usually called a validium or an optimium rather than a rollup.

**An appchain is a design choice, not a layer.** Chains built for one application — perp venues in particular — may be an L1, an L2, or neither. See [AMMs vs CLOBs](/guides/amms-vs-clobs) for why order books tend to want their own chain.

## The sequencer is the thing to understand

Almost every production rollup today runs a **single sequencer** operated by the rollup team. It has real consequences:

* **It can go down.** If the sequencer stops, the chain stops producing blocks. Rollups provide an escape hatch to force transactions through the L1 directly, but it is slow and rarely used.
* **It orders transactions.** The sequencer chooses the ordering that would otherwise be auctioned, so [MEV](/guides/mev) on a rollup looks different from MEV on Ethereum — usually less extractive, because there is no public mempool to front-run, and more concentrated.
* **It is a trust assumption.** Between soft confirmation and L1 posting, the sequencer could in principle reorder or drop your transaction. It cannot forge state — the proof or challenge system prevents that — but the ordering is its to choose.
* **A reorg means something different here.** Rollup blocks do not compete the way L1 blocks do, so ordinary [reorgs](/guides/reorgs) are rare. What can happen is the sequencer revising unposted blocks, or an L1 reorg dropping a batch that had already been posted.

## What this changes in the data

<AccordionGroup>
  <Accordion title="An address is not unique to a chain" icon="fingerprint">
    The same EVM address exists on every EVM chain, controlled by the same key, holding entirely different assets on each. Any query, join, or balance lookup must key on `(chain, address)` — never on the address alone. This applies to contracts too: a token deployed at the same address on two chains is two different tokens.
  </Accordion>

  <Accordion title="Bridged and native tokens share a name" icon="clone">
    A token on an L2 may be issued natively on that chain or bridged from Ethereum, and both will be called USDC. They are different contracts with different addresses and separate supplies, and they are not interchangeable without a swap. Summing "USDC on Base" without checking which contract you have double-counts. Check the address, not the symbol — [Tokens](/historical-data/tokens/profile-beta) resolves this.
  </Accordion>

  <Accordion title="Fees have two components" icon="gas-pump">
    An L2 transaction pays for its own execution and for its share of posting data to the L1. The L1 component moves with Ethereum's blob market, so L2 fees can rise sharply for reasons that have nothing to do with activity on the L2 itself.
  </Accordion>

  <Accordion title="Activity is fragmented by design" icon="arrows-split-up-and-left">
    One user's assets and history are spread across an L1 and several L2s. Per-chain metrics will undercount them, and unioning per-chain tables without deduplicating an entity across chains will overcount. Allium's `crosschain.*` tables and [Wallet 360](/historical-data/wallet-360) exist for exactly this problem.
  </Accordion>

  <Accordion title="Cross-chain flows need bridge data" icon="bridge">
    A deposit on one chain and a withdrawal on another are two unrelated transactions on two chains unless something matches them. [Bridges](/historical-data/bridges) does that matching, including [matched transfers](/historical-data/bridges/crosschain/matched-transfers) across protocols.
  </Accordion>
</AccordionGroup>

## Where to look in Allium

Allium treats every rollup as a first-class chain: an L2 gets the same raw, DEX, NFT, and balance schemas as an L1, so a query written against Ethereum works against Base with the database name changed. Coverage is listed per chain in the [Data Catalog](/historical-data/overview), and confirmation depths per rollup are in [Transaction finality](/guides/finality).

## Next steps

* [Transaction finality](/guides/finality) — soft confirmation vs L1 settlement, per chain
* [Consensus mechanisms](/guides/consensus) — what rollups borrow from, and what they replace