What Are Based Rollups and Why They Use Ethereum's Validators

What problem are based rollups actually trying to solve?

Most Ethereum layer-2 rollups today, including well-known networks built on the OP Stack and Arbitrum Orbit stacks, run their own sequencer. The sequencer is the machine that decides which user transactions go in the next block and in what order. For users, this is mostly invisible. You click "swap," the sequencer includes your transaction, and within a second or two you see a confirmation.

Behind that smooth experience sits a quiet trust assumption: you are trusting the sequencer operator to behave honestly. In practice, a centralized sequencer can reorder transactions to profit from price moves (a form of MEV, or "maximal extractable value"), censor specific addresses, or simply go offline. The rollup's own security story usually includes an "escape hatch" that lets users force transactions through L1 if the sequencer misbehaves, but that hatch is slow, expensive, and rarely used.

Based rollups, sometimes called L1-sequenced rollups, propose a different answer. Instead of running their own sequencer, they let Ethereum's existing block proposers include rollup transactions directly in L1 blocks. The same validators that secure Ethereum are also the ones ordering the rollup's activity. There is no separate sequencer to trust because there is no separate sequencer at all.

What does "L1-sequenced" actually mean in practice?

To understand the shift, it helps to picture a normal rollup. A user signs a transaction on the L2, sends it to the rollup's mempool, and the rollup's sequencer picks it up, orders it, executes it, and posts a batch of compressed data back to Ethereum for security. The ordering step is the sequencer's job, and that step is what determines whether you get a fair trade, a sandwich attack, or a failed transaction.

In a based rollup, the ordering step is given to Ethereum's L1 block proposers. Users still submit transactions to the rollup, but the rollup does not decide the order. Instead, the next Ethereum proposer who is building a block can include rollup transactions as part of their L1 block construction. The rollup inherits the ordering that L1 produces, which is exactly the ordering that secures Ethereum itself.

This design has a name for a reason. The L1 proposer "bases" the rollup on top of L1 activity. The rollup's transaction ordering is not an independent stream anymore. It rides along with whatever ordering L1 produces, for better and for worse.

What trade-offs does this design impose?

Removing a sequencer is not free. The first cost is latency. A typical L2 sequencer produces blocks every 200 milliseconds to 2 seconds, because it controls its own clock. A based rollup is bound by Ethereum's block time, which on mainnet is currently 12 seconds. That means users wait longer for soft confirmations, and any application that depends on fast feedback, like on-chain order books or aggressive liquidation bots, has to be redesigned for slower cycles.

The second cost is throughput. An L1 proposer has limited space in each block, and that space is shared between regular Ethereum transactions and any based rollup activity. If the rollup gets popular, it competes with swaps, transfers, and DeFi liquidations for inclusion. On a busy day, rollup transactions may sit in queues for several blocks.

The third cost is composability. Most rollup apps today can talk to each other within the same L2 environment almost instantly because they share a sequencer. Based rollups, by design, do not share a sequencer with anyone. Cross-rollup interactions still happen through asynchronous messages and proofs, which are slower and more expensive than the seamless experience users have grown used to inside a single L2.

None of these costs are deal-breakers, but they are real, and they explain why based rollups are not simply "better rollups." They are a specific design choice with specific consequences.

How does this change MEV and trust assumptions?

MEV is the value that can be captured by reordering, inserting, or censoring transactions. In a typical L2, the sequencer captures most of this value, and the rollup's token holders or operators often benefit. The users whose trades are reordered usually do not. A small slice of MEV also leaks to L1 proposers who get to include the rollup's data batches.

In a based rollup, the picture changes. L1 proposers now control ordering end-to-end. They can capture the MEV that used to sit with the L2 sequencer, and that MEV is paid out in ETH, not in the rollup's own token. Proponents argue this is a feature: it aligns incentives with Ethereum, it removes a class of off-chain negotiation, and it stops rollup operators from extracting rent from users.

The honest counterpoint is that L1 proposers are a small, specialized set, and concentrated MEV capture is its own political problem. It also makes the rollup's economics dependent on L1 block construction dynamics, including things like MEV-Boost, builder markets, and PBS (proposer-builder separation) that are evolving quickly.

