Celestia is the first modular blockchain network allowing for the effortless development of new blockchains. Celestia focuses on the real bottleneck of scalability in blockchain infrastructure, data availability. To solve this Celestia provides a pluggable consensus and data availability layer, allowing developers to deploy their own execution layers to run on top. This enables more customizability and sovereignty for applications built on Celestia.
Traditional blockchains have the consensus layer and the execution layer on the same layer (see photo below).
Consensus Layer
This layer deals with the enforcement of network rules that describe what nodes within the network should do to reach consensus about the broadcasted transactions. It also deals with the generation and verification of blocks.
Execution Layer
Execution layer is the sublayer which constitutes of smart contracts, underlying rules and chaincode. This sublayer has the actual code that gets executed and rules that are executed.
notion image

Traditional monolithic architecture

notion image

Celestia-enabled modular architecture

Celestia separates the consensus layer and the execution layer allowing users to deploy their own execution layers on top of the Celestia consensus and data availability layer. This allows Celestia to achieve scalability, flexibility, and interoperability that is not achievable in traditional monolithic blockchain designs.
notion image


Celestia applies modular architecture, which breaks up the blockchain layer stack into separate specialized components. This allows for the core functions of consensus and execution to be separated.
notion image
In monolithic architecture blockchains having consensus and execution on the same layer restricts users to one execution environment. This limits the potential to optimize for specific use cases (DeFi, Play to earn gaming, NFTs, etc) and forces all users of the chain to operate under the same execution environment. Take Ethereum for example and the issues with congestion and gas on the platform in 2021/2022.
With Celestia and the separation of these layers, it allows for data availability sampling and offers a solution to the data availability problem. This problem is at the core of blockchain architecture and has some of the biggest and brightest minds working to solve it. If you are not familiar with the data availability problem and are interested I suggest you read through some of these documents.


Celestia uses what is called Data Availability Proofs. These and fraud proofs are key to enabling on-chain scaling of blockchains. Data Availability Proofs allow for nodes to download and sample a small portion of random chunks from each block in the chain.
Celestia light clients only work if there are enough clients in the network to sample the entire blockchain. This leads to a scale-out design meaning more adoption = higher scale. This works because the more light clients you have in the network, the greater the block size (and as a result throughput and more scaling) you can have without compromising on decentralization and security.
Data Availability Proofs utilize what is called Erasure Code which is used in things like DVDs, QR codes to satellite communication.
notion image
More info on Data Availability Proofs here
More info on Erasure Code here


Rollups are a Layer 2 scaling solution that forces the execution off-chain and rely on a base chain for consensus and data availability. They aim to provide a cheaper platform for dApps without sacrificing security and decentralization.
notion image
Again take Ethereum for example. Most transactions still occur on Ethereum however these will eventually move off-chain once Ethereum fully integrates their PoS and various Layer 2 rollup solutions. Celestia is a perfect complement to rollups because it provides them with a scalable chain that they can publish transaction data at a low cost to users. Optimistic rollups require data availability (DA) to detect fraud and zero-knowledge rollups (zk Rollups) require data availability to reconstruct the state of the chain.
Layer 2 rollups are very technical in nature and there is a whole plethora of information and data on them out there. I will list some good resources below for you.


Intra-Cluster Communication

Clusters can be considered simply as a set of blockchains or even a set of rollups connected to a parent chain that can communicate with each other through what is called intra-cluster communication.
There are 2 ways that these chains can communicate with each other
  1. Trust-minimized - Cross-chain communication that relies on either an honest minority or synchrony assumption for liveness and state verification (definitions in drop-down below).
  1. Trusted - Cross-chain communication, that relies on an honest majority assumption for liveness and state verification (definitions in drop-down below).
Relay liveness
If a transaction happens that changes the state of chain A in a way that affects the state of chain B, then some transaction needs to be eventually submitted on chain B (whether by the user, a relayer, or some other party) to complete the transaction. For example, if Alice locks some coins on chain A to move them to chain B, there should eventually be a corresponding transaction submitted to increase Alice's balance on chain B.
State verification
When chain A and chain B take actions based on the states of each other, they need to be sure that the information on the state they have received actually corresponds to the agreed and valid state of the chain according to the chain's transaction validity rules. Note that liveness requires state verification. For a more in-depth look at cross-chain state verification
Every chain in the cluster can validate the state machine of other chains in the cluster. This simply means storing the status of the blockchain. For example, all Ethereum rollups are EVM-compatible so it is possible to validate the fraud of ZK proofs (zero-knowledge) of rollups within the EVM (Ethereum virtual machine). However, you could not share an Ethereum cluster with a chain like Solana because you could not validate the Solana state machine within the EVM.
notion image

Inter-Cluster Communication

Clusters can also communicate with other clusters with trusted cross-chain communication using state validation techniques that are not trust-minimized through what is called inter-cluster communication.
notion image
These articles here outline the possibilities and limitations of inter-cluster bridging
notion image


The Quantum Gravity Bridge is a Celestia to Ethereum data availability (DA) bridge. Currently, Ethereum rollups collect data from multiple transactions into a single batch transaction, which is posted to Ethereum. This includes the rollups transaction data that is posted to Ethereum but not executed directly.
This can get quickly really expensive due to the costs associated with posting all the transaction data to Ethereum due to the limited capacity of Ethereum.
This is where Celestia and what are called “Celestiums” come into play. A Celestium is an Ethereum L2 chain that uses Celestia for data availability, but Ethereum for settlement and dispute resolution. Remember Celestia as an L1 doesn’t handle computations it just handles data availability.
The Quantum Gravity Bridge sits on Ethereum. It works like this
Ethereum L2 operators post their transaction data to Celestia Network → its then placed into blocks by Celestia’s PoS validators → The data is then relayed in the form of data availability attestation from Celestia to Ethereum →The Quantum Gravity Bridge contract verifies the signature on the DA attestation from Celestia → L2 contract verifies call data
What a Celestium will look like, leveraging Celestia as the DA layer.
What a Celestium will look like, leveraging Celestia as the DA layer.
So in essence instead of call data being posted to Ethereum, it utilizes Celestiums because of the higher data throughput of Celestia.


Currently, there is no token for Celestia and apparently, there doesn’t necessarily have to be one.
In their whitepaper they stated
  • "There does not need to be a native currency to the system, as consensus nodes can choose to accept transaction fees in any currency application that they choose to recognize.”
Essentially any IBC (inter-blockchain communication) enabled chain’s native token could be used for transactions fees as consensus nodes can choose to accept any currency they recognize.
Many believe there will be a token in the future in order to incentivize securing the network as a validator.


Mustafa Al-Bassam is the CEO of Celestia Labs, he previously co-founded Chainspace, a sharded smart contract platform that was acquired by Facebook. He has written a number of seminal papers whose contributions underpin the security of sharded blockchain systems, notably a formal fraud and data availability proofs scheme.
Also on the team is John Adler, a layer two scalability researcher at ConsenSys working on Phase 2 of Ethereum 2.0. He created the first specification for an optimistic roll-up scheme, drawing inspiration from Mustafa’s earlier works on data availability.
Joining them is Ismail Khoffi, a senior research engineer who has many years of experience ranging from building academic research prototypes to bringing both blockchain and non-blockchain systems to production, including at Tendermint, Google UK, and EPFL.
Below you can see the rest of the team and some info on each of them. Here is the link - https://celestia.org/team/#team
notion image
notion image


notion image
Built with Potion.so