Shared Sequencing: Decentralizing MEV for Rollups in 2026

By DeFi Intel Research · Reviewed 2026-07-02 · 10 min read · advanced

Shared sequencing Ethereum is the architectural shift from single-sequencer rollups to decentralized ordering layers that mitigate MEV centralization risks and remove single points of failure. By distributing the right to order transactions among a permissionless or semi-permissioned committee, rollups can achieve both scalability and credible neutrality. Over the past two years, projects like Espresso Systems, Astria, and Radius have pioneered designs that reduce extractable value for any single participant while preserving low latency—the critical requirement for user experience.

This guide dissects the core mechanisms of shared sequencing, comparing consensus-based, threshold-encrypted, and shared-API approaches. We examine how each design handles MEV, its trust assumptions, and the trade-offs that protocol designers must balance. Whether you are a rollup builder evaluating sequencing options or a DeFi protocol assessing cross-rollup composability, understanding these trade-offs is essential for navigating the 2026 Ethereum scalability landscape.

The MEV Centralization Problem in Single-Sequencer Rollups

In a single-sequencer rollup, one entity (e.g., Arbitrum Sequencer or OP Mainnet Sequencer) controls transaction ordering entirely. This sequencer can reorder, censor, or front-run transactions, capturing MEV that would otherwise be distributed among users. While some rollups implement economic slashing for misbehavior (e.g., decentralized validators in Arbitrum’s future roadmap), the sequencer remains a central point of trust for liveness and fairness. A single centralized sequencer that captures ordering rents represents a lucrative single point of control – a honeypot. Shared sequencing disperses that power to a committee, making collusion necessary to extract MEV and dramatically raising the cost of attack.

What Is Shared Sequencing? The Core Mechanism

Shared sequencing collects transactions from one or multiple rollups, runs them through a decentralized ordering protocol, and produces a canonical sequence committed to the rollup’s bridge contract on Ethereum. The sequencing committee does not execute the transactions—it only orders them. Execution remains on the rollup (either via a single executor or decentralized proving). By decoupling ordering from execution, shared sequencing introduces a sequencing layer that can be (a) permissionless (any node can join) or (b) semi-permissioned (governed by a fixed set of operators). Key properties include: independence from any single sequencer, transparent ordering, and the ability to enforce inclusion lists or fair ordering constraints.

“Shared sequencing does not eliminate MEV entirely—it democratizes access to ordering opportunities and makes extraction observable and challengeable.”

Protocols in this space include: Espresso (uses a consensus-based ordering committee with byzantine fault tolerance), Radius (employs threshold-encrypted mempool to prevent front-running), and Astria (offers a CometBFT-based shared ordering service that rollups can integrate via a single endpoint).

Architectural Comparison: Consensus, Threshold Encryption, and Shared API

Three dominant architectures have emerged:

• Consensus-Based (e.g., Espresso): A BFT committee reaches agreement on transaction order (e.g., HotStuff, CometBFT). Transactions are revealed before ordering, so MEV is observable but ordering is deterministic. Mitigation: fair ordering (e.g., ordering by arrival time in public mempool) and inclusion lists force the proposer to include specific transactions.
• Threshold-Encrypted (e.g., Radius): Transactions are encrypted using a distributed key generation (DKG) scheme; only after ordering can the committee jointly decrypt them. This hides transaction contents until they are sequenced, preventing front-running and searcher perversion. Latency is higher due to encryption/decryption rounds.
• Shared Ordering API (e.g., Astria): A shared ordering service collects from all rollups, orders them via its consensus, and returns a canonical sequence. Trust is placed in the API operator’s code correctness, but the operator cannot reorder—only delay or censor. This is the simplest to integrate but retains some trust assumptions.

These approaches represent different points on the spectrum of trust minimization versus performance, with threshold encryption offering the highest resistance to MEV but lower throughput, and consensus-based providing a middle ground with well-understood trade-offs.

How Shared Sequencing Mitigates MEV: Fair Ordering, Inclusion Lists, and Separation of Roles

MEV mitigation in shared sequencing rests on three pillars:

