Skip to main content

The Rollkit stack

This page will cover the main components of Rollkit.

Rollup sequencer nodes collect transactions from users, aggregate them into blocks, and post the blocks onto a data availability (DA) layer (such as Celestia) to be ordered and finalized. Full nodes execute and verify rollup blocks, and in the case of an optimistic rollup, propagate fraud proofs when needed. Light clients will receive headers, verify proofs (fraud, zk, etc), and authenticate trust-minimized queries about the state.


If you're familiar with Rollkit's stack, you may want to skip to the tutorials section.

Application structure

Rollup architecture with Rollkit and ABCI.

ABCI interface

Rollkit is a fully functional Application BlockChain Interface (ABCI) client software. It can be used as a Tendermint replacement for any ABCI application. Thanks to this compatibility, you can use tools like abci-cli to test and debug your rollup.

Cosmos SDK

Would you like to change your Cosmos SDK application to a Rollkit rollup? No problem! You need to replace the Cosmos SDK Go dependency with a Rollkit-enabled version, which can be found at the rollkit/cosmos-sdk repository.

Note the rollkit/cosmos-sdk repository follows the release branches of upstream Cosmos SDK, but with the bonus of using Rollkit instead of Tendermint as the ABCI client.

And don't forget to replace another dependency, tendermint, with rollkit/tendermint, which has an enhanced ABCI interface that includes the methods needed for state fraud proofs.

Data availability

Data availability (DA) can be accessed using generic interfaces. This design allows for seamless integration with any DA layer. New implementations can be plugged in programmatically, without a need to fork Rollkit.

The DataAvailabilityLayerClient interface includes essential lifecycle methods (Init, Start, Stop) as well as data availability methods (SubmitBlock, CheckBlockAvailability).

The BlockRetriever interface serves to enable syncing of full nodes from the data availability layer. It's important to keep in mind that there is no direct correlation between the DA layer block height and the rollup height. Each DA layer block may contain an arbitrary number of rollup blocks.


Celestia is an example of a data availability integration implemented for Rollkit. It's using the Celestia Node gateway API via the celestiaorg/go-cnc package. To deploy a Rollkit rollup on Celestia you also have to run a Celestia light node.

Node components


The mempool is inspired by the Tendermint mempool. By default, transactions are handled in a First Come, First Served (FCFS) manner. Ordering of transactions can be implemented on the application level; currently this is possible by returning a priority on CheckTx, and once we support ABCI++ it is also possible via PrepareProposal and the application mempool.

Block manager

The block manager contains Go routines AggregationLoop, RetrieveLoop, and SyncLoop that communicate through Go channels. These Go routines are ran when a Rollkit node starts up (OnStart). Only the sequencer nodes run AggregationLoop which controls the frequency of block production for a rollup with a timer as per the BlockTime in BlockManager.

All nodes run SyncLoop which looks for the following operations:

  • Receive block headers: block headers are received through a channel HeaderInCh and Rollkit nodes attempt to verify the block with the corresponding block data.
  • Receive block data: block bodies are received through a channel blockInCh and Rollkit nodes attempt to verify the block.
  • Receive state fraud proofs: state fraud proofs are received through a channel FraudProofInCh and Rollkit nodes attempt to verify them. Note that we plan to make this configurable for full nodes since full nodes also produce state fraud proofs on their own.
  • Signal RetrieveLoop with timer as per the DABlockTime in BlockManager.

All nodes also run RetrieveLoop which is responsible for interacting with the data availability layer. It checks the last updated DAHeight to retrieve a block with timer DABlockTime signaled by SyncLoop. Note that the start height of the DA layer for the rollup, DAStartHeight, is configurable in BlockManager.


Rollkit's RPC fully implements the Tendermint RPC interfaces and APIs for querying:

  • Information about the rollup node: information such as node's health, status, and network info.
  • The rollup blockchain: getting information about the rollup blockchain such as blocks and block headers.
  • The rollup transactions: getting transaction information and broadcasting raw transactions, with search capabilities.
  • ABCI: rollup application information.

