Shared Sequencer

What Is a Shared Sequencer?

A shared sequencer is a decentralized infrastructure layer that provides transaction ordering services for multiple rollups at the same time. Instead of each rollup running its own centralized sequencer (a single operator that decides the order of transactions), a shared sequencer distributes this responsibility across a network of validators who collectively reach consensus on a global transaction order.

The concept emerged from a core problem in the rollup ecosystem: fragmentation. As dozens of rollups launched on Ethereum, each operated its own isolated sequencer. This meant no rollup could natively interact with another. Users wanting to move assets or execute logic across rollups had to rely on bridges, introducing delay, cost, and trust assumptions. Shared sequencing aims to reconnect these isolated execution environments by giving them a common transaction ordering layer.

Think of it like a shared postal sorting facility. Instead of every town running its own post office that only handles local mail, a regional sorting center processes mail for all towns. It can efficiently route letters between towns and guarantee that a package sent from Town A arrives at Town B at the same time Town B's reply reaches Town A.

The Centralized Sequencer Problem

To understand why shared sequencers matter, it helps to understand what they replace. Today, major Layer 2 rollups like Arbitrum, Base, OP Mainnet, zkSync Era, and Scroll all run centralized sequencers operated by a single entity.

This creates several risks:

• Censorship: a single operator can exclude or delay specific transactions. In June 2024, Linea paused its sequencer entirely and censored specific addresses during a security incident, demonstrating this power in practice.
• Single point of failure: if the centralized sequencer goes offline, the entire rollup halts. Users cannot submit transactions until the operator restores service.
• MEV extraction: a centralized sequencer can reorder transactions for profit through front-running and sandwich attacks, disadvantaging ordinary users.
• No cross-rollup atomicity: because each rollup orders transactions independently, there is no way to guarantee that a transaction on Rollup A and a related transaction on Rollup B execute together or not at all.

Rollup teams initially chose centralized sequencers for practical reasons: using Ethereum L1 directly for sequencing cannot handle L2 transaction volume, and L1 latency would negate the user-experience benefits that rollups provide. Speed and cost were prioritized over decentralization.

How It Works

A shared sequencer sits between users and the rollups they interact with. Its architecture typically consists of three layers:

1. Transaction submission: users and applications submit transactions to the shared sequencer network via standard APIs (JSON-RPC or custom protocols). Transactions are tagged with the target rollup.
2. Consensus and ordering: a decentralized set of validators runs a Byzantine Fault Tolerant (BFT) consensus protocol to agree on a single, deterministic ordering of all incoming transactions across all connected rollups.
3. Delivery and data availability: the ordered transaction batches are published to a data availability layer and delivered to each rollup. Each rollup reads its relevant subset and independently executes state transitions.

Atomic Cross-Rollup Bundles

The key capability that shared sequencing enables is conditional transaction inclusion across rollups. Users can specify all-or-nothing bundles: "include transaction A on Rollup 1 if and only if transaction B on Rollup 2 is also included in the same block."

The shared sequencer enforces this atomicity at the ordering layer. If either transaction cannot be included, neither is. This is a prerequisite for true cross-rollup composability: a smart contract on one rollup triggering logic on another without bridge delays or intermediaries.

A simplified flow for an atomic cross-rollup swap:

// User wants to atomically swap tokens across two rollups
// 1. User submits a bundle to the shared sequencer:
Bundle {
  tx_a: { rollup: "rollup-1", action: "lock 100 USDC" },
  tx_b: { rollup: "rollup-2", action: "release 100 USDC" },
  constraint: "atomic"  // both execute or neither does
}

// 2. Shared sequencer validators reach consensus on ordering
// 3. Both transactions are included in the same sequenced block
// 4. Each rollup executes its respective transaction
// 5. If either fails during execution, both are reverted

It is important to note a limitation: atomic inclusion does not guarantee atomic execution. Even if both transactions are included in the same block, one could still fail during execution (for example, due to insufficient balance). Research has shown that atomic execution requires additional guarantees beyond what ordering alone provides.

Consensus Mechanisms

Different shared sequencer projects use different consensus approaches:

• Espresso Systems uses HotShot, a custom proof-of-stake BFT protocol with permissionless validator participation and security bootstrapped through EigenLayer restaking.
• Radius uses Practical Verifiable Delay Encryption (PVDE), a zero-knowledge cryptographic approach that encrypts transactions until execution, preventing sequencers from extracting MEV before ordering is finalized.
• NodeKit SEQ is building a shared sequencer L1 on the Avalanche HyperSDK toolkit, leveraging Avalanche's sub-second consensus.

Active Projects

Shared sequencing is still an emerging field. As of mid-2026, the landscape includes both operational networks and cautionary tales:

Espresso is the most mature project, having raised $28M in Series A funding led by a16z. Its Mainnet 1 publishes sequencing confirmations for chains including ApeChain, Celo, and Arbitrum ecosystem rollups, with fully permissionless Mainnet targeted for late 2026.

Astria's shutdown in December 2025 (at block 15,360,577, after roughly one year of mainnet operation) illustrates the economic and adoption challenges. Even with $18M in funding, sustaining a shared sequencer network proved difficult without sufficient rollup adoption to generate sustainable fee revenue.

