What is a rollup, and why did Bitcoin need one?

Bitcoin's scalability problem

Bitcoin is designed to prioritise verifiability, decentralisation and robustness rather than to maximise the number of transactions per second. Every full node validates transactions in accordance with the rules of the protocol. On the base layer, capacity is limited and is often estimated at roughly 7 transactions per second, although the actual figure depends on the nature and size of the transactions.

For years, the debate could be distilled into a single question: how can Bitcoin's capacity be increased without compromising what makes it unique?

The paths tried so far

The first answer was the Lightning Network, operating since 2018: a network of payment channels that enables fast and usually low-cost payments, including along routes that run through several channels. It is intended chiefly for payments and does not offer a general-purpose smart-contract environment. Its operation also depends on the liquidity available and on the ability to find a suitable route.

Stacks took a different approach: a smart-contract network connected to Bitcoin through the PoX mechanism and with its own language, Clarity. Its security model and finality differ from Bitcoin's and, moreover, depend on the specific rules of the Stacks network.

Rootstock (RSK) opted for EVM compatibility and merge-mining with Bitcoin. The network has operated since 2018 and uses a sidechain model with its own assumptions regarding security and the bridge.

Why a rollup is different

A rollup is not a sidechain. The technical distinction is important:

• - A sidechain retains its own consensus or validation mechanism. Its security depends chiefly on that system and on the design of its bridge, which connects it to Bitcoin.
• - In the architecture described for Bitcoin Hyper, execution would take place outside Bitcoin, while state commitments would be published on the base layer. Whether it truly qualifies as a rollup also depends on data availability and the proving system.

According to the architecture published by the project, the intended process would look as follows:

1. Users would submit their transactions to the sequencer
2. The sequencer would order them and execute them in batches
3. At regular intervals, the state commitment, described as a Merkle root of the updated state, would be published to Bitcoin via OP_RETURN or Taproot
4. The ability to verify the transition would depend on data availability and the proving system; the commitment does not, in itself, prove that the transition is correct

As soon as it is confirmed on Bitcoin, the state commitment enjoys the practical immutability of the transaction that contains it. This makes it difficult to alter that record after the fact, but it does not, in itself, prevent the publication of an incorrect commitment, nor does it guarantee the validity of the state, data availability or the security of the bridge.

Data availability: still an open question

The key point is this: where do the transaction data actually reside? If only the commitment is published on Bitcoin while the full data remain in the hands of the sequencer, the architecture would be closer to a Validium-type model than to a rollup in which data availability is public. This distinction is not merely academic: if the sequencer were to disappear along with the data, users might no longer be able to verify their own balance.

According to the documentation published by the project, the definitive data-availability solution is still under study; an update dated 27 March 2026 states this explicitly. The options being examined include external data-availability layers, such as Celestia, erasure coding and the use of distributed nodes.

In summary

A rollup on Bitcoin can pursue several design goals: using Bitcoin to anchor state commitments; increasing capacity through off-chain execution; providing an environment for smart contracts; and lowering costs for users. The extent to which these goals can be achieved depends on the specific implementation, data availability, the proving system and the exit mechanisms.

The price of this approach is greater architectural complexity and several design decisions that remain unresolved: the sequencer, data availability, the bridge and the proving system. The project asserts that these components can be managed gradually; this is the project's own view, which remains to be independently verified.