The Governance of Execution: A Comparative Analysis of Sovereign and Based Rollup Architectures

Executive Summary: The Divergence of Modular Execution

The architectural evolution of blockchain scalability has transitioned from a focus on raw throughput to a fundamental re-evaluation of execution governance. As the monolithic blockchain paradigm decomposes into modular layers—separating Data Availability (DA), Consensus, Settlement, and Execution—a critical dichotomy has emerged in the design of Layer 2 (L2) systems: the distinction between Sovereign Rollups and Based Rollups. This report provides an exhaustive technical analysis of these two paradigms, focusing specifically on the locus of control regarding transaction execution, ordering, and finality.

The core inquiry of this analysis is “Who controls execution?” In the context of modular blockchains, this question is not merely about who processes the transaction, but who has the ultimate authority to order transactions, determine validity, and resolve forks. In Sovereign Rollups, control is retained by the rollup’s peer-to-peer (P2P) network and social consensus, treating the underlying Layer 1 (L1) merely as a publication medium.1 This model emphasizes autonomy and flexibility, allowing communities to fork at will. In stark contrast, Based Rollups delegate the power of sequencing to the L1 proposer set, aligning the rollup’s liveness and economic security directly with the base layer.3 This delegation seeks to inherit the full decentralization and censorship resistance of the L1, turning the rollup into a direct extension of the base protocol.

This report explores the technical underpinnings of these divergent paths, analyzing the mechanics of “Client-Side Settlement” in sovereign chains versus the “L1-Sequenced” model of based chains. It further investigates the emerging complexities of “Based Preconfirmations” and the hybrid “Based Sovereign” architectures that seek to reconcile these opposing philosophies. Through detailed case studies of Celestia, Taiko, and the theoretical frameworks proposed by researchers like Justin Drake, we delineate the future landscape of execution governance.

1. The Modular Decomposition and the Execution Crisis

1.1 The Shift from Monolithic to Modular

To understand the divergence between Sovereign and Based rollups, one must first contextualize the shift from monolithic to modular architectures. In a monolithic blockchain like Ethereum (pre-rollup) or Solana, a single network of validators is responsible for all four core functions:

1. Execution: Processing transactions and updating the state.
2. Settlement: Dispute resolution and bridging.
3. Consensus: Ordering transactions.
4. Data Availability (DA): Ensuring transaction data is accessible.

The rollup-centric roadmap acknowledges that asking a single validator set to perform all these tasks imposes severe scalability limits. By decoupling execution, rollups allow for specialization. However, this decoupling introduces a new problem: Fragmentation of Sovereignty. When execution moves off-chain, who decides what is valid?

1.2 The Two Answers to Validity

The industry has coalesced around two primary answers to the validity question, which form the basis of the Sovereign vs. Based distinction:

1. The Enshrined Settlement Model (Smart Contract Rollups): This is the model used by Optimism, Arbitrum, and ZK-Sync. A smart contract on the L1 acts as the “light client” for the L2. The L1 contract verifies proofs (fraud or validity) and determines the canonical state of the L2.5 In this model, the L1 is the supreme court; the rollup is a jurisdiction within the L1’s legal system.
2. The Sovereign Model: This model rejects the idea that the L1 should adjudicate L2 validity. Instead, the L1 is treated solely as a bulletin board for ordering data. The interpretation of that data—determining which transactions are valid—is left entirely to the nodes of the rollup itself.2

1.3 The Emergence of Based Sequencing

Parallel to the validity debate is the sequencing debate. Most “Smart Contract Rollups” today utilize centralized sequencers for performance, creating a single point of failure and censorship. Based Rollups emerged as a solution to this centralization, proposing that the L1’s existing decentralized validator set should take over the sequencing role for the L2.3

Thus, we have a matrix of possibilities defined by two axes: Who orders? and Who settles?

Table 1: The Rollup Taxonomy Matrix

Architecture	Who Orders (Sequencing)?	Who Settles (Validity)?	Examples
Smart Contract Rollup	Centralized / Shared Sequencer	L1 Smart Contract	Optimism, Arbitrum
Sovereign Rollup	Centralized / DA-based	Local P2P Nodes	Rollkit on Celestia
Based Rollup	L1 Proposers	L1 Smart Contract	Taiko, Ridley
Based Sovereign Rollup	L1 Proposers	Local P2P Nodes	Bitcoin Rollups (Theoretical)

2. The Sovereign Rollup Paradigm

2.1 Architectural Definition: The “Client-Side” Settlement Model

