Cosmos RPC Explained: Tendermint RPC vs REST vs gRPC

If you come to the Cosmos ecosystem from Ethereum, the first thing that trips you up isn't the SDK or the tokens — it's the word "RPC." On Ethereum, the RPC is a single JSON-RPC endpoint, and eth_* methods do everything. On a Cosmos chain, "RPC" can mean three different interfaces, each running on its own port, each answering a different kind of question. Point CosmJS at the wrong one and nothing works. This post clears that up: what the three interfaces are, when to use each, and the one mental shift — you query modules, not contracts — that makes the whole thing click. It applies to every Cosmos-SDK chain, including the ones we've spotlighted: Celestia, Osmosis, and Injective.

First, the mental shift: modules, not contracts

On Ethereum, state lives inside smart contracts, and you read it by eth_call-ing a contract function. On a Cosmos chain, the base functionality — balances, staking, governance, and app-specific logic — lives in modules compiled into the chain binary (bank, staking, gov, plus app modules like Osmosis's poolmanager). You don't call a contract's balanceOf; you query the bank module for an address's balance.

So there's no eth_getBalance, no eth_getLogs, no eth_call. Instead, every interface below is a different way to reach the same module queries and the underlying consensus data. Keep that in mind and the three endpoints stop being confusing — they're three doors into the same house.

The three interfaces

1. Tendermint / CometBFT RPC — the consensus layer (port 26657)

This is what people usually mean by "the Cosmos RPC," and it's what an integration points CosmJS at. It's a JSON-RPC (and URI) interface to the consensus engine — CometBFT (formerly Tendermint) — exposing:

• Chain/consensus data: status, block, block_results, commit, validators.
• Transactions: tx, tx_search, and broadcasting via broadcast_tx_sync / _async / _commit.
• Generic state access: abci_query — the escape hatch that lets you query any module's state by path.

It's the lowest-level, most universal interface: block data, transaction submission, and (via abci_query) all module state. If you're tailing the chain, broadcasting transactions, or building with CosmJS, this is your endpoint.

import { StargateClient } from "@cosmjs/stargate";

// CosmJS talks to the Tendermint/CometBFT RPC
const client = await StargateClient.connect(
  "https://rpc.swiftnodes.io/rpc/osmosis?key=YOUR_API_KEY"
);
console.log(await client.getHeight());             // current block height
console.log(await client.getAllBalances(address)); // bank module, under the hood

2. REST / LCD — the HTTP gateway (port 1317)

The LCD ("Light Client Daemon," now just the REST API) is a RESTful gateway that maps plain HTTP GET paths to the same module queries. It's generated from the modules' protobuf definitions via gRPC-gateway, so every query has a URL:

GET /cosmos/bank/v1beta1/balances/{address}
GET /cosmos/staking/v1beta1/validators
GET /osmosis/poolmanager/v1beta1/pools

REST is the convenient choice for browsers, quick scripts, and reading module state without any protobuf tooling — paste a URL, get JSON. It's a read-and-broadcast gateway, not a consensus interface: you won't tail blocks here, but you'll happily fetch balances, positions, and app-module state.

3. gRPC — the typed interface (port 9090)

Under the hood, Cosmos modules define their queries in protobuf, and gRPC is the native, strongly-typed way to call them. With generated clients you get type safety, efficient binary encoding, and streaming — the right choice for production backends that want typed queries rather than hand-built URLs or JSON. REST is literally a gateway in front of gRPC, so anything REST can do, gRPC can do with types.

Which one do I use?

For most integrations — wallets, indexers, dApps built with CosmJS — you'll live in the Tendermint RPC, because it covers block data, transaction submission, and (via abci_query) all module state. That's the endpoint SwiftNodes serves at /rpc/<chain> for Cosmos chains.

Broadcasting transactions: messages, not calldata

Cosmos transactions aren't EVM calldata — they're Cosmos SDK messages (Msg types: MsgSend, MsgDelegate, Osmosis's MsgSwapExactAmountIn, etc.). You build and sign them with CosmJS, then broadcast over the Tendermint RPC:

import { SigningStargateClient } from "@cosmjs/stargate";

const client = await SigningStargateClient.connectWithSigner(
  "https://rpc.swiftnodes.io/rpc/osmosis?key=YOUR_API_KEY", wallet
);
await client.sendTokens(from, to, [{ denom: "uosmo", amount: "1000000" }], "auto");

Two Cosmos gotchas worth flagging, both covered in the Osmosis spotlight: amounts are in micro-denominations (uosmo, uatom — 1 token = 1,000,000 base units), and cross-chain assets show up as ibc/<HASH> denoms you resolve via the denom trace.

Finality: single-block, no reorgs

One genuinely nice thing after Ethereum: CometBFT gives single-block BFT finality. When a block commits, it's final — there are no reorgs, no confirmation counting, no "wait 12 blocks." Index at the tip and trust it. (Contrast with the reorg defenses probabilistic chains force on you — none of that here.)

How this maps to the Cosmos chains you'll use

Every Cosmos-SDK chain follows this same three-interface pattern; only the app modules differ:

• Celestia — a modular data-availability layer; its core consensus RPC is standard CometBFT, with blob submission living in a separate node API.
• Osmosis — a DEX where the AMM is a native module (poolmanager/gamm), queried through exactly these interfaces rather than a smart contract.
• Injective — a finance-focused chain whose order-book and exchange logic are likewise native modules (Injective RPC).

Learn the pattern once and every Cosmos chain is approachable — the modules change, the three doors don't. And since the Tendermint RPC is plain JSON-RPC, standard conveniences like request batching still apply when you're making many reads. (It's a different world from the non-Cosmos non-EVM chains like Sui, which has its own object-model API entirely.)

The short version

"Cosmos RPC" isn't one thing — it's three interfaces to the same chain: Tendermint/CometBFT RPC (consensus + tx broadcast + generic abci_query, port 26657, what CosmJS uses), REST/LCD (HTTP gateway to module queries, port 1317, browser-friendly), and gRPC (typed protobuf queries, port 9090, for backends). The unifying idea is that you query modules, not contracts — no eth_*, no balanceOf; you ask the bank module for a balance and the app module for app state. Transactions are signed Msg types broadcast over the Tendermint RPC, and finality is single-block (no reorgs).

Building on the Cosmos ecosystem? A flat-rate Cosmos RPC endpoint gives you CometBFT RPC across Celestia, Osmosis, Injective, the Cosmos Hub and more — all under one key. Grab a free key and connect CosmJS to:

https://rpc.swiftnodes.io/rpc/<chain>?key=YOUR_API_KEY