The following RPC protocols are currently supported:

  • URI over HTTP
  • JSON-RPC over HTTP
  • JSON-RPC over WebSockets

P2P layer

Rollkit's P2P layer enables direct communication between rollup nodes. It's used to gossip transactions, headers of newly created blocks, and state fraud proofs. The P2P layer is implemented using libp2p.

Rollkit uses DHT-based active peer discovery. Starting a node connects to pre-configured bootstrap peers, and advertises its namespace ID in the DHT. This solution is flexible, because multiple rollup networks may reuse the same DHT/bootstrap nodes, but specific rollup network might decide to use dedicated nodes as well.

Rollkit node types

Rollkit nodes are implemented in the node package.

Full node

Full nodes verify all blocks, and produce fraud proofs for optimistic rollups. Since they fully verify all rollup blocks, they don't rely on fraud or validity proofs for security.

Light node (work in progress)

Light nodes are light-weight rollup nodes that authenticate block headers, and can be secured by fraud proofs or validity proofs. They're recommended for average users on low-resource devices. Users running light nodes can make trust-minimized queries about the rollup's state. Currently, Rollkit light nodes are still under development.

Sequencer node

Rollups can utilize sequencer nodes. Sequencers are block producers for rollups, responsible for aggregating transactions into blocks, and typically executing transactions to produce a state root, used by the rollup's light clients.

Rollkit plans to support multiple different pluggable sequencer schemes:

Deploy in one-clickFaster soft-confirmations than L1Control over rollup's transaction orderingAtomic composability with other rollupsCensorship resistanceImplementation Status
Centralized sequencerRequires spinning up a sequencerYes ✅Yes ✅No ❌Eventual ⏳*✅ Implemented!
Decentralized sequencerRequires spinning up a sequencer setYes ✅Yes ✅No ❌Real-time ⚡️Planned
Shared decentralized sequencerYes ✅Yes ✅No ❌Yes ✅Real-time ⚡️Planned
Pure fork-choice ruleYes ✅No ❌Maybe 🟡Maybe 🟡Eventual ⏳Planned

"Pure fork-choice rule" refers to any rollup without privileged sequencers, e.g. nodes defer to the data availability layer for ordering and apply a "first-come-first-serve" fork-choice rule.

* implementation of this property is in progress.

State validity modes

Pessimistic (full nodes only)

A pessimistic rollup is a rollup that only supports full nodes that replay all the transactions in the rollup in order to check its validity. Rollkit supports pessimistic rollups by default.

Pessimistic rollups are similar to how Tether uses Bitcoin as a data availability layer via OmniLayer.

Optimistic (fraud proofs) (work in progress)

Rollkit's current design consists of a single sequencer that posts blocks to the DA layer, and multiple (optional) full nodes. Sequencers gossip block headers to full nodes and full nodes fetch posted blocks from the DA layer. Full nodes then execute transactions in these blocks to update their state, and gossip block headers over the P2P network to Rollkit light nodes.

Once state fraud proofs are enabled, when a block contains a fraudulent state transition, Rollkit full nodes can detect it by comparing intermediate state roots (ISRs) between transactions, and generate a state fraud proof that can be gossiped over the P2P network to Rollkit light nodes. These Rollkit light nodes can then use this state fraud proof to verify whether a fraudulent state transition occurred or not by themselves.

Overall, state fraud proofs will enable trust-minimization between full nodes and light nodes as long as there is at least one honest full node in the system that will generate state fraud proofs.

Note that Rollkit state fraud proofs are still a work in progress and will require new methods on top of ABCI, specifically, GenerateFraudProof, VerifyFraudProof, and GetAppHash.

You can find current detailed design and the remaining work needed to push state fraud proofs towards completion in this Architecture Decision Record (ADR).

Validity (ZK proofs)

Validity (ZK) rollups are planned, but not currently supported by Rollkit.