The Sovereign Rollup (SR) represents a radical departure from the Ethereum-centric view of Layer 2s. In the SR model, the “rollup” is not a contract on a blockchain; it is a software protocol run by a distributed network of nodes, much like a Layer 1 blockchain. The crucial difference is that instead of maintaining their own consensus set (miners/validators), SR nodes pay an external blockchain (the DA layer) to handle the ordering of their transaction batches.1

This architecture is often described as “Client-Side Settlement.” The DA layer—whether it be Celestia, Avail, or Bitcoin—remains agnostic to the content of the data. It guarantees only that the data has been published and ordered. It does not verify signatures, state roots, or execution traces. The logic of the chain lives entirely in the client software installed by the rollup’s users and validators.2

The Transaction Lifecycle in Sovereign Rollups

The lifecycle of a transaction in a Sovereign Rollup underscores the shift in control:

1. Creation: A user signs a transaction according to the SR’s VM rules (EVM, SVM, Move, etc.).
2. Publication: The transaction is sent to a sequencer (or directly to the DA layer). The sequencer batches transactions and publishes them as a “blob” to the DA layer.6
3. Ordering (Consensus): The DA layer’s validators order the blob within a block and attest to its availability. This provides the definitive “Input Sequence” for the rollup.
4. Local Derivation: All full nodes of the Sovereign Rollup constantly sync with the DA layer. They download the block, filter for blobs belonging to their rollup’s namespace (using Namespaced Merkle Trees in Celestia), and process the blobs.9
5. Execution & Validity: The node locally executes the transactions. If a transaction in the blob is invalid (e.g., trying to mint infinite tokens), the DA layer has already included it. However, the SR node simply skips it during execution, marking it as invalid in its local state database.
6. Finality: The transaction is final for the user when their local node has processed the DA block containing it. There is no waiting for an L1 smart contract to confirm validity.11

2.2 Sovereignty via Fork Choice Rules

The defining characteristic of the Sovereign Rollup, and the core answer to “Who controls execution?”, is the Fork Choice Rule. In a traditional blockchain, the fork choice rule (e.g., Nakamoto Consensus, GHOST) allows nodes to agree on the head of the chain. In a Sovereign Rollup, the fork choice rule is interpreted relative to the data on the DA layer.6

The Implications of Social Forks

Because the “canonical chain” is defined by the client software and not an on-chain contract, Sovereign Rollups possess the unique ability to Hard Fork via social consensus.

• Scenario: Imagine a massive hack occurs on the rollup due to a bug in the VM.
• Smart Contract Rollup Response: The community must lobby the “Security Council” or the L1 governance (if the contract is upgradeable) to pause the bridge or upgrade the code. If the contracts are immutable, the funds are lost forever unless the L1 itself forks (which is unlikely).
• Sovereign Rollup Response: The community releases a software update (Patch v2.0) that modifies the state transition function to revert the hacker’s transaction. Nodes that upgrade effectively fork away from the hacker’s chain. The DA layer continues to store data for both “forks,” but the economic majority follows the new path. This aligns the governance model of the rollup with that of L1 blockchains like Ethereum or Bitcoin.1

This capability is termed “Social Sovereignty.” It ensures that the execution rules are ultimately beholden to the community of stakeholders, not a set of immutable smart contracts or a multisig council on a foreign chain.1

2.3 Implementation Case Studies: Celestia and Rollkit

Celestia is the primary enabler of this paradigm, optimizing its architecture solely for Data Availability via Data Availability Sampling (DAS) and Namespaced Merkle Trees (NMTs).9

Rollkit acts as the framework for building these chains. It introduces the concept of the “Pure Fork-Choice Rule” rollup. In this design, there is no “settlement layer” in the traditional sense. The rollup nodes are light clients of the DA layer and full nodes of the execution layer.

• Censorship Resistance via DA: If the rollup’s sequencer attempts to censor transactions, users can submit “Inbox Transactions” directly to the DA layer. Rollkit nodes are programmed to read these forced transactions from the DA layer and include them in their local state execution, bypassing the sequencer entirely.11
• Bitcoin as a Sovereign Host: The concept extends to Bitcoin. Since Bitcoin cannot verify ZK proofs natively, rollups on Bitcoin (like those using the BitVM or sovereign approaches) use Bitcoin purely for ordering and data storage, relying on the sovereign model for validity.16

Table 2: Locus of Control in Rollup Architectures

 