• Fair Ordering: The sequencing protocol commits to a notion of fairness—e.g., ordering by submission time (first-come-first-serve) or by a verifiable delay function (VDF) that prevents time-manipulation. Espresso’s Fair Ordering specification uses a global clock and ephemeral ordering rounds.
• Inclusion Lists: Each proposer can be forced to include transactions that meet certain criteria (e.g., paid sufficient fees). This prevents outright censorship. The committee can verify that the proposer’s block includes all required transactions.
• Separation of Proposer and Executor: Shared sequencing layers can assign ordering rights to a different entity than the execution layer’s sequencer. This ensures that the sequencer/executor cannot both order and execute, breaking the chain of MEV extraction.

For example, in Espresso’s design, the ordering committee produces a sequence that is later executed by rollup-specific executors. If the executor attempts to reorder or censor, the bridge contract can detect that the execution does not match the globally agreed ordering and reject it. Similarly, Radius’s threshold encryption ensures that even the ordering committee cannot see transaction payloads until after ordering, preventing any MEV from being extracted based on transaction order.

Trust Assumptions: From Single Sequencer to Decentralized Committee

*Some rollups implement sequencer bonds with slashing for liveness failures, but reordering remains unconstrained.

Note that both consensus and threshold-encrypted approaches reduce trust to an honest majority of the committee (by stake or reputation). The key difference is that threshold encryption adds an extra layer of privacy, preventing even the committee from seeing tx contents until after ordering, which completely removes the ability to front-run or back-run based on transaction types. However, it also increases latency and system complexity due to the necessary decryption rounds.

Protocol Design Choices: Tokenomics, Permissioning, and Finality

Designers of shared sequencing layers must make several foundational choices:

• Sequencing Tokenomics: Should sequencing rights be auctioned, staked, or earned via block rewards? Espresso uses a native token staked by sequencing nodes; misbehavior results in slashing. Astria plans a similar model with an additional fee market for decryption requests. The token captures value from ordering activity but introduces regulatory complexity.
• Permissionlessness vs Permissioned: Fully permissionless sequencing (any node can join by staking) maximizes decentralization but may suffer from low participation and high latency. Permissioned committees (whitelisted operators) can achieve lower latency and better throughput but centralize power. Many protocols opt for a semi-permissioned model with high staking thresholds (e.g., 1,000,000 tokens) to ensure quality operators.
• Finality Guarantees: Shared sequencing layers can offer economic finality (after N blocks with cumulative stake) or instant finality via BFT consensus. Economic finality is common in consensus-based approaches (e.g., Espresso’s HotStuff-based consensus targets fast finality). Threshold-encrypted approaches often have slower finality due to encryption/decryption phases.

For rollups considering integration, these choices directly affect latency, cost, and the ability to support atomic cross-rollup composability. For instance, a DeFi application requiring near-instant settlement may prefer a fast finality consensus-based shared sequencer, while a privacy-sensitive DEX may opt for threshold encryption even at higher latency.

Cross-Rollup Composability and Liquidity Fragmentation

One of the most touted benefits of shared sequencing is enabling atomic cross-rollup transactions. When all participating rollups share the same sequencing layer, the order of transactions across rollups is globally consistent. This allows, for example, a borrow on Rollup A and a deposit on Rollup B to be executed in the same block with exactly-once semantics, effectively creating a synchronized state machine across rollups. Cross-rollup claims and yield routing become trustless, significantly reducing liquidity fragmentation.

Concrete implementations: Espresso’s Rollup Continuum and Astria’s Shared Sequencer both support atomic inclusion proofs. However, true atomic composition requires that all rollups also share the same execution environment (e.g., all EVM), which is not required by the sequencing layer alone. In practice, composability across different execution layers (e.g., EVM and MoveVM) still needs bridging and proof verification. Shared sequencing reduces the ordering trust barrier but does not solve cross-proving entirely. Some projects are exploring multi-VM sequencing, but production solutions remain early.

Rollups that join a shared sequencing network can also benefit from liquidity aggregation: a user can send assets through the sequencing layer to any other rollup atomically, eliminating the need for multiple bridge hops. This is a major reason why RaaS providers (e.g., Caldera, Conduit) have started integrating shared sequencing into their stack.

Challenges: Latency, Oracle Synchronization, and Forced Inclusion

Despite progress, shared sequencing introduces new challenges:

