Based Rollups, Preconfirmations, and the Catalyst Sidecar

I've been studying to contribute to Nethermind's Catalyst project for Taiko. Here's everything I learned about based rollups, preconfirmations, and why this matters for Ethereum's future.

The Problem with L2 Sequencing

Let's start with the problem.

Most L2s today use a centralized sequencer. Basically one entity decides which transactions go into blocks and in what order. Arbitrum has their sequencer. Optimism has theirs. Base has theirs. Fast? Yes. Decentralized? About that...

The centralized sequencer model has real problems:

Single point of failure: If the sequencer goes down, the L2 halts. We've seen this happen. Users can't do anything until it comes back online.

Censorship risk: The sequencer can choose to exclude certain transactions. Maybe they're legally compelled to. Maybe they just don't like you. Either way, you're trusting them not to.

MEV extraction: The sequencer sees all transactions before ordering them. They can extract MEV for themselves. They can front-run. They can sandwich. And users have no recourse.

Trust assumptions: When you use a centralized L2, you're trusting the sequencer to be honest, available, and fair. That's a lot of trust for a supposedly trustless system.

The L2s will tell you they plan to decentralize eventually. And maybe they will. But "decentralize later" has been the plan for years now. Meanwhile, users are trusting single entities with billions in transaction volume.

Enter Based Rollups

This is where Taiko comes in.

Taiko is the first "based rollup" on Ethereum. Instead of trusting a single sequencer, Taiko hands over transaction ordering to Ethereum's own validators. No new trust assumptions. Just Ethereum.

So what does "based" actually mean?

Based rollups use Ethereum L1 for sequencing. Traditionally, L2s have their own sequencer which posts data to Ethereum, but in based rollups, Ethereum validators sequence user transactions directly. It's the most "Ethereum-native" way to build an L2.

The security model is elegant. You're not trusting some new entity. You're trusting Ethereum validators, the same validators you already trust to secure your L1 transactions. If you think Ethereum is secure, you automatically think based rollups are secure.

This also means MEV flows back to Ethereum validators instead of being captured by a centralized sequencer. That's good for Ethereum's economic security. Validators earn more, making staking more attractive, making the network more secure.

And censorship resistance comes for free. If Ethereum validators sequence your L2 transactions, you get the same censorship resistance guarantees as L1. No single entity can exclude your transaction.

The Latency Problem

But here's the catch.

Ethereum takes ~12 seconds to produce a block. If a based rollup relies on Ethereum validators for sequencing, it inherits that 12-second block time too.

Meanwhile, centralized L2s can give you sub-second confirmations. Arbitrum feels instant. Optimism feels instant. Users submit a transaction and immediately see the result.

This is a real UX problem. If you're building a trading interface, 12 seconds is forever. If you're building a game, 12 seconds is unplayable. Users have gotten used to fast confirmations. They're not going to accept going back to waiting.

So how do you get speed without sacrificing decentralization?

Preconfirmations: The Best of Both Worlds

The answer is preconfirmations (preconfs).

Preconfs give you a promise for your transaction before the block is even created. You get a cryptographic guarantee that your transaction will eventually be included in the L1 block. The promise comes in milliseconds. The actual inclusion happens later.

Here's how preconfs work:

1. User submits a transaction: Just like normal. You sign it, broadcast it.

2. A preconfer sees it: The preconfer is a validator (or delegate) who's going to propose the next block. They see your transaction in the mempool.

3. Preconfer issues a commitment: They sign a message saying "I promise to include this transaction in my block." This is the preconfirmation.

4. User gets instant feedback: The user sees the preconf in ~2 seconds. They know their transaction will go through.

5. Block gets proposed: When the preconfer's slot comes, they include the transaction as promised.

6. If they break the promise?: They get slashed. There's collateral at stake. Breaking a preconf means losing money.

The key insight is separating confirmation from inclusion. You don't need to wait for the block to know your transaction will be included. You just need a credible promise. And the promise is credible because breaking it costs money.

