A single sequencer at launch: risk or pragmatism?
An analysis of the single sequencer envisaged for the launch of Bitcoin Hyper: operational advantages, concentration of power, censorship, availability, MEV and the conditions for verifiable decentralisation.
Educational purpose. The contents of this article are for information and general understanding only. They do not constitute financial advice. Full disclaimer.
Transaction ordering is an exercise of power
Every rollup needs someone — or something — to determine the order in which transactions are processed. That is the job of the sequencer.
Ordering is not neutral. Whoever controls the sequencer can: extract MEV (Maximal Extractable Value) by adding or reordering transactions to their own advantage; censor transactions by ignoring those it does not wish to process; and engage in front-running by getting ahead of other users' transactions.
In a decentralised system, no single actor gathers this power to itself. In a system with a centralised sequencer, that power rests with the team that operates it. The risks associated with this concentration include the censorship of transactions, delays, poor service availability, control over ordering, the extraction of MEV and the existence of a single point of failure.
Why many rollups start with a centralised sequencer
The most direct answer is that this architecture is operationally simpler. In the initial phase, a single operator could simplify coordination, upgrades and debugging. At the same time, such a model would concentrate power and dependencies in the hands of a single actor.
A decentralised sequencer requires a consensus protocol among multiple sequencers, mechanisms against collusion, systems for leader election or rotation, and robust economic incentives that are difficult to attack.
Building all of these mechanisms before launch may require considerably more development time. Arbitrum, Optimism and Base — three significant rollups on Ethereum — launched with a centralised sequencer and are continuing their decentralisation process years later. This comparison is purely contextual: it does not presuppose architectural or security equivalence with the architecture described for Bitcoin Hyper.
According to the project documentation analysed in chapter 34.2 of the book, at mainnet launch the sequencer would be centralised and operated by the team. As at the cut-off date, Bitcoin Hyper was still in its pre-mainnet phase: a single sequencer belongs to the planned launch model rather than to an already-verified operational component. The roadmap envisages a gradual decentralisation over a period of two to four years, through rotation, auction and leader-election mechanisms. This is a stated intention rather than a completed feature.
How would censorship risk be limited?
The most important planned architectural mechanism is forced transaction inclusion (forced inclusion): a transaction could be “forced” into the rollup by way of Bitcoin's base layer, bypassing the sequencer. If the sequencer were to censor a transaction, the user could have it processed by paying the fees directly on Bitcoin. A single sequencer creates a central point of operational control; forced inclusion is a planned safety mechanism whose purpose is to prevent that control from becoming absolute. It should be regarded as a documented feature that remains to be verified, not as an already-available guarantee.
The decisive caveat is that forced inclusion in Bitcoin Hyper is still under development (as at 28 April 2026). It was not available on the Devnet. Until it is released and tested, the protection it offers remains unverified. These details relate to the documentation available at that time.
Signals worth watching
Before considering a position in Bitcoin Hyper, these are the signals that would indicate genuine progress on decentralising the sequencer. As at the cut-off date, no public and sufficiently detailed specification of the definitive mechanism existed:
- Published technical specifications for the chosen decentralisation mechanism
- Working forced inclusion on Testnet or Mainnet
- A roadmap with verifiable milestones (not merely “in the coming years”)
- An audit of the sequencer code carried out by recognised independent firms
- A credible timeline with explicit dependencies
Conclusion
A centralised sequencer at launch can be a pragmatic and understandable choice, without necessarily being a warning sign. In itself it does not imply a loss of funds, but it can weaken service availability, transaction ordering and censorship resistance. It becomes problematic when a concrete decentralisation roadmap is missing, when forced inclusion is never delivered, or when the entity operating the sequencer exploits its position to extract MEV in a non-transparent manner.
The project states that sequencing will be decentralised at a later stage. At the time of writing, that transition is still a roadmap objective, and a general promise of decentralisation is not a verifiable roadmap. The sequencer, the bridge, data availability and the proving system form distinct layers: decentralising the sequencer would not automatically remove the risks associated with the bridge, nor those associated with data availability. Forced inclusion, forced exit and the Escape Hatch should be regarded as documented features, or features that remain to be verified. A single sequencer can be a pragmatic starting point, but it should not be presented as an end point: the assessment depends on the published limitations, the controls in place and the alternative procedures. The credibility of decentralisation rests on verifiable milestones, not merely on statements of intent.