• Latency: Decentralized ordering inherently imposes more rounds of communication than a single sequencer. Consensus-based shared sequencers achieve 1-2 second block times through optimistic protocols and parallelized consensus, but threshold-encrypted systems can add 3-5 seconds for decryption. For latency-sensitive use cases (e.g., order book DEXes, high-frequency trading), this may be unacceptable.
• Oracle Synchronization: Many DeFi protocols rely on off-chain oracles for price feeds. If the sequencing layer does not guarantee the same ordering as a single sequencer, oracle updates may be vulnerable to misordering. Shared sequencing committees can integrate a dedicated oracle ordering protocol, but this adds complexity.
• Forced Inclusion and Censorship Resistance: A fundamental design goal is preventing censorship by the sequencing committee. Inclusion lists are a robust mechanism, but they require that all users can submit transactions to a public mempool. In permissioned shared sequencers, the committee could still collude to delay or ignore inclusion list updates. Solutions like forced transaction inclusion can be mapped to the shared sequencing layer, giving users a timeout-based fallback to submit directly to the rollup’s bridge contract on Ethereum.

For example, a user in Radius’s threshold-encrypted system must wait until the decryption phase for their transaction to be visible; if the committee refuses to decrypt, the user cannot prove censorship. Radius mitigates this with on-chain dispute games similar to optimistic rollups, but at the cost of delay.

The 2026 Landscape: Upcoming Improvements and Research Directions

By 2026, shared sequencing is expected to reach production stability across multiple rollup ecosystems. Key research directions include:

• MEV redistribution back to users: Shared sequencing layers can enforce a minimum allowed miner extractable value (MEV) burn, returning value to users via fee reductions or direct revenue sharing. Some designs price the cost of ordering with user fees while distributing surplus back to users.
• Incentive alignment with base layer: Using Ethereum’s own validator set for shared sequencing (via restaking) could eliminate the need for a separate token and bootstrap security from Ethereum’s value. EigenLayer’s active validation services (AVS) already enable this – shared sequencing is one of the first proposed AVS use cases.
• Multi-execution-layer rollups: e.g., a shared sequencer that orders transactions for both an EVM rollup and a SVM rollup atomically. This requires the sequencing layer to understand transaction dependencies across execution contexts, a problem being studied by researchers at projects like Taiko.

Infrastructure providers like Caldera and Conduit are already offering shared sequencing as a service, enabling rollups to launch with decentralized ordering from day one. The next frontier is achieving sub-second finality through advanced consensus protocols (e.g., Jolteon, Narwhal) without compromising security.

Conclusion: Preparing for Decentralized Sequencing

Shared sequencing is not a panacea for all rollup centralization concerns, but it is the most concrete step toward aligning rollup architecture with Ethereum’s credibly neutral ethos. By distributing ordering power and making MEV observable, it reduces the risk of censorship and extractive behavior that plague single-sequencer systems. The design space—spanning consensus threshold encryption, inclusion lists, and tokenomics—is rich with trade-offs that protocol designers must carefully evaluate based on their rollup’s latency and privacy requirements.

For developers, the time to integrate shared sequencing is now. Start by evaluating which architecture suits your rollup’s trust profile: Espresso for low-latency, high-throughput; Radius for strong MEV protection; Astria for simple integration. For researchers, open problems around cross-execution composability and economic security remain rewarding. As Ethereum evolves to support a rollup-centric roadmap, shared sequencing will become the standard layer for order fairness and decentralization.

Common mistakes to avoid

• Assuming shared sequencing eliminates all MEV – it only democratizes ordering opportunities and makes extraction observable.
• Ignoring the trust assumptions of the sequencing committee (e.g., assuming permissionless = trustless; committee still controls ordering).
• Overlooking latency trade-offs – threshold encryption increases block time, which may break latency-sensitive applications.
• Treating shared sequencing as a replacement for rollup-level execution decentralization (e.g., still need a decentralized prover/validator set).
• Neglecting forced inclusion mechanisms – without them, a colluding committee could censor transactions indefinitely.
• Confusing cross-rollup composability with atomic composability – shared sequencing orders across rollups but does not guarantee identical execution environment.

Frequently asked questions

Related reading

• Ethereum Layer 2 Networks
• Rollup
• ZK Rollup
• Ai Crypto Decentralized Ai
• Central Bank Digital Currencies CBDC
• Eigenlayer Restaking
• Filecoin Fil Decentralized Storage
• Helium DEPIN Decentralized Physical Infrastructure