Beyond Based: Sequencing, Governance, and the Future of Ethereum Rollups

By Tom Lehman, co-founder of Facet

I was invited to give a talk at the Ethereum Foundation on Feb 5, 2025 called "Everything You Need to Know About Based Rollups." This article is adapted from that talk.

Introduction

I started in Ethereum in 2022, but my first experience being front-run was actually in 2016. The damage? Millions of dollars. But who was the perpetrator? A sophisticated MEV bot? jaredfromsubway.eth? No, it was Google!

As CEO of Genius.com, I watched Google scrape lyrics from our website and use their control over search results to place their own lyric results (containing our content) above ours. This hurt our traffic considerably, yet from Google’s perspective it was a great move! They could win at lyrics without having to do any additional work beyond controlling the order of search results.

We caught them "red handed" using hidden watermarks and nearly reached the Supreme Court, but we still lost.

This was a brutal lesson about centralized power in general, and the power of ordering in particular. In response, I turned to Ethereum, determined to help create systems immune to corporate capture. By coincidence—or fate—I discovered that some of the most intense debates in Ethereum revolve around the exact power that Google used to harm my company: who gets to decide what comes first?

Ethereum, like Google, is fundamentally a machine for putting things in order. The difference is that Ethereum's rules are transparent and can't be controlled by a single entity. Yet access to Ethereum's sequencing is increasingly mediated by Layer 2 (L2) protocols, which risk recreating the same centralizing risks we faced with Google.

This piece surveys the sequencing landscape for Ethereum rollups. It began as a "based rollups" explainer, but understanding what "based" means requires seeing how they fit into the broader ecosystem. Pull on these threads and you find deeper questions—topics I’ll explore by covering:

1. Rollup Fundamentals: Why rollups represent a radical new approach to blockchain design—and why they might not get enough credit.
2. Sequencing Models: Who can create transactions on a rollup, and under what rules? We’ll contrast fully "based" vs. centralized sequencing.
3. Governance Models: Once the rules are set, who can change them?
4. Funding: How do we pay for building decentralized rollup technology on a meaningful scale?
5. The Existential Question: Finally, does decentralization even matter?

By walking through these layers, we’ll see how a seemingly technical debate about L2 ordering reveals deeper truths about power, incentives, and the future of a trustless Ethereum.

Understanding Rollups: The Foundation

A rollup is a blockchain, but instead of managing its own state independently, it lets Ethereum serve as the canonical record of who owns which tokens, which NFTs belong to whom, etc. At first glance, this may seem contradictory—rollups rely on Ethereum to determine their entire state, yet they're meant to reduce Ethereum's workload.

The explanation lies in separating two key blockchain tasks:

1. Ordering: Maintaining the canonical record of which transactions happened in what order.
2. Execution: Computing the actual effects of each transaction.

The profound insight of the rollup approach is that of these two vital tasks, only ordering is actually creating new information. Once the sequence of transactions is set, their outcomes are predetermined—execution is just the mechanical process of calculating these predetermined results.

As Jon Charbonneau put it, "Ordering determines truth; execution simply reveals it."

Think of it like following a Lego instruction booklet: if the steps are listed in a fixed order, anyone building from that sequence will end up with the same final result—regardless of who actually assembles the pieces. In the rollup context, Ethereum takes on the role of publishing and finalizing this "instruction manual," while the rollup does the work of "assembling the legos."

This is why rollups can depend on Ethereum while also reducing its burden: Ethereum only handles ordering (the instructions), not the heavy lifting of running every transaction.

An NFT Race: When Ordering Decides the Outcome

Imagine a new NFT collection with only two items available. Three people—Alice, Bob, and Charlie—all try to mint. Which two transactions succeed, and who misses out?

Ethereum’s Traditional Approach

On Ethereum, a smart contract sees all three mint transactions and executes them in order, checking the remaining NFT supply and updating everyone’s balances as it goes. This is straightforward but costly—it relies on Ethereum itself to do all the computation.

The "Paper and Pen" Approach

