Co-authored by Lorenzo and Kubi from Gattaca. Special thanks to Justin, Drew, Jason, Ladi, Connor, Liam, Sam B, Matthew, Lin, Brecht, Can, Thanh, Kevin and Sam J for their feedback and suggestions. Feedback is not necessarily an endorsement.
Prerequisite: This article assumes familiarity with concepts such as: based rollups, preconfirmations and PBS
Setting the Context
This article provides a practical roadmap for rollups currently operating a centralised sequencer at scale to progressively transition into based rollups.
To demonstrate how this transition can be achieved, the article first outlines a design for based sequencing, followed by an explanation of how parts of the design can be gradually adopted to enable the transition.
While several approaches have been proposed to leverage L1 proposers for sequencing services, such as free-for-all (total anarchy) and vanilla based sequencing, the design outlined in this article builds on an approach where L1 proposers delegate sequencing rights to specialised 3rd parties called gateways. This concept was initially discussed in “Based Preconfirmations” and “Vanilla Based Sequencing”, and seeks to avoid overloading validators.
The outlined design also incorporates ongoing standardisation efforts around based preconfirmations and assumes the existence of an open-source public-good “sidecar” that enables opt-in delegation. It further leverages existing low-latency Proposer-Builder Separation (PBS) infrastructure for efficient L1 inclusion and settlement of batches. Together, these elements enable rollups to adopt based sequencing immediately, without the need for L1 protocol-level changes or hard forks.
Finally, some of the mechanics were inspired by collaborative efforts with teams such as Taiko, Puffer UniFi , Rise, Spire and many others.
TLDR
- Rollups can progressively decentralise and become based rollups by replacing their centralised sequencer with the most credibly neutral actors: the L1 validator set.
- This transition can occur in phases, enabling a gradual and robust path towards decentralisation.
- A practical first step would be to overlay preconfirmations - guarantees from the sequencer before an L2 block is published - on centralised sequencing. This can provide close to ping-latency UX and maintains forward-compatibility with permissionless based sequencing.
- By becoming based, rollups achieve stronger alignment with Ethereum. Moreover, by adopting a delegation model involving gateways in a competitive marketplace, they can also unlock significant performance improvements in throughput and processing speed.
- Mechanisms such as preconfirmations and pipelining block construction enable execution proofs on the order of tens of milliseconds.
- Rollups can adopt a pragmatic, incremental, three-phase approach to decentralisation, improving sequencer resilience and performance at each step. This is especially important for large-scale rollup operators managing ecosystems with substantial TVL and user bases, as it offers tangible incentives to adopt based sequencing while mitigating the risks of a major systemic overhaul.
How this Article is structured
We begin with a Background discussion, examining the state of rollups and the challenges posed by centralised sequencers. Next, we highlight the Key Benefits of Based Sequencing, outlining how the Ethereum L1 proposer set can offer stronger resilience, composability, and economic security when sequencing rollups.
We then define Terminology to ensure clarity when discussing the key roles and mechanics of our proposed design. After that, we present a Based Sequencing Design Using Delegation, outlining the technical details and core mechanisms that form the foundation for a gradual adoption roadmap.
Finally, in Becoming Based, we provide a three-phase roadmap showing how rollup operators can progressively adopt parts of the proposed design to transition from a centralised sequencer model to fully permissionless based sequencing. After describing potential Risks, including centralisation concerns and UX variations, we conclude with Further Considerations, identifying areas that call for ongoing research and refinement.
Background
Current state of rollups:
- Users currently enjoy an excellent UX, enabled by preconfirmations issued with low latency by centralised sequencers.
- By holding the exclusive right to sequence and batch transactions, centralised sequencers can give guarantees about the execution of these transactions.
- Rollups avoid the overhead of consensus mechanisms, unlocking a design space that can achieve exceptionally high levels of performance and throughput. Currently, most rollups rely on centralised sequencers that operate solely on a trust basis, raising concerns about censorship resistance and liveness. While some rollups include an “escape hatch” mechanism, it often comes at the cost of degraded user experience due to significant delays.
Why Based sequencing can improve rollups:
- Based sequencing enables Ethereum L1 proposers, the most decentralised and credibly neutral set of actors, to provide sequencing services for rollups. This enables shared sequencing across multiple rollups and, in turn, synchronous composability across the rollups and between the rollups and L1.
- Preconfirmations backed by economic guarantees can mitigate the delays caused by long L1 slot times. This ensures L2 users maintain an excellent UX while benefiting from enhanced economic security and mitigate risks such as liveness failures or regulatory challenges posed by centralised sequencers.
The importance of delegation:
- For based sequencing to fully leverage the L1 proposer set, all proposers, including solo stakers, must be able to opt in and participate. Inclusivity ensures equitable access to yield, which is critical for maintaining decentralisation of the L1 proposer set. In alignment with PBS and research such as APS, the research efforts around based sequencing have generally introduced a role referred to as a “Gateway.”
- Gateways, staked third-party entities providing specialised sequencing services, will be available to proposers lacking bandwidth and technical capacity to support high-throughput rollups. Gateways are held accountable through strict performance monitoring and are subject to slashing conditions, ensuring reliability and alignment with the network’s security guarantees. Nonetheless, delegating sequencing services to gateways introduces additional risks, which are discussed later in this article.
We strongly believe that, with a robust mechanism design, based sequencing should become the default choice for rollups. It leverages Ethereum’s economic security, reliability, and neutrality. Moreover, in based sequencing designs that adopt a delegation model and foster a competitive market among specialised gateways, rollups can achieve superior performance enabling them to meet the high-throughput demands users expect.
Key Benefits of Based Sequencing
- High Performance with Decentralised Sequencing: Optimised block pipelining and efficient gossiping enable execution preconfirmations within just a few milliseconds. This level of performance has been demonstrated with pipelined sequencers, achieving 300,000 transactions per second, or approximately 6 gigagas per second on a consumer-grade laptop using a single core for sequencing.
- Enhanced Liveness and Resilience through Decentralisation: Sequencing becomes significantly more robust and fault-tolerant with multiple gateways, compared to reliance on a single centralised sequencer. The system can automatically recover from temporary liveness failures, ensuring continuous operation without the need for manual intervention.
- Retention of Control over MEV and Priority Fees: Rollup operators maintain full control over sequencing rules, MEV management, and fee attribution. This flexibility allows operators to fine-tune incentives and penalties to meet specific performance and economic goals.
- Alignment with Ethereum L1: Based sequencing leverages the Ethereum L1 proposer set as watchdogs to enhance security, ensure credible neutrality, and enable seamless composability with Ethereum L1.
- A Scalable Ecosystem of Rollups: Based sequencing provides a realistic and scalable path to synchronous composability with Ethereum L1, laying the foundation for a seamlessly interconnected ecosystem of rollups.
| Centralised Sequencing | Based Sequencing | |
|---|---|---|
| Performance |  Excellent |
Excellent - Gateways |
| Liveness |  Single Point of Failure |
Excellent - L1 proposers + Gateways |
| Economic Security |  None |
Excellent - Staked Proposers + Gateways |
| Real-time Censorship Resistance | Single Point of Failure |
Excellent - L1 proposers |
| Composability | Limited |
Excellent - Synchronous |
Terminology
- Gateway: The entity responsible for issuing preconfirmations and sequencing the L2. Sophisticated L1 proposers may choose to operate their own gateways, while others can delegate sequencing responsibilities to third-party operators. For simplicity, we refer to all sequencing entities as gateways, with the understanding that proposers may self-delegate.
- Nodes: Non-sequencing follower nodes that track the tip of the chain by listening to sequenced transaction batches. These nodes are essential for tasks such as submitting fraud proofs, indexing, handling RPC calls, and supporting other off-chain services.
- Lookahead: A mapping from L1 slots to gateway identities, establishing the leader schedule for sequencers.
- Inbox Contract: An L1 contract where transaction batches from the L2 are posted.
- Frags: Fragments of a block that the leader shares with follower nodes before the block is fully constructed. This concept is similar to shreds in Solana and has been frequently discussed in Sequencing and Preconfirmations calls (eg #13).
Confirmation Levels for a given L2 Transaction
We define three levels of confirmation:
- Preconfirmed: The transaction is sequenced by a gateway, and an execution receipt is available to the user.
- Included: The transaction is included in an L2 block.
- Finalised: The L2 block containing the transaction has been batched and included in an L1 block.
Note: Even after being finalised, the L1 block may still be subject to reorgs, however reorging L2 blocks can be avoided by chaining preconfirmations.
Based sequencing design using delegation
The lookahead (as shown in the table below) serves as a leader schedule for sequencers, mapping L1 slot numbers to leader gateways. These gateways act as sequencers with exclusive rights to advance the L2 state during their assigned slots. Slot assignments are determined by L1 proposers who opt in to become sequencers, granting them sequencing rights during their respective L1 slot durations. If no L1 proposer has opted in for one or more slots, the sequencing rights for those slots are assigned to the next available proposer who has opted in.
| Gateway | L1 Slots |
|---|---|
| Gateway A | 100-102 |
| Gateway B | 103-105 |
| Gateway C | 106-108 |
Alternative methods for establishing a gateway schedule may also be considered. The assignment could take into account factors such as the proportional stake delegated to each gateway by L1 proposers to ensure fair representation across the proposer set. To further promote decentralisation and prevent monopolisation, a hard upper limit could be imposed on the number of consecutive slots a single gateway is allowed to sequence.
Finally, the inbox contract enforces this schedule by accepting transaction batches only from the designated gateway leader for each slot, as defined by the lookahead.
Gateway and Node Connectivity
Gateways and nodes communicate via a fast, leader-aware peer-to-peer (p2p) gossip network, inspired by the Solana Turbine block propagation. This network plays a critical role in maintaining efficient and reliable communication and serves two primary purposes:
- Inbound Gossip: Transactions are relayed from nodes to the current gateway leader for sequencing.
- Outbound Gossip: The gateway leader distributes sequenced transaction batches back to nodes and the next leader in the lookahead schedule.
Users can send transactions directly to the current gateway leader or to any node, which then forwards transactions received via Inbound Gossip. The leader sequences these transactions and distributes the resulting frags via Outbound Gossip through the p2p network. It is important to note that these frags are signed (committed to) by the gateway leader. This streamlined block construction process allows nodes to begin rebuilding the current block immediately, rather than waiting for the entire block to be finalised, as is the case in Ethereum today.
struct Frag {
// Block in which this frag will be included
block_number: u64,
// Index of this frag. Frags need to be applied sequentially by index
seq: u64,
// Whether this is the last frag in the sequence
is_last: bool,
// Ordered list of EIP-2718 encoded transactions
txs: Transactions,
}
As peer nodes receive batches, they optimistically construct a local TempBlock and provide preconfirmations (execution receipts) to users. This is possible because nodes validate batches based on the current lookahead and the latest L2 block number posted on the L1, rejecting any batches not signed by the current leader.
Nodes also monitor the sequencing performance and responsiveness of the gateway leader. If a node misses any sequential batches, it can request the missing data from other nodes within the p2p network.
New Nodes can join the network permissionlessly and independently reconstruct the gateway schedule by reading the lookahead data directly from the L1. This ensures that the network remains open and transparent, eliminating reliance on centralised RPC providers to issue preconfirmations. To support off-chain components such as wallets, indexers, and other services, nodes also expose a standard JSON-RPC API, enabling seamless integration and compatibility with existing infrastructure.
The size and frequency of frags can be adjusted by the rollup operator, balancing trade-offs between performance, hardware requirements and throughput. At the limit, where frags contain a single transaction and are streamed continuously, a user connected directly to the gateway leader can receive an execution preconfirmation within just a few milliseconds. This efficiency is achievable because L2s inherit security guarantees from the L1, removing the need for additional consensus overhead.
Periodically, the gateway leader broadcasts a block seal, consolidating a set of frags into a single L2 block, thereby advancing the tip of the chain.
struct Seal {
// How many frags for this block were in this sequence
total_frags: u64,
// Header fields
block_number: u64,
gas_used: u64,
gas_limit: u64,
...
}
To ensure a smooth transition between leaders, the current gateway also broadcasts an EndOfSequence message, signaling to the next gateway and nodes that sequencing rights can safely transfer. This approach minimises “dead times” when no sequencer is active, avoiding unnecessary reliance on L1 settlement during transitions.
struct EndOfSequence {
// Last block sequenced
block_number: u64,
// Hash of last block
block_hash: B256,
}
If the current gateway fails to broadcast the EndOfSequence message, the next gateway must fall back to waiting for the L1 to settle, preventing any risk of conflicting L2 transactions.
L1 Settlement and Slashing
Even though the chain tip advances optimistically, each gateway is responsible for ensuring that batches of L2 blocks are settled on the L1 according to the schedule in the lookahead. Gateways and proposers must post collateral in the registry contract and are subject to slashing under certain conditions, including:
- Reneging on preconfirmations,
- Failing to settle batches on the L1,
- Missing assigned slots.
Notably, proposers may also face slashing penalties if the gateway they have delegated to is slashed. This creates a strong alignment of incentives between proposers and gateways, reinforcing the responsibility of proposers to monitor and carefully select the gateways. In return, proposers earn additional yield, which compensates for the risks associated with delegation.
The exact conditions for attribution and slashing fall outside the scope of this document but remain an important area for further specification.
Fallback Mechanism
A liveness failure by a gateway results in a temporary “blackout,” during which users are unable to settle transactions, and the rollup is unable to progress. Failures in single centralised sequencers can result in hours-long disruptions, however a based rollup with multiple sequencers can recover within a few L1 slots.
In practice, a blackout caused by a faulty gateway would typically last only a short time, such as two L1 slots. The faulty gateway can be penalised by slashing its collateral and reducing its sequencing slots in future lookaheads. For instance, if GatewayA is the current leader as per the lookahead up to Slot N, but fails to post a Batch after the slot has passed, GatewayA can be slashed and temporarily excluded from the sequencing schedule.
This fallback mechanism ensures that even in the event of a gateway failure, the system remains resilient, minimising disruption and incentivising reliable performance from all gateways.
Note: Liveness failures can originate with either the gateway or the proposer, so we need a robust way to detect and penalise both scenarios. If the proposer is at fault, enforcing accountability may require an off-chain process, which conflicts with a truly trust-minimised approach. Designing a mechanism that can reliably attribute proposer-induced liveness failures, and penalise them, remains an open challenge.
Proposers and Gateways
The ability to delegate sequencing responsibilities to third parties allows unsophisticated proposers, who may lack bandwidth or the technical expertise required to run a gateway, to participate effectively. This delegation mechanism fosters a more equitable and inclusive market while introducing competitive pressure on gateway operators to provide higher-quality sequencing services.
Although similar in spirit to Proposer-Builder Separation (PBS), where validators delegate block-building to specialised third-party actors, based sequencing ensures that proposers retain control and oversight over their delegates. This is achieved through slashing gateways for safety faults and proposers for liveness faults. If the liveness fault is not caused by the proposer, it is expected that proposers will seek compensation from gateways via off-chain mechanisms.
Proposers act as “watchdogs,” monitoring the performance of gateways by tracking key metrics and incentivising reliability and efficiency. This alignment of incentives ensures that delegation does not compromise the security or robustness of the system.
Retention of Control over MEV and Priority Fees
Rollup operators retain full control over sequencing rules, priority fees, and MEV management. Gateways are required to operate in compliance with the rollup’s established policies. This is initially enforced by limiting participation to permissioned gateways until more robust mechanisms are available for fully permissionless participation.
Proposers earn a share of the fees as compensation for their indirect sequencing services and, in turn, allocate a portion of these fees to gateways based on their performance and reliability. This arrangement creates a virtuous cycle, incentivising gateways to deliver high-quality services while ensuring a fair distribution of rewards across the system.
The distribution of fees among proposers, gateways, and the rollup operator is determined at the discretion of the rollup operator, allowing flexibility to align with the rollup’s economic and operational goals.
Becoming Based
Achieving fully permissionless, based sequencing is the ultimate goal. However, we recognise that rollups starting with centralised sequencers may adopt a gradual, 3-phase approach to decentralisation. This framework allows for a progressive transition to based sequencing while minimising risks and ensuring operational stability.
Phase 1: Initial Deployment
In this phase, the leader-aware gossip protocol is deployed and integrated with a single gateway functioning as a centralised sequencer. This enables nodes to receive fast preconfirmations regardless of the L2 block time. A registry contract is introduced to lay the foundation for a sequencer set, initially comprising only one entity.
For added robustness, a fallback mechanism leveraging the existing rollup stack is also implemented.
Phase 2: Additional Gateway Introduction
Gateways are progressively incorporated into the lookahead schedule. At this stage, gateways are still operated by the rollup operator and/or pre-approved third parties. The gossip network becomes fully operational, enabling transaction forwarding and the streaming of sequenced batches. While gateways operate under SLA-like agreements with the rollup operator, slashing mechanisms are not yet enabled.
Phase 3: Permissionless Sequencing
Gateways can now permissionlessly join the sequencer set, and proposers are able to delegate sequencing responsibilities to gateways. Proposers are expected to monitor the performance and reliability of their delegates. At this stage, slashing mechanisms are activated to address safety and liveness faults.
However, several considerations, such as fault attribution and front-running prevention, must be addressed to ensure the system’s robustness before reaching this stage.
Risks
- Centralisation Risk: If the majority of proposers delegate to a small number of gateways, it could result in an oligopolistic sequencing market. Nevertheless, as long as more than one active gateway exists, this model remains a significant improvement over the centralised status quo. Furthermore, gateways are staked actors subject to slashing conditions and are held accountable by L1 proposers, ensuring decentralised oversight.
- Inconsistent User Experience: A rotating set of distributed sequencers may introduce variability in user experience compared to a centralised sequencer. To mitigate this, a temporary whitelist of gateway operators under SLA-like agreements can be employed to provide more consistent performance during the transition phases.
- Dependency on Rollup Operator: During Phases 1 and 2, the sequencer set is not fully permissionless and remains reliant on the rollup operator. This “training wheels” approach is necessary to ensure stability but introduces some centralisation during the early stages.
Further Considerations
Several topics require further discussion and detailed specification:
- The design and implementation of the registry contract.
- Collateral requirements for gateways and proposers.
- The definition of exact slashing conditions.
For Phase 3 (permissionless gateways), the following open questions remain:
- How to prevent front-running by malicious leaders.
- Determining fault attribution between proposers and gateways in cases of missed proposals.
- Establishing effective performance monitoring and addressing the fair exchange problem.
We are eager to work with protocol researchers, developers, rollup operators and other teams in the ecosystem to join in refining these open questions and shaping a secure, high-performance future for based sequencing. By collaborating on the outstanding design details and testing solutions in real-world settings, we can work together to build a more robust, permissionlessly sequenced rollup ecosystem.