From the user's perspective, the UX is identical to a centralized L2. Submit transaction, get confirmation in 2 seconds. Under the hood, the decentralization guarantees are preserved.

Sidecars: Running Extra Software

Now, where does the "sidecar" come in?

Validators already run software to propose blocks. They run an execution client (like Geth or Nethermind) and a consensus client (like Lighthouse or Prysm). That's the standard Ethereum node setup.

A sidecar is extra software they run alongside their existing node. It's called a sidecar because it rides alongside the main software, like a motorcycle sidecar.

For preconfirmations, the sidecar handles the preconf duties:

• Watching for incoming transactions
• Deciding whether to preconfirm them
• Issuing signed commitments
• Making sure the commitments get honored when the block is proposed

Validators opt-in to running the sidecar. Not every validator needs to do preconfs. But those who do can earn extra fees for the service.

Catalyst: Nethermind's Preconfer Sidecar

This is where Catalyst comes in, the project I'm contributing to at Nethermind.

Catalyst is the preconfer sidecar for Taiko Alethia. It handles:

• Validator registration: Getting the validator registered in the preconf registry so they can participate
• Lookahead monitoring: Checking which validator's turn it is to preconfirm
• L2 block building: Constructing L2 blocks from the Taiko mempool
• P2P publishing: Broadcasting preconfirmed blocks to the preconf P2P network
• State syncing: Keeping local state up to date with the latest preconfirmed blocks
• L1 posting: Posting L2 blocks to Ethereum when the time comes

Let me break down what Catalyst actually does under the hood.

The Lookahead

Catalyst monitors the "lookahead" to know which validator preconfirms next. The lookahead is a schedule that tells you which validators are proposing upcoming slots. If your validator is in the lookahead, you know you'll be preconfirming soon.

This is important because preconfirmations require knowing who's going to propose. If you preconfirm a transaction but then a different validator proposes, your preconf is meaningless. The lookahead solves this coordination problem.

Block Construction

When it's your turn to preconfirm, Catalyst constructs L2 blocks from the Taiko mempool. It pulls pending transactions, orders them, builds a valid L2 block, and issues preconfirmations for the included transactions.

The block construction logic has to be fast. Users are waiting for their preconfs. Every millisecond counts.

State Management

Catalyst syncs local state with the latest preconfirmed blocks. This is necessary to validate new transactions. If someone's trying to spend tokens they don't have, Catalyst needs to know about previous transactions that depleted their balance.

Keeping state in sync across a P2P network of preconfers is non-trivial. There are edge cases around competing preconfs, reorgs, and network partitions.

L1 Posting

Finally, Catalyst posts L2 blocks to Ethereum. The preconfirmed transactions actually get included on L1, making them final. This is when the promise becomes reality.

Why This Matters

Based rollups with preconfirmations represent a different vision for scaling Ethereum.

The centralized sequencer model says: "Let's build fast L2s now, decentralize later." It prioritizes speed over decentralization and asks users to trust the sequencer.

The based rollup model says: "Let's keep Ethereum's decentralization guarantees and solve the speed problem with cryptoeconomics." It prioritizes decentralization and uses preconfs to match centralized L2 speed.

There are tradeoffs either way. Centralized L2s are simpler to build and can be even faster than preconfs (sub-100ms). Based rollups require validators to run extra software and have more complex coordination.

But if you believe in Ethereum's values, credible neutrality, censorship resistance, decentralization, then based rollups are the path that preserves those values while still giving users the speed they expect.

Quick Glossary

A few terms from this post:

1. Based Rollup: L2 using Ethereum validators for sequencing instead of a centralized sequencer
2. Preconfirmation: A signed promise that your transaction will be included, issued before the block is created
3. Sidecar: Extra software validators run alongside their node to handle additional duties
4. Catalyst: Nethermind's preconfer sidecar for Taiko Alethia
5. Lookahead: The schedule of upcoming block proposers, used to coordinate preconfirmations

This is what I've been studying and working on. Based rollups are still early, but the research is solid and the first implementations are live. Taiko launched the first based preconf on mainnet in August 2025. The future is getting built.