Feature	Smart Contract Rollup (Enshrined)	Sovereign Rollup
Source of Truth	L1 Smart Contract	Local Node Client / P2P Network
Validity Check	On-chain (Fraud/Validity Proof)	Client-side (Local Execution)
Upgrade Mechanism	Contract Upgrade (Multisig/DAO)	Hard Fork (Social Consensus)
Bridge Trust	Trust-minimized (Enshrined)	Trust-based or Peer-to-Peer 18
Response to Hacks	Rely on L1 or Council	Social Fork 13
Settlement Latency	Dependent on Proof Verification	Dependent on DA Finality + Local Execution

3. The Based Rollup Paradigm

3.1 Definition: “Total Anarchy” to Organized Delegation

While Sovereign Rollups seek independence from the L1, Based Rollups (or L1-sequenced rollups) seek total alignment. The concept, originally described by Vitalik Buterin as “Total Anarchy” and later formalized by Ethereum Foundation researcher Justin Drake, defines a rollup not by its settlement method, but by its sequencing mechanism.1

Definition: “A rollup is said to be based, or L1-sequenced, when its sequencing is driven by the base L1. More concretely, a based rollup is one where the next L1 proposer may, in collaboration with L1 searchers and builders, permissionlessly include the next rollup block as part of the next L1 block”.1

This definition answers “Who controls execution?” definitively: The L1 Validator Set. There is no separate sequencer entity, no “PoS Leader Election” for the L2, and no centralized server processing transactions. The L2 piggybacks entirely on the L1’s block production pipeline.

3.2 Technical Architecture: Leveraging Proposer-Builder Separation (PBS)

Based Rollups are uniquely enabled by the Proposer-Builder Separation (PBS) architecture inherent in modern Ethereum. The transaction lifecycle reveals how L2 execution is subsumed into L1 block building:

1. L2 Transaction Submission: Users submit L2 transactions to the public mempool or directly to specialized L2 block builders.
2. Bundling and Building: “Searchers” (who may be L1 or specialized L2 entities) bundle these L2 transactions. They construct an L2 block that maximizes revenue (MEV + fees).
3. The L1 Bid: These L2 bundles are offered to L1 Block Builders. The L1 builder treats the L2 block as just another transaction payload (a “blob” in EIP-4844 terms) with a high fee attached.
4. L1 Inclusion: The L1 builder includes the L2 bundle in their Ethereum block and bids for the right to propose the block.
5. Sequencing: The L1 Proposer (the Ethereum validator selected for the slot) proposes the block. Once the Ethereum block is finalized, the order of the L2 transactions inside it is canonical.19

Key Advantage: This architecture provides the Based Rollup with L1 Liveness. As long as Ethereum is producing blocks, the Based Rollup proceeds. It eliminates the risk of a centralized sequencer going offline or censoring transactions, as the censorship resistance is equivalent to that of the L1 validator set.3

3.3 The MEV Equation and Economic Alignment

A critical distinction in Based Rollups is the flow of Maximal Extractable Value (MEV). In centralized sequencer models, the rollup operator captures MEV (arbitrage, sandwiching, front-running). In a standard Based Rollup, this MEV naturally flows to the L1 Proposers.7

• Mechanism: L2 searchers bid for inclusion in L1 blocks. These bids (in ETH) go to the L1 block builder, who pays the L1 proposer. This effectively transfers the value generated on L2 directly to the L1 security budget.
• Implications:

• L1 Economic Alignment: This strengthens the economic security of the L1, as L1 validators are incentivized to service the rollup.
• L2 Revenue: The rollup retains revenue from L2 Base Fees (congestion fees), which can be burned or directed to a treasury. The rollup sacrifices execution MEV for security and simplicity.7

3.4 Case Study: Taiko (The Based Contestable Rollup)

Taiko is the most prominent implementation of the Based Rollup architecture. It utilizes a “Based sequencing” mechanism where anyone can propose a block to the L1 contract.

• Architecture: Taiko uses a “Based Contestable Rollup” (BCR) design. The L1 contract acts as the sequencer registry. Any L1 user can submit a block (acting as a proposer).
• Decentralization: Data analysis of Taiko’s mainnet shows that L1 proposers effectively become the sequencers, inheriting Ethereum’s decentralization. Unlike rollups with whitelisted provers/sequencers, Taiko allows permissionless participation.21
• Validity: Execution validity is handled via a multi-proof system (ZK + SGX), but the sequencing remains fully permissionless and L1-driven. This creates a clear separation: L1 controls ordering; L1 (via proofs) controls settlement.23