Economic Model

Shared sequencers generate revenue from two primary sources: transaction inclusion fees paid by users and MEV captured during the ordering process.

• Sequencing fees: rollups pay the shared sequencer network for ordering services, similar to how they pay Ethereum L1 for data availability. Costs are distributed across all connected rollups, creating economies of scale.
• MEV redistribution: rather than a single centralized sequencer capturing all MEV, shared sequencers can use proposer-builder separation mechanisms to auction ordering rights and distribute MEV revenue among validators, rollups, and potentially users.

The economic challenge is bootstrapping: a shared sequencer needs enough rollups to generate meaningful revenue, but rollups are reluctant to adopt unproven infrastructure. This chicken-and-egg problem contributed to Astria's difficulties.

Use Cases

Cross-Rollup DeFi

Today, liquidity is fragmented across rollups. A DEX on Arbitrum cannot natively access liquidity on Optimism. Shared sequencing could enable unified order books and liquidity pools spanning multiple rollups, with atomic settlement guarantees.

Rollup Ecosystems

The Optimism Superchain (a network of interoperable OP Stack rollups) plans to use shared sequencing across all member chains. This would allow applications on any Superchain rollup to compose with applications on any other, treating the ecosystem as a single execution environment rather than isolated chains.

New Rollup Bootstrapping

Launching a new rollup traditionally requires building or configuring a sequencer, attracting operators, and establishing liveness guarantees. A shared sequencer removes this overhead: new rollups can plug into an existing sequencing network and inherit its security and decentralization properties from day one.

MEV Mitigation

By using encrypted mempools or fair-ordering protocols, shared sequencers can reduce harmful MEV extraction. Radius's PVDE approach encrypts transactions until execution, preventing sequencers from seeing transaction contents and eliminating front-running at the ordering layer.

Why It Matters

Shared sequencing addresses the blockchain trilemma at the rollup layer. Rollups already provide scalability, but most sacrifice decentralization by relying on centralized sequencers. Shared sequencers aim to restore that decentralization without sacrificing the performance benefits that rollups provide.

For the broader modular blockchain thesis, shared sequencing is a missing piece. A modular blockchain stack separates execution, data availability, consensus, and settlement into specialized layers. Shared sequencers fill the consensus and ordering role, allowing rollups to focus purely on execution.

The challenges in rollup sequencing parallel issues in the Bitcoin Layer 2 space. Bitcoin L2 networks like those built with BitVM2 face similar questions around operator networks and transaction ordering. Projects in the Bitcoin L2 ecosystem use intermediary operator networks to process deposits and withdrawals, with multiple operators monitoring each other under honest-minority assumptions. As the Bitcoin Layer 2 landscape evolves, shared sequencing concepts may extend to Bitcoin-based rollups as well, though Bitcoin L2 operator networks currently focus more on bridging and settlement than on transaction ordering.

Alternative Approaches

Shared sequencing is not the only path to decentralized rollup ordering. Two notable alternatives have emerged:

• Based sequencing: rollups inherit sequencing directly from L1 validators. Transactions are ordered by Ethereum block proposers, inheriting Ethereum's full decentralization. The tradeoff is higher latency (L1 block times) and less flexibility in ordering rules.
• TEE-based sequencing: trusted execution environments provide ordering guarantees through hardware-level isolation. This offers lower latency than BFT consensus but introduces hardware trust assumptions.

Each approach makes different tradeoffs between latency, decentralization, trust assumptions, and implementation complexity. The rollup ecosystem may ultimately use a mix of all three depending on application requirements.

Risks and Considerations

Correlated Failure

If many rollups depend on a single shared sequencer, a failure in that sequencer affects all connected rollups simultaneously. This creates systemic risk: instead of isolated rollup outages, a shared sequencer failure could halt an entire ecosystem of chains.

Latency Overhead

BFT consensus protocols add latency compared to centralized sequencers that achieve near-instant ordering. A centralized sequencer can order transactions in milliseconds, while BFT consensus among distributed validators requires multiple rounds of communication. For latency-sensitive applications like high-frequency trading, this tradeoff may be unacceptable.

Cross-Domain MEV

While shared sequencers can mitigate some forms of MEV, they also create a new chokepoint for cross-domain MEV extraction. A shared sequencer that sees transactions across multiple rollups has a privileged view of cross-rollup arbitrage opportunities. Research has identified this as a fundamental game-theoretic problem, not merely a technical one.

Adoption Challenges

Rollup teams have limited incentive to adopt shared sequencing in its current state. A centralized sequencer gives the rollup operator full control over ordering, revenue, and uptime. Ceding this control to an external network requires strong trust in the shared sequencer's reliability and economic alignment. Astria's shutdown demonstrates that even well-funded projects can fail to achieve the adoption needed for sustainability.

Trust Assumption Shift

Shared sequencing does not eliminate trust: it shifts it. Instead of trusting a single centralized operator (who is typically the rollup team itself), users must trust a distributed network of validators with its own consensus rules, economic incentives, and potential failure modes. Whether this tradeoff improves security depends on the specific implementation and the quality of its validator set.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.