Suppose we want to arrive at the same final result but avoid expensive on-chain logic. We record each mint transaction in the exact order Ethereum saw it and manually track the NFT supply on paper. Bob’s transaction is first (one NFT gone), Alice’s is second (zero left), so Charlie’s fails.

Because Ethereum has already fixed the transaction order, this off-chain "paper and pen" method must yield the same outcome. The contract and your paper both rely on the same ordered data, so the results can’t differ.

Back to Rollups

A rollup implements this same principle. Instead of using pen and paper, specialized software called a "rollup node" tracks the state off-chain, using Ethereum purely to finalize transaction order. This cuts costs, because Ethereum no longer does all the execution—it only provides the ordered list of transactions.

Putting it all together

Here's how a rollup system works in practice:

User Intents → L1

User transactions (or "intents") are posted directly to Ethereum. Like adding steps to a public Lego instruction manual, once these are posted, their order is final and determines the outcome.

When transactions are posted in this way, Ethereum is acting as the "data availability layer" for the rollup, though this label is somewhat misleading as it implies that Ethereum is just storing transaction data. But posting transactions to Ethereum isn't just about making data available—it's how the rollup establishes the canonical ordering of transactions. A better name could be "data ordering and availability layer" or even "truth-determining layer."

Rollup Node

The rollup node acts as the "lego assembler." It watches Ethereum for new transactions and processes them in order, maintaining a complete record of account balances, NFT ownership, and other state details.

Checking State

Because rollup nodes have processed all transactions, users can query them directly about current balances or NFT ownership—like asking to see the Lego model. This doesn't involve Ethereum.

Proofs

A common misconception is that proofs (optimistic or ZK) secure a rollup’s truth—but Ethereum’s ordering already does that. Instead, proofs provide a way to verify the final state without re-running every transaction.

In the Lego analogy, a proof is like a mathematically verifiable photo showing the model was assembled exactly as instructed. Anyone can build the model (run a rollup node) to confirm the result, but proofs let people—especially L1 contracts—verify correctness more efficiently.

Sequencing: Where the Power Lies

We've seen that rollups derive their state from transaction ordering on Ethereum. But this raises the question: who gets to post these transactions to Ethereum? Whoever controls what gets posted to Ethereum, and in what order, effectively controls the rollup's entire state.

There are two fundamentally different approaches:

• Based Sequencing: Anyone can post transactions to Ethereum
• Centralized Sequencing: Only designated parties can post (also called "run-ahead" sequencing)

Given the Ethereum community’s focus on decentralization, why is based sequencing, the more decentralized option, only now gaining popularity? It might surprise you to learn that the idea of based sequencing actually precedes that of centralized sequencing, which became dominant as a response to based sequencing’s limitations.

In this spirit, let’s examine based sequencing first.

Based Rollups: Embracing Ethereum's Rules

Based rollups let anyone post rollup blocks¹ to Ethereum, an approach that Vitalik Buterin called "total anarchy" in 2021. Under based sequencing, a rollup block gets posted directly to Ethereum, creating a one-to-one relationship between L1 and L2 blocks. Once your transaction makes it into an Ethereum block, it's final (barring an L1 reorg).

How It Works:

1. Users broadcast transactions to a public mempool
2. Anyone can bundle these into an L2 block
3. These block producers compete to post to Ethereum
4. Ethereum's consensus decides which block wins
5. When Ethereum finalizes it, your L2 transaction is final

The core insight here is that if rollups already trust Ethereum for ordering, why not reuse Ethereum for sequencing as well? Instead of building complex sequencing mechanisms on top, based rollups simply say "whatever Ethereum decides is what happens."

This principle of "no additional assumptions" means:

• If Ethereum is censorship resistant, your rollup is censorship resistant
• If Ethereum is live, your rollup is live
• If Ethereum reorgs, your rollup reorgs
• If users understand Ethereum's consensus, they understand your rollup

Trade-Offs