4. The Battle for Execution Control: Preconfirmations

A major limitation of “Vanilla” Based Rollups is latency. If sequencing relies on L1, the block time is bound by the L1 block time (12 seconds for Ethereum). This is unacceptable for modern user experience (UX) which demands sub-second feedback. To solve this, the concept of Based Preconfirmations (Preconfs) was introduced, creating a complex market for execution promises.

4.1 Based Preconfirmations Mechanism

Based Preconfirmations allow a subset of Ethereum validators to opt-in to becoming “Preconfers.” These entities promise to include a user’s transaction in the next block they propose, providing a cryptographic receipt (the preconfirmation) that guarantees execution before the L1 block is actually mined.24

The lifecycle of a Preconf Transaction involves:

1. Registration: L1 validators register as Preconfers via a smart contract, restaking collateral (e.g., via EigenLayer) to bond their honesty.27
2. Promise Issuance: A user interacts with the Preconfer for the upcoming slot. The user sends their transaction and a “Preconf Tip.” The Preconfer signs a promise to include the transaction in a specific order.
3. Forced Inclusion: If the Preconfer is the proposer for that slot, they prioritize the preconfirmed transaction. Mechanisms like Inclusion Lists (IL) are critical here, allowing validators to force inclusion of transactions into blocks built by others, preventing builders from censoring the preconfed transactions.28

4.2 Slashing Conditions: The Enforcement of Control

Who controls execution in a Preconf system? The Preconfer, but they are strictly bound by economic penalties. The system relies on two distinct slashing conditions 24:

1. Liveness Fault: The Preconfer fails to include the transaction in their designated slot.

• Nuance: Identifying liveness faults is difficult. A Preconfer might claim they never received the transaction, or that the network was congested. Accidental liveness faults are a major research area, requiring complex “fair exchange” protocols to ensure the Preconfer cannot be slashed for circumstances beyond their control.30

1. Safety Fault: The Preconfer includes the transaction but with a different outcome than promised (e.g., different ordering), or signs two conflicting preconfirmations (double-signing).

• Enforcement: This is objectively provable on-chain. If a Safety Fault is detected, the Preconfer’s staked collateral is slashed. This provides a hard economic guarantee to the user.27

This system creates a “Credible Promise” of future execution. It returns the sub-second user experience to Based Rollups while maintaining the decentralization of the L1 validator set. Effectively, it creates a “Shared Sequencer” composed dynamically of Ethereum validators.20

5. Comparative Analysis: Censorship, Finality, and Interoperability

To definitively answer “Who controls execution?”, we must dissect the layers of control across censorship resistance, settlement finality, and interoperability.

5.1 Censorship Resistance

• Sovereign Rollups: Censorship resistance is a function of the DA Layer’s permissionlessness. If the centralized sequencer of a Sovereign Rollup censors a user, the user can submit an “Inbox Transaction” directly to the DA layer (e.g., Celestia). The P2P nodes of the rollup are programmed to scan the DA layer for these forced transactions. If a forced transaction appears in a DA block, the nodes must execute it to remain in sync. Thus, the ultimate control over inclusion lies with the DA layer, not the rollup operator.11
• Based Rollups: Censorship resistance is inherited from the L1 Validator Set. Because there is no specific L2 sequencer, a user only needs one honest L1 proposer to pick up their transaction. In Ethereum, with thousands of validators, censorship is economically unfeasible for anything less than a 51% attack. The L1 Proposer controls the specific ordering of a block, but the aggregate L1 set controls the inevitability of inclusion.1

5.2 Settlement and Finality

• Sovereign Rollups: Finality is Subjective and Pessimistic. A transaction is effectively final when the DA block containing it is finalized and the user’s local node has successfully executed it. There is no “global” settlement layer that confirms validity to the world. A light client on another chain cannot easily verify the state of a Sovereign Rollup without running the execution logic itself (or verifying a ZK proof provided by the SR). This makes bridging complex, often requiring peer-to-peer bridge nodes.11
• Based Rollups: Finality is Objective and tied to L1 Finality. Once the L1 block containing the L2 bundle is finalized, and the validity proof (if applicable) is verified by the L1 contract, the state is globally final. Based Preconfirmations add a layer of “Soft Finality” (approx. 100ms) backed by economic stake, but “Hard Finality” remains tied to the 12-minute Ethereum epoch.20

5.3 Interoperability and Composability

