Skip to main content
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.
1

You send a transaction to the sequencer

Not to the L1. The sequencer is the rollup component that receives transactions and decides their order.
2

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

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

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

​
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 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 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 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

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.
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 resolves this.
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.
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 exist for exactly this problem.
A deposit on one chain and a withdrawal on another are two unrelated transactions on two chains unless something matches them. Bridges does that matching, including matched transfers across protocols.

​
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, and confirmation depths per rollup are in Transaction finality.

​
Next steps