• Pros:
• You inherit Ethereum’s censorship resistance and liveness
• Gain scale without additional trust assumptions
• Simpler to understand and audit
• Cons:
• Slower confirmations (12s+ block times)
• Less MEV revenue for the rollup
• Higher posting costs (can't batch as efficiently)
• Subject to L1 reorgs

Centralized / Run-Ahead Sequencing

While based rollups embrace Ethereum's limitations, run-ahead sequencing takes a different approach: start with the user experience you want, then figure out how to build it securely. The core challenge is that users want instant transaction confirmations, but Ethereum has 12 second block times.

The Innovation: "Running Ahead"

The solution is clever: instead of waiting for rollup blocks to make it to Ethereum, let a single sequencer "run ahead" by creating temporary off-chain "unsafe" blocks. These blocks exist only in the sequencer's off-chain internal state but give users immediate feedback about their transactions.

Think of it like ordering at a restaurant. When you tell the waiter what you want, they immediately confirm your order—but this isn't a guarantee your food will be cooked. The waiter is just promising to deliver your order to the kitchen. If they never make it back to the kitchen, your order could be lost. But we accept this risk because the alternative—walking to the kitchen yourself for every order—would be too inconvenient.

Run-ahead sequencing works the same way. Instead of waiting for Ethereum (the kitchen), a central sequencer (the waiter) gives you immediate confirmation while promising to eventually deliver your transaction to Ethereum. For example:

1. You submit a Uniswap swap transaction to the sequencer
2. The sequencer simulates it and returns a "this swap succeeded" message right away
3. Every few minutes, the sequencer bundles many "unsafe" blocks together and posts them to Ethereum
4. Once included on L1, these blocks become "safe" and cannot be changed (barring an L1 reorg)

However, just like a waiter could lose your order or change it before reaching the kitchen, during this "unsafe" period, the sequencer can:

• Reorder transactions to capture MEV
• Delay specific users or transactions
• Completely omit transactions it doesn't like

The Safety Net: Forced Inclusion

To prevent abuse, these systems typically implement "forced inclusion"—a way to bypass an uncooperative sequencer by posting directly to Ethereum. Continuing our restaurant analogy, it's like being able to walk straight into the kitchen if your waiter is ignoring you.

1. Users post transactions directly to a special "inbox" contract on Ethereum.
2. The rollup protocol prepends these forced transactions to the next batch of sequencer transactions—they must be processed first, before any sequencer-chosen transactions.
3. The sequencer must check this inbox when confirming new transactions, since forced transactions could affect the rollup's state.

In other words, if you force-include a transaction, you get a guaranteed spot at the front of the sequencer’s next batch, but you still have to wait for the batch to be posted. This prevents permanent censorship, but how well does it protect users against other forms of sequencer exploitation?

The Limits of Forced Inclusion: Beyond Simple Censorship

While forced inclusion appears to solve the censorship problem on paper, in reality sequencers retain significant power through two key mechanisms: timing control and the "handoff problem."

Timing Control: The Sequencer's First Line of Defense

Even with forced inclusion, sequencers maintain considerable control through batch timing:

• Users can submit forced transactions, but these only execute when the sequencer posts its next batch to L1.
• While protocols typically set maximum delays (e.g., 30 minutes), sequencers can strategically time their batches.
• This can create a "hurry up and wait" situation where users can force their transactions in, but can't control when they actually execute.

The "Handoff Problem"

The more subtle but powerful limitation is what's known as the "handoff problem." This arises because the sequencer controls the transaction environment both before and after your forced transaction.

Say you want to trade USDC for ETH on a DEX. You're willing to accept up to 2% price movement. You notice the sequencer is ignoring your trade, so you force it through. But the sequencer can:

1. Buy ETH to push the price up by 2.1%
2. Let your forced trade go through (it fails due to the price change)
3. Sell the ETH to bring the price back down

It's like trying to bypass an uncooperative waiter by going straight to the kitchen to order the last lobster. The waiter:

1. Quickly claims the lobster for another table
2. Lets your kitchen order fail ("Sorry, no lobster left!")
3. Cancels their order, freeing up the lobster after you leave

In both cases, your transaction was technically "included," but you still couldn't get what you wanted. This affects any transaction where success depends on conditions the sequencer can influence.

However this problem doesn’t affect self-contained operations like:

• Token transfers
• Basic contract interactions that don't depend on manipulatable state
• Withdrawals to L1 (though timing can still be controlled)

The recent Soneium controversy in which the rollup blocked a token named $aibo from being traded at the sequencer level is instructive. In this case, users were able to turn to forced inclusion to exit their DEX positions. Were Sony exploiting the hand-off problem they might not have been as successful.

Conclusion

Centralized sequencing—running ahead with off-chain blocks—vastly improves user experience by offering near-instant transaction confirmations. But these fast confirmations come with an asterisk—they're promises, not guarantees. Users must temporarily trust the sequencer to keep its word about transaction ordering and inclusion until the next L1 batch is posted. While forced inclusion exists as a safety net against complete censorship, we've seen that it's an imperfect solution with its own limitations and vulnerabilities to manipulation.

Trade-Offs

• Pros:
• Super-fast confirmations off-chain.
• Cost-efficient L1 data posting by batching many L2 blocks together
• Full L1 security once transactions are finally posted
• Cons:
• Relies on a single sequencer—if they're offline, all transactions halt
• Potential censorship & MEV extraction.
• Forced inclusion is slow, and can be gamed ("handoff problem")

Preconfirmations: Can Based Rollups Match Centralized Speed?

The Market Has Spoken: Speed Matters

The market's verdict is clear: users prefer fast transaction feedback, even with additional trust assumptions. This reality has forced based rollups to confront the question: can they match centralized rollups' speed without compromising their security principles?

Preconfirmations: A Compromise Solution

Preconfirmations represent an attempt to have it both ways: the speed of run-ahead sequencing with the security of based rollups. Preconfirmations have not yet been used in production, but the concept is simple:

1. Instead of submitting transactions directly to the L1 mempool, users send them to a "gateway."
2. The gateway promises "Your transaction will be included in an upcoming L1 block."
3. The gateway coordinates with block builders and proposers to fulfill this promise.
4. If the gateway breaks its promise, it loses staked funds.
5. Users get fast feedback while maintaining L1-based sequencing.

"Another trusted third party"?

However, in solving the speed problem, preconfirmations risk reintroducing the trust assumptions that based rollups were designed to eliminate. The gateway becomes a new trusted intermediary, requiring bonding and slashing mechanisms to ensure honest behavior and fallback systems when it fails.

And even with these added risks and complexity, users might not get the full benefits of run-ahead sequencing. In most designs, gateways typically can only confirm that a transaction will be included—not whether it will succeed—and even then they can't guarantee exact block placement.

The Core Tension

Based rollups face a difficult choice. Their core appeal lies in their "no additional trust assumptions" model and elegant simplicity. Preconfirmations risk compromising these principles—but without them, based rollups might struggle to attract users who demand fast feedback.

The Convergence of Rollup Designs

As Jon Charbonneau argues, beneath their apparent differences, both centralized and based sequencing are pursuing the same goals:

• Fast user feedback (sub-second confirmations)
• Strong security guarantees (L1 anchoring)
• Protection against censorship (forced inclusion)

The apparent divergence in their approaches—whether using preconfirmations, run-ahead blocks, or other mechanisms—might be more about implementation than fundamental philosophy. Each design represents a different way to balance the same core requirements.

There is No "Free Lunch"

A pattern emerges when we examine these different approaches: any improvement in user experience beyond what Ethereum provides requires introducing additional trust assumptions. This raises the question: Should rollups try to overcome Ethereum's limitations, or should we focus on making Ethereum itself faster?

Rethinking the Division of Labor

While improving L1 to better serve rollups might seem appealing, Ethereum faces other pressing challenges such as decentralizing block building and implementing anti-censorship mechanisms.

Perhaps the optimal architecture builds on what we have today:

• L1 focuses exclusively on security and decentralization
• L2s handle user experience improvements
• Additional trust assumptions are clearly "encapsulated" at the L2 level

This division of responsibilities could provide the best of both worlds: a rock-solid foundation in Ethereum, with more flexible L2s free to make different trade-offs based on their specific needs.

Synchronous Composability: Based Rollups' "Secret Weapon"?

While based rollups have historically "played defense"—trying to match centralized sequencers' speed—"synchronous composability" suggests a different path. Instead of just catching up, based rollups might offer something entirely new through their tight synchronization with Ethereum's L1.

How Synchronous Composability Works

When multiple rollups have their transactions posted in the same L1 block, atomic cross-rollup operations become theoretically possible. Imagine a complex DeFi transaction:

1. Borrow a 1M USDC flash loan from Aave on Rollup A
2. Use it for arbitrage trades on Rollups B and C
3. Repay the loan on Rollup A

With synchronous composability, all these steps either succeed or fail together—just like smart contract interactions in pre-rollup Ethereum. No more complex bridging or worrying about partial success.

As another example, consider booking a trip to ETHDenver:

Today's World (Asynchronous):

• Book flight for $500
• Try to buy conference ticket
• If conference is sold out, you're stuck with the flight
• Need refund mechanisms, cancellation policies, trust etc.

With Synchronous Composability:

• Book flight AND conference as one operation
• Either get both or get neither
• No need for refunds or reversals

The Debate: Revolutionary or Overrated?

The traditional finance world functions efficiently with asynchronous operations, as does the internet itself. Observations like these led Vitalik Buterin to famously call synchronous composability "overrated." But as Justin Drake counters: shouldn't blockchain technology improve upon these limitations rather than simply recreating them?

Technical Challenges

Achieving this vision requires solving significant technical challenges. One core problem is "real-time proving"—since rollups operate in separate execution environments, they need a way to prove their state to each other quickly and efficiently. While active research is underway, the technology to make this possible doesn't exist today.

A New Direction for Rollups

If these technical hurdles can be overcome, synchronous composability could redefine what's possible in the rollup ecosystem. Rather than based rollups merely trying to match centralized ones on speed, they could enable entirely new categories of applications built around atomic cross-rollup operations. This suggests that the future of rollups isn't just about balancing familiar trade-offs—it's about unlocking new capabilities that weren't possible before.

Governance Risks

While we've explored the intricacies of rollup mechanics, there's a more fundamental concern that overshadows all technical considerations: Who can change the rules?

Protocol Changes: Forks vs. Configuration

Like any blockchain, rollups can be forked—creating a new version with different rules that users can choose to follow or ignore. Think of how chess rules evolve: in 2014, FIDE (the international chess federation) added a rule that automatically declares a draw if 75 moves pass without a capture or pawn movement. No one can force you to play by this new rule—the only pressure to adopt the change comes from the fact that most other players have accepted it.

The same is true for the Ethereum L1. When Ethereum switched from proof-of-work to proof-of-stake (the Merge), users were technically free to continue using the proof-of-work chain. But social consensus made this impractical—the value of assets depends on which chain other people recognize, and the Ethereum Foundation's trademark ownership means only their chosen chain can be called "Ethereum."

Beyond forks, Ethereum L1 has some flexibility to change through social consensus—validators can "vote" to adjust the block gas limit, for instance. But rollups have introduced something new: the ability to change rules through L1 smart contracts.

In certain cases this is uncontroversial. For example, some rollups manage their sequencer's address with an L1 contract. Here's how it works: rollup nodes read from this “system configuration contract” every block to determine the current authorized sequencer address and when processing batches only accept transactions from that source.

This is useful because if the sequencer's address needs to be changed, admins can simply update the address in the contract. Nodes automatically pick up the new value without requiring a coordinated fork—an elegant solution for this specific case.

In addition to predefined configuration options, however, many rollups rely on L1 smart contracts that are arbitrarily upgradeable. While users can plan around certain predefined capabilities (like updating the sequencer’s address), upgradeable contracts can be modified to add entirely new capabilities that weren't initially contemplated.

An Example: Halting All Transactions

Remember our restaurant analogy: when your waiter (centralized sequencer) ignores you, you can walk straight to the kitchen to place your order (use forced inclusion). But imagine the restaurant owner responds by firing the waiter and locking the kitchen doors. Now it doesn't matter if you're willing to place the order yourself—there's simply no way to get food.

This isn't theoretical. All centrally-sequenced rollups on mainnet today can shut down sequencing entirely through a multi-sig. In 2024 Blast demonstrated this approach by blocking three addresses from using forced inclusion in order to prevent them from withdrawing stolen funds.

Nor is this vulnerability specific to centralized sequencing—based rollups can have the same issue. For example, Taiko's 3-of-5 multisig can disable based sequencing entirely.

This is far worse than the handoff problem we discussed earlier—instead of just making transactions difficult, governance can make them impossible.

What Should We Do With These L1 Smart Contracts?

In traditional rollup architectures like the OP Stack, privileged L1 contracts serve three key functions:

1. Sequencer selection: maintaining the current sequencer address
2. Forced inclusion mediation: managing the processing of user transactions when the sequencer fails
3. Gas token bridge: controlling the rollup's gas token (typically bridged ETH)

The first of these is innocuous—updating a sequencer address when keys are lost shouldn't require a fork. However, the ability to disable forced inclusion or based sequencing is far more concerning. If a rollup claims these security features, it should guarantee they cannot be overridden by administrators. If such changes are truly needed, they should happen through forks where users must actively choose to follow the change.

The bridge problem, however, is not so black and white. While protocol changes can be handled through forks, bridge contracts cannot because they hold real assets on L1. You can't fork away from a bridge contract holding millions in ETH or stablecoins. Bridge contracts need upgradeability for two fundamental reasons:

• Security: even completely altruistic teams need to patch vulnerabilities
• Protocol evolution: bridges must update to verify proofs as rollup rules change

Solving the Gas Token Bridge Issue

How can we solve it? There are three approaches:

1. Sovereign rollups: eliminating privileged contracts entirely
2. Native rollups: building verification into Ethereum itself
3. DAO governance: distributing control through tokens

Sovereign rollups

A sovereign rollup is a rollup that doesn’t depend on L1 smart contracts. In the context of the bridge issue, a sovereign rollup is a rollup that uses a native asset instead of a bridged asset for its gas token. Instead of depositing ETH into an L1 contract to increase your native balance on the rollup you would take a different action.

The OP Stack partially implements this idea for their forced inclusion mechanism. When you force a transaction on an OP Stack chain you pay for the L2 gas by spending gas on the L1. This enables you to use OP Stack chains without bridging at all—though this is still subject to an admin-controlled forced-inclusion mechanism.

Facet takes this concept further: it not only lets you pay L2 gas directly with L1 gas but also allows you to increase your L2 balance in the same way. Because Facet's sequencing cannot be disabled by any administrator key, it eliminates protocol-level governance risk entirely.

However, while a native gas token design removes the need for rollup-controlled bridges in protocol mechanics, it does not eliminate the broader demand for bridging. Users will still want to transfer ETH and other assets across chains. This means decentralized, proof-based bridges remain necessary for the ecosystem, even if they are not, strictly speaking, mandatory for rollup users.

Next, we'll explore native rollups, a more ambitious (though still theoretical) approach that aims to remove upgradeable bridges altogether by integrating rollup state verification directly into Ethereum.

Native Rollups: Rethinking Proof Systems

What if L1 smart contracts could verify rollup state more directly? This is the key insight behind native rollups: instead of relying on complex, upgradeable proof systems in L1 contracts, we could build rollup state verification directly into Ethereum itself.

Built-in Rollup State Verification

For a rollup bridge to work, its L1 contract must always know the current state of the rollup. This is a prerequisite for verifying user claims about L2 actions, like withdrawal initiations, before finalizing them on L1.

Strictly speaking, the bridge doesn't need to know the full rollup state in a way that it can answer user questions about it—it just needs to know enough about the state that it can validate user claims. Doing this requires only a small amount of data called the "state root."

How can a bridge contract maintain a correct rollup state root? Here’s how it works in a native rollup:

1. The bridge contract starts with a known good state root.
2. As the rollup processes transactions, users submit new state roots to the contract, along with a list of transactions they claim transitioned from the known good state root to the new proposed one.
3. The contract can’t just trust these updates, it must validate them.
4. In traditional rollups, the contract would rely on proof systems with significant off-chain components. But in a native rollup, the contract would use a built-in Ethereum function (a "pre-compile") that returns "true" if the transactions resulted in the claimed state.
5. If the transition was valid, the contract updates its "known good state" to the new state.
6. Users can then prove their withdrawals were valid against the new state root and receive their funds.

Key Benefits

While this approach might look similar to traditional rollups at first glance—it's just replacing the proof system, after all—the benefits are significant:

1. Automatic Evolution: Traditional rollups must update their proof systems whenever Ethereum adds new functionality. With native rollups, this evolution happens automatically because the EVM itself handles validation. There's no need for governance or manual updates—as Ethereum grows, rollups naturally gain new capabilities.
2. Better Security Model: In traditional rollups, proof system bugs are the sole responsibility of the rollup team, potentially leading to lost funds and requiring complex governance to mitigate. With native rollups, any validation bugs would be Ethereum bugs, benefiting from the entire community's coordination and social consensus around fixing critical issues. While the L1 would likely never fork to recover funds lost in a rollup protocol bug, it could theoretically fork to fix a critical EVM bug affecting multiple rollups.
3. Simplicity: Rather than each rollup maintaining its own complex proof system, native rollups move this complexity into the EVM itself. This means one well-audited implementation can secure many rollups, significantly reducing the points of potential failure.

The Challenges

This solution is appealing because it could eliminate the need for privileged contracts while still enabling bridged gas tokens. However, two significant challenges emerge:

• Verification Scope: While validating basic EVM operations is straightforward, rollups often have unique rules (like checking sequencer identity) that go beyond simple computation. A generic pre-compile might not capture all the validation a specific rollup needs.
• Ethereum Upgrade Process: Implementing native rollups requires protocol-level changes to Ethereum—a process that historically moves slowly and carefully to maintain security. Also, while native rollups "upgrade automatically" as Ethereum evolves, these upgrade cycles would likely be longer than current rollup protocols are used to.

Despite these challenges, the native rollup approach represents an important direction for research. It suggests a future where rollups could achieve both perfect security alignment with Ethereum and full-featured bridging capabilities.

DAOs: Legitimizing Governance Power

A third approach, sometimes called "Stage 3" rollups, proposes to solve the admin key problem not by eliminating governance power, but by legitimizing it through DAO structures.

This mirrors how many organizations work: a board of directors firing a CEO might be controversial, but it can't be called illegitimate if it follows proper governance procedures. Similarly, a well-structured DAO with economic incentives, transparent processes, and broad token-holder participation could provide a framework where governance decisions, while debatable, are fundamentally legitimate by definition.

In practice, this would mean:

• Creating a governance token that's expensive to accumulate and attack
• Implementing voting structures that make manipulation difficult
• Building transparent processes for protocol changes

This approach could create systems that cost billions to exploit—but therein lies a fundamental limitation: a rollup DAO token will likely never achieve the market cap and security of ETH itself. This means a DAO-governed rollup, while potentially very secure, would still be easier to attack than Ethereum's L1.

Beyond the theoretical security ceiling, there's a more immediate practical concern: we've never seen a DAO successfully manage billions of dollars and a complex protocol without falling back on security councils or oversight committees. Even Optimism, arguably the most sophisticated player in the rollup DAO space, maintains additional oversight layers.

This raises the question: is DAO governance actually solving the upgradeability problem, or just replacing it with an even harder one?

The Tension: Decentralization vs. Funding

Despite these challenges, many rollup teams plan to eventually transition to DAOs to address governance risk and bridge security. And DAOs offer one crucial advantage: a clear funding model for ongoing development and security research.

The Token Value Proposition

Governance tokens create a paradox. The more power the DAO has, the more valuable its token becomes—and the harder it is to attack. At the same time, the more control a DAO holds, the greater the damage if governance fails.

Valuable governance tokens don’t merely protect DAOs from attack, they can be allocated to the rollup core team, grant programs, and ecosystem growth, ensuring long-term sustainability.

A no-governance rollup, on the other hand, is constrained: it can’t set up the protocol to give it an edge in collecting sequencing fees / MEV, and it can’t issue a token that grants holders governance rights.

This leads to the fundamental problem: who funds a decentralized rollup?

Rollup development isn’t just about sequencing models or protocol rules in general—it’s about incentives. How do you build, secure, and grow a decentralized network when you can’t offer investors special privileges in return?

Conclusion: Who Really Cares About Decentralization?

Let's trace how our understanding of rollup challenges evolved, with each layer revealing an even more fundamental issue beneath:

We began by understanding rollups themselves—how they work by posting transactions to Ethereum and computing their effects off-chain. This led us to what seemed like the most important question: Who gets to post these transactions?

This brought us to sequencing models:

• Based sequencing: permissionless but slower
• Run-ahead sequencing: faster but requiring trust

But as we dug deeper, we realized sequencing wasn't actually the root issue. The sequencer, after all, must follow the rollup's rules. This revealed a more fundamental question: Who can change these rules?

This governance question led us to three potential approaches:

• Sovereign rollups: eliminating privileged contracts entirely
• Native rollups: building verification into Ethereum itself
• DAO governance: distributing control through tokens

Yet this governance analysis revealed an even more fundamental challenge: funding. No matter how elegant your security model or how decentralized your governance, someone needs to pay for development, maintenance, and security research.

But now we reach an even more basic question: Does decentralization matter at all?

This is truly fundamental because:

• If users don't care about decentralization, the funding problem disappears—centralized solutions are profitable and well-understood.
• If decentralization doesn't matter, we don't need complex governance models.
• If users are happy with trusted systems, we don't need to solve any of these technical challenges.

This question is particularly challenging because the obvious answer seems to be "no." Most of the world runs on centralized systems, and most of the time, they work just fine.

There is a rule of thumb in startups: a new solution must be 10x better than the incumbent to motivate users to change their behavior. By this standard, decentralized systems appear to fail—in everyday use, they're often slower, more complex, and more expensive than their centralized counterparts.

And yet.

The Insurance Argument: Protecting Against Tail Risk

When we observe that "centralized systems work fine," we're looking at a snapshot in time. But platforms can evolve toward exploitation. Google is the perfect example—their founders explicitly promised not to prioritize their own content. In their 2004 IPO filing, Larry Page said:

Most portals show their own content above content elsewhere on the web. We feel that's a conflict of interest... Google conscientiously tries to stay away from that. We want to get you out of Google and to the right place as fast as possible.

Many companies not only believed these statements, they built businesses that relied on them! Genius is one such company. By the time Google began competing with its former partners, it was too late to build alternatives.

This experience has parallels in the rollup ecosystem. Today's rollup admins, like 2004 Google, act benignly and espouse high principles. But as power accumulates and stakeholder pressure increases, the temptation to abuse it increases as well.

This is why decentralization matters: it is insurance you pay for today because if you wait until you need it it will be too late.

The value of this insurance is already evident in the ecosystem's emergent behavior. With over 50 nearly identical rollups live, why are organizations launching more constantly? Because they don't trust each other's control. This drives them to waste enormous resources rebuilding similar infrastructure, all to avoid depending on someone else's platform.

Many of these teams would gladly give up control of their infrastructure—if they could be certain no one else would control it either. This reveals that centralization's apparent efficiency can be an illusion. The "cost savings" of centralized systems are often outweighed by the duplicated effort of everyone building their own.

Ethereum's original promise was a world computer where parties could collaborate without trust. And yet it has evolved into an ecosystem of competing and incompatible fiefdoms. As rollup technology advances, we must return to the spirit of cooperation that public blockchain infrastructure originally promised.

About the Author

Tom Lehman is the co-founder of Facet, a fully based rollup project that cannot be shut down. The principle behind Facet is that decentralization must be the first thought in a rollup, not a promise. He previously co-founded Genius.com where he served as CEO from 2009–2021.