On the trust side, the simplification is real. Users no longer need to trust a separate sequencer operator to behave. They trust Ethereum's validator set, which is the same trust they already accept when they use L1. The escape hatch, the slow L1 fallback, becomes less of a last resort and more of the normal path. That is a meaningful reduction in assumptions, not just a marketing slogan.

What are the risks of based rollups?

The biggest risk is the opposite of what the marketing claims. Based rollups do not eliminate trust, they concentrate it in Ethereum's L1 proposers. If L1 proposer behavior degrades, for example through censorship, coordinated MEV extraction, or block-building centralization, the rollup inherits all of it. The rollup cannot route around a sick L1 because it is, by design, riding on L1's back.

A second risk is the live operational track record. The approach is still new. Taiko has been the most prominent based rollup in production, and Kraken has launched Ink using a related architecture. These are real deployments with real money, but they are not yet battle-tested through multiple Ethereum upgrades, hard forks, or major L1 validator churn. Any of those events could expose coordination bugs or assumption violations that nobody has seen yet.

Third, the latency and throughput ceiling is a product risk, not just a UX risk. Applications that need fast, predictable inclusion, including derivatives exchanges, certain oracle patterns, and high-frequency trading bots, may find based rollups unsuitable. If a project chooses a based design and then tries to bolt on faster preconfirmations, it ends up recreating the very centralized sequencing layer it set out to remove, just with a different label.

Fourth, there is a token and governance risk. Many rollups have a token, and token holders expect that token to capture value. In a based rollup, the primary value flow goes to L1 validators in ETH. The rollup token has to find a different role, and that role is not obvious. Projects that promise token holders a share of L1 MEV tend to be making promises that the L1 protocol does not actually back.

Finally, the "based" label itself has become a bit of a marketing magnet. Not every project that uses the word is fully L1-sequenced, and some offer hybrid designs where a centralized sequencer still does most of the work and L1 is a fallback. Buyers and builders should read the actual architecture, not the pitch deck.

Who is building based rollups today?

Taiko is the most cited example. It has run a based rollup design on Ethereum mainnet for a sustained period, with a focus on being "based" in the strict sense: L1 proposers include Taiko transactions directly. It has gone through several iterations of its proving system and its fee market as the team learns what works at scale.

Kraken's Ink is another live example. Ink, associated with the broader Kraken ecosystem, uses a based or hybrid approach and has positioned itself around the idea of removing a centralized sequencer from the trust model. The exact architecture is still maturing, and it is one of the designs to watch for anyone who wants to see how the model holds up at consumer scale.

Beyond these, several research groups and OP Stack-based projects have explored partial adoption, where rollups keep a fast preconfirmation layer for users but ultimately settle ordering to L1. These hybrids try to keep the latency benefits of a sequencer and the trust benefits of L1 sequencing, though as noted earlier, the preconfirmation layer reintroduces trust in whoever runs it.

What does this mean for you as a user or builder?

If you are a user, the practical change is subtle. You will see slightly slower confirmations on a based rollup than on a typical L2, and you may notice that bridge times and cross-rollup operations feel different. In exchange, you should expect that no single rollup operator can reorder or censor your transaction in the same way a centralized sequencer can, which is a real, if quiet, improvement in fairness.

If you are a developer, the question is whether your application can tolerate L1 block-time latency and shared-block space competition. DeFi primitives, NFT marketplaces, and many social apps can. Perps DEXs that depend on millisecond-level price updates, certain oracle designs, and games with strict tick rates may struggle. A careful audit of your latency budget, your MEV exposure, and your cross-rollup dependencies is worth doing before committing to a based architecture.

If you are an investor evaluating a rollup token, the based model is a yellow flag rather than a green one. It does not destroy the investment case, but it does mean the usual "the token captures sequencer revenue" thesis does not apply. The token has to earn its keep elsewhere, and the team should be able to explain that clearly.

How to follow based rollups the smart way

Based rollups are a moving target, and the honest read changes as Ethereum's own roadmap evolves. Signals like L1 proposer behavior, MEV-Boost dynamics, and the actual inclusion latency users experience on Taiko and Ink matter more than launch announcements. Zippfeed surfaces rollup and Ethereum headline flow with sentiment scoring, bullish, neutral, or bearish, plus an importance rating, so you can tell genuine architecture shifts from rebrands and marketing. That way you spend less time sorting noise and more time deciding which L2 design, including the based kind, actually fits what you are building or holding.