Skip to content

Integrate with Blobstream

Blobstream logo

Blobstream is the first data availability solution for Ethereum that securely scales with the number of users. Formerly known as the Quantum Gravity Bridge (QGB), Blobstream relays commitments to Celestia's data root to an onchain light client on Ethereum, for integration by developers into L2 contracts. This enables Ethereum developers to build high-throughput L2s using Celestia's optimised DA layer, the first with Data Availability Sampling (DAS).

The following docs go over how developers can integrate Blobstream. There are also docs on how to run a Blobstream orchestrator as a Celestia validator which won't be covered in the following sections aimed at developers.


Blobstream, consists of two components: an orchestrator and a relayer.

In the following diagram, we show how a layer 2 (L2) would post data to Celestia and then verify that it was published in the target EVM chain.


Data will first be attested to by the Celestia validator set, i.e. signing commitments committing to the data. Then, these signatures will be relayed to the target EVM chain (in this case, Ethereum). Finally, the L2, or any party, will be able to verify that the data was published to Celestia directly on the EVM chain on the Blobstream smart contract. You can reference the Blobstream smart contract.

The orchestrator is part of the validator setup and works as follows:

  • celestia-app creates an attestation on the state machine level that needs to be signed
  • The orchestrator queries the attestation, signs it, then submits the signature to the Blobstream P2P network

The relayer submits the attestations' signatures from the Blobstream P2P network to the target EVM chain.


If the contract is still not deployed, then it needs to be deployed before it is used by the relayer. See the deployment documentation for more details.

How Blobstream works

Blobstream allows Celestia block header data roots to be relayed in one direction, from Celestia to an EVM chain. It does not support bridging assets such as fungible or non-fungible tokens directly, and cannot send messages from the EVM chain back to Celestia.

It works by relying on a set of signers to attest to some event on Celestia: the Celestia validator set. The Blobstream contract keeps track of the Celestia validator set by updating its view of the validator set with updateValidatorSet(). More than 2/3 of the voting power of the current view of the validator set must sign off on new relayed events, submitted with submitDataRootTupleRoot(). Each event is a batch of DataRootTuples, with each tuple representing a single data root (i.e. block header). Relayed tuples are in the same order as Celestia block headers.

Blobstream attestation flow

Events and messages relayed

Validator sets: The relayer informs the Blobstream contract who are the current validators and their power. This results in an execution of the updateValidatorSet function.

Batches: The relayer informs the Blobstream contract of new data root tuple roots. This results in an execution of the submitDataRootTupleRoot function.

How to integrate

Integrating your L2 with Blobstream requires two components: your onchain smart contract logic, and your offchain client logic. The next three sections cover these topics:

Deployed contracts

You can interact with the Blobstream contracts today on testnet. The Blobstream Solidity smart contracts are currently deployed on the following Ethereum testnets:

ContractEVM networkContract addressAttested data
BlobstreamSepolia0x3a5cbB6EF4756DA0b3f6DAE7aB6430fD8c46d247Mocha testnet
BlobstreamArbitrum Sepolia0x040769edbca5218e616c8eb16e4faea49ced5e33Mocha testnet
Blobstream XGoerli0x67ea962864cdad3f2202118dc6f65ff510f7bb4dMocha testnet

Blobstream vs. data availability committees (DACs)

Decentralization and security

Blobstream is built on Celestia, which uses a CometBFT-based proof-of-stake system. An incorrect data availability attestation in this system will ultimately be penalized (currently not implemented), ensuring validators act in good faith. Thus, Blobstream shares the same security assumptions as Celestia. In contrast, data availability committees (DACs), are typically centralized or semi-centralized, relying on a specific set of entities or individuals to vouch for data availability.

Mechanism of verification

Blobstream uses data availability attestations, which are Merkle roots of the batched L2 data, to confirm that the necessary data is present on Celestia. The L2 contract on Ethereum can check directly with Blobstream if the data is published on Celestia. Similarly, a DAC would rely on attestations or confirmations from its permissioned members.

Flexibility and scalability

Blobstream is designed to offer high-throughput data availability for Ethereum L2s, aiming to strike a balance between scalability and security. It operates independently of Ethereum's gas costs, as Celestia's resource pricing is more byte-focused rather than computation-centric. On the other hand, the scalability and flexibility of a DAC would depend on its specific design and implementation.

In summary, both Blobstream and DACs aim to ensure offchain data availability, but Blobstream offers a more decentralized, secure, and scalable solution compared to the potential centralized nature of DACs.