Celestia RPC: Talking to a Modular Data Availability Layer

Celestia is one of the most talked-about chains in crypto, and also one of the most misunderstood by developers who first connect to it — because it isn't an execution chain at all. There's no eth_*, no smart contracts, no accounts-with-code. Celestia is a modular data availability (DA) layer: its whole job is to order transactions and guarantee their data was published, so that rollups built on top can handle execution. Once you understand that, its RPC makes sense. Here's the map.

What Celestia actually does

In a monolithic chain (like Ethereum L1), one network does everything: execution, settlement, consensus, and data availability. Celestia pulls data availability out into its own specialized layer. Rollups post their transaction data to Celestia; Celestia orders it and guarantees it's available; the rollup executes the transactions itself. This is the "modular" thesis — separate the layers, and each can scale independently.

Two ideas make it work:

• Data Availability Sampling (DAS): light nodes verify that a block's data was actually published without downloading the whole block — they randomly sample small pieces and, probabilistically, confirm availability. This is what lets Celestia scale data throughput as more light nodes join.
• Namespaced Merkle Trees (NMT): data is organized so a rollup can download only its own data, not the entire chain.

Celestia launched mainnet October 2023, is built with the Cosmos SDK + CometBFT (Tendermint) consensus, uses the TIA token (6 decimals), and has ~6-second blocks with single-block deterministic finality.

The RPC reality: it's a Cosmos chain, not an EVM one

Because Celestia is a Cosmos SDK chain, you don't talk to it with eth_*. You use the CometBFT (Tendermint) RPC — the same consensus-layer RPC every Cosmos chain exposes. SwiftNodes serves this endpoint:

# Node + sync status (CometBFT RPC)
curl -s -X POST https://rpc.swiftnodes.io/rpc/celestia?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"status","params":[],"id":1}'
# -> {"result":{"node_info":{...},"sync_info":{"latest_block_height":"...",...}}}

The CometBFT RPC methods you'll actually use:

This is standard Cosmos consensus RPC — the same surface you'd use for Osmosis, Injective, or the Cosmos Hub (a dedicated post on the Cosmos RPC stack — Tendermint RPC vs REST vs gRPC — is coming). If you've only worked with EVM chains, the mental shift is: query the application state via abci_query, not via method-per-field getters.

Where the special part lives: blobs and the celestia-node API

Here's the nuance. The thing that makes Celestia Celestia — posting and retrieving data blobs — doesn't happen over the CometBFT RPC. It happens through the celestia-node API, a separate JSON-RPC exposed by a light, bridge, or full celestia-node (the DA node software, distinct from the consensus node).

• Submitting data: a rollup posts a blob with a PayForBlobs transaction via blob.Submit on the node API. The blob is stored under a namespace.
• Retrieving data: blob.Get / blob.GetAll fetch blobs by namespace + height.
• Verifying availability: light nodes run DAS automatically.

The celestia-node API typically requires an auth token and is often run by the team building the rollup (or a specialized DA provider), because it's tied to a node you control. So the practical split is:

• Core consensus RPC (CometBFT) — reading blocks/state, monitoring the chain, broadcasting standard transactions. This is what a flat-rate RPC endpoint like SwiftNodes gives you.
• celestia-node DA API — blob submit/retrieve/DAS. Run by rollup operators against their own node.

If your goal is to read Celestia's chain, monitor DA activity, track blocks, or broadcast transactions, the CometBFT RPC is what you need. If you're building a rollup that posts data, you'll also run a celestia-node for the blob API.

Blobs here vs "blobs" on Ethereum

A quick disambiguation, because the word collides: Celestia's blobs are the arbitrary data rollups post to its DA layer. Ethereum's blobs (EIP-4844) are a similar idea — cheap, temporary data availability for rollups — but implemented inside Ethereum L1. They solve the same problem (rollup DA) from opposite architectural directions: Celestia is a purpose-built external DA layer; EIP-4844 bolts DA capacity onto a monolithic L1. If you're evaluating where a rollup should post its data, that's the core trade-off.

Finality and reading the chain

Celestia has single-block deterministic finality via CometBFT — once a block is committed by the validator set, it's final, no reorgs (light-node availability confidence accrues separately through sampling). For an indexer that means you can trust a committed block immediately, similar to other BFT chains — no probabilistic confirmation waits, minimal reorg handling. Read blocks and results via block / block_results, and query state via abci_query.

The short version

Celestia is a modular data availability layer, not an execution chain — so its RPC is Cosmos CometBFT (Tendermint) RPC, not eth_*. Use status, block, block_results, abci_query, and broadcast_tx_* to read state and broadcast transactions. The DA-specific part — posting and retrieving blobs under namespaces, plus data availability sampling — lives in the separate celestia-node API (auth-token'd, run by rollup operators), not the core RPC. It has single-block BFT finality, so reads are deterministic. Think of it as: core RPC to talk to the chain, node API to move data.

For reading Celestia, monitoring DA activity, and broadcasting, you need a reliable CometBFT endpoint. A flat-rate Celestia RPC endpoint gives you that across load-balanced nodes, alongside dozens of other chains under one key. Grab a free key and point your app at:

https://rpc.swiftnodes.io/rpc/celestia?key=YOUR_API_KEY