• Based Rollups (Synchronous Composability): Because Based Rollups share the same sequencing layer (Ethereum L1), they can theoretically achieve Synchronous Composability. A single L1 transaction could interact with multiple Based Rollups in the same block, as the ordering is determined by the same Proposer. This allows for atomic swaps and shared liquidity pools across different L2s without complex bridges.21
• Sovereign Rollups (Asynchronous Bridging): Sovereign Rollups generally operate asynchronously. Interacting between two SRs (e.g., one on Celestia and one on Bitcoin) requires a bridge that locks assets on one chain and mints them on another. This introduces trust assumptions and latency, similar to the Cosmos IBC model. There is no shared sequencer to guarantee atomic execution across chains.2

6. Hybrid Architectures: The “Based Sovereign” Rollup

The analysis reveals that “Based” and “Sovereign” are not mutually exclusive. A rollup can utilize L1 for sequencing (Based) while rejecting the L1’s role in settlement (Sovereign). This hybrid model is gaining traction, particularly in the Bitcoin ecosystem.

6.1 The Based Sovereign Model

In a Based Sovereign Rollup, the rollup has no settlement smart contract on the L1. However, it requires L1 proposers/miners to include its data blobs in a specific order. The rollup nodes read the L1 block, extract the blobs, and execute them according to their own local fork-choice rule.34

• Liveness: Derived from the L1 (e.g., Bitcoin miners). No L2 sequencer can go offline.
• Validity: Derived from the Sovereign community. No L1 script limits the complexity of the L2.
• Example: Bitcoin Rollups: Many Bitcoin L2s function this way. They use Bitcoin’s Proof-of-Work to order “Inscription-like” data. The validation of this data happens off-chain in the L2 P2P network. Bitcoin provides the “Time” (ordering), while the L2 provides the “Space” (execution).17

6.2 The “Ultrasound” and “Gigagas” Variants

Emerging terminologies further nuance this landscape:

• Ultrasound Rollups: These are Based Rollups that utilize L1 for sequencing and maximize L1 alignment, potentially utilizing future L1 precompiles for validity verification. They aim to be indistinguishable from the L1 in terms of security properties.1
• Gigagas Rollups: These focus on maximizing throughput. They might use a Based Sequencing model to order huge blocks but utilize a specialized, high-performance VM (like SVM or Move) for execution. They might use a sovereign settlement model to avoid the high gas costs of verifying proofs on Ethereum, using the L1 only for cheap blob storage and ordering.1

7. Future Outlook: The Convergence of Alignment

The future of execution governance appears to be moving toward a spectrum rather than a binary choice.

7.1 The “Beam Chain” and Native Rollups

Research into the “Beam Chain” (a potential future upgrade to Ethereum’s consensus layer) suggests a move toward “Native Rollups” or “Enshrined Rollups.” In this model, the L1 itself would natively understand ZK proofs, blurring the line between Smart Contract Rollups and the L1. This would make Based Rollups the default standard for scaling Ethereum, effectively sharding execution while keeping consensus unified.37

7.2 The Role of Shared Sequencing

Shared Sequencers (like Espresso or Astria) represent a middle ground. They offer the “Based” benefit of decentralized sequencing to Sovereign Rollups. A Sovereign Rollup on Celestia might use a Shared Sequencer to order transactions, gaining preconfirmations and interoperability without being “Based” on the Celestia L1 itself.39

7.3 Conclusion: The Locus of Control

The question “Who controls execution?” yields two fundamentally different philosophies of blockchain scaling:

1. Sovereign Rollups posit that Users and Nodes should control execution. By removing the “enshrined” bridge, they revert to the original blockchain model where the chain with the most valid work (socially agreed upon) is the truth. This model prioritizes autonomy, flexibility, and easy forkability at the cost of fragmented liquidity and complex bridging. It is the “Internet of Blockchains” vision.
2. Based Rollups posit that The Base Layer (L1) should control execution ordering to guarantee liveness and decentralization. By outsourcing sequencing to the robust L1 validator set, they eliminate the “single point of failure” risk of centralized sequencers and align the L2’s economy with the L1. It is the “Global Supercomputer” vision.

Ultimately, Based Rollups represent the “Alignment” thesis—scaling Ethereum by becoming part of its economic and block-building circulatory system. Sovereign Rollups represent the “Modular” thesis—scaling the ecosystem by proliferating independent chains that treat Ethereum merely as a hard drive. The future of execution control will likely see a spectrum, with high-value DeFi gravitating toward the security of Based architectures, while gaming and social networks embrace the flexibility of Sovereign designs.

Key Takeaways

• Execution Control: Sovereign = Local Nodes; Based = L1 Proposers.
• Settlement: Sovereign = Client-side; Based = On-chain (typically).
• MEV: Sovereign = Internal capture; Based = Leaked to L1 (paying for security).
• Convergence: The “Based Sovereign” rollup represents the intersection, utilizing L1 for liveness (sequencing) but retaining local control over validity (settlement).

Detailed Technical Analysis

Section A: The Mechanics of Sovereignty

A.1 Data Availability as the Root of Truth

In Sovereign Rollups, the DA layer is the ultimate arbiter of what happened, but not what it means. This distinction is crucial.

• Mechanism: When a transaction is posted to Celestia or Bitcoin, it is immutable. A Sovereign Rollup node syncs by downloading all data from the rollup’s namespace.
• Validity: The node applies the State Transition Function (STF): State_N+1 = STF(State_N, Batch_N). If Batch_N contains an invalid transaction (e.g., signature mismatch), the STF simply outputs State_N (ignoring the batch) or Error. The L1/DA layer does not know or care that the batch was invalid; it only cares that the fees were paid to store the data.2
• Implication: This makes Sovereign Rollups immune to L1 smart contract bugs. If a smart contract rollup on Ethereum has a bug in its verifier contract, an attacker can steal funds, and the L1 will accept it as “valid.” In a Sovereign Rollup, the attacker might post the malicious transaction to the DA layer, but all honest nodes will reject it upon execution. The “hack” exists only on the attacker’s node.6

A.2 The Fork Choice Rule in Depth

The “Fork Choice Rule” is the algorithm used to select the canonical chain when multiple valid chains exist.

• L1 Dependency: In SCRs, the fork choice rule is: “Whichever chain the L1 smart contract says is the tip.”
• Sovereign Independence: In SRs, the fork choice rule might be: “The longest chain of valid blocks appearing in the DA layer.”
• Social Forking: If a major exploit occurs (e.g., a DAO hack), the community can coordinate off-chain to release a software update that blacklists the hacker’s transaction. This is a “Social Fork.” In an SCR, this would require upgrading the L1 smart contract, which might require a multisig key or a long governance delay. In an SR, it happens as fast as users update their software.1

Section B: The Mechanics of Alignment (Based)

B.1 Reusing the Builder Pipeline

Based Rollups are technically simpler than centralized sequencer rollups because they remove the need for a separate consensus mechanism or Leader Election protocol on L2.3

• Simplicity: There is no “Sequencer Rotator” or “Proof of Authority” ring. The “Leader” is whoever the Ethereum Leader is.
• Gas Overhead: Based sequencing often results in zero gas overhead for signature verification of sequencers, as the “signature” is implicitly the inclusion in the L1 block.19

B.2 Preconfirmation Economics

The introduction of Preconfirmations transforms the Based Rollup from a passive system to an active marketplace.

• Delegation: An L1 proposer might not have the technical capacity to sequence L2 transactions optimally. They can delegate this right to a specialized “Preconfer” or “Sequencing Delegate” in exchange for a fee. This mirrors the Proposer-Builder Separation on L1.24
• Fair Exchange: Users pay a premium (Preconf Tip) for the guarantee of inclusion. This creates a new revenue stream for L1 validators, further cementing the alignment between L1 and L2.41
• Inclusion Lists (IL): To prevent a malicious Preconfer from monopolizing the slot, the L1 proposer can utilize Inclusion Lists to force specific transactions into the block, ensuring censorship resistance even against the delegated sequencer.29

Section C: Future Outlook

The industry is moving toward a spectrum of “Modularity” where the lines blur.

• Taiko’s Roadmap: Taiko aims to implement “Based Contestable Rollups,” combining the liveness of based sequencing with the safety of multi-proofs (ZK + SGX). This hybrid approach maximizes both alignment and security.21
• Bitcoin as DA: As Bitcoin introduces opcodes like OP_CAT or utilizes Taproot Wizards’ techniques, we will see a surge of Sovereign Rollups on Bitcoin. These will effectively be “Based Sovereign” rollups—using Bitcoin Proof-of-Work for ordering (Based) but client-side validation for execution (Sovereign).17

The definitive answer to “Who controls execution?” depends on the architecture chosen:

• Sovereign: The Code (Client) + The Community.
• Based: The Base Layer (Validators) + The Market (Builders/Searchers)