dYdX RPC: Querying a Decentralized Perpetuals Exchange

dYdX Chain is one of the more architecturally distinctive chains in the Cosmos ecosystem, because the entire chain exists to serve a single application: a decentralized perpetual-futures exchange. The orderbook is off-chain, settlement is on-chain, and the validators themselves run the matching engine. Developers who connect an RPC endpoint to dYdX often expect a standard Cosmos pattern and miss the parts that make it different. Here's the map.

What dYdX actually does

dYdX is a decentralized perpetual-futures exchange built on the Cosmos SDK with CometBFT consensus. The pitch: trade perpetual contracts with the speed of a centralized exchange, but keep your funds in self-custody. The chain handles order matching, trade settlement, liquidations, and funding rate calculations — all on-chain, all with sub-second block times.

The numbers as of September 2026: $1.6 trillion in lifetime trading volume, 99+ listed markets, and open interest in the tens of millions. The chain migrated from an Ethereum L2 (dYdX v3, StarkEx-powered) to a sovereign Cosmos SDK appchain (dYdX v4) on October 27, 2023. The migration was driven by the need for lower latency, higher throughput, and full control over the execution environment — things that are hard to achieve when your settlement layer is someone else's chain.

The architecture has three layers:

1. Off-chain orderbook: Each validator runs an in-memory orderbook. Orders are gossiped peer-to-peer and matched locally. This is what gives dYdX its speed — matching happens in memory, not through consensus.
2. On-chain settlement: When orders match, the resulting trades are proposed as transactions and committed through CometBFT consensus. This is where the chain comes in — recording trades, updating positions, handling liquidations.
3. Indexer API: A separate indexer aggregates on-chain state into a queryable API for the frontend. Most users and dashboards read from the indexer, not directly from the chain.

Perpetuals are margined in Noble USDC bridged onto the chain via IBC. The native DYDX token (18 decimals, base denom adydx) is used for staking and governance — not as trading collateral.

The RPC: CometBFT JSON-RPC, same as other Cosmos chains

dYdX Chain runs on dydx-mainnet-1, uses CometBFT v0.38.x, has sub-second blocks (~0.7s in practice), and exposes the standard CometBFT JSON-RPC surface. No eth_*, no EVM. The chain ID is the string dydx-mainnet-1, not a numeric EVM ID.

SwiftNodes serves the CometBFT JSON-RPC endpoint:

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

The core methods you'll use:

These are the consensus-layer queries — reading blocks, monitoring chain activity, broadcasting transactions. They work the same way across every Cosmos chain.

Where the special part lives: dYdX modules

Here's where dYdX diverges from a plain Cosmos chain. The trading state — perpetual markets, positions, orders, fills — lives in dYdX-specific protobuf modules. You query these through abci_query with the module's gRPC query path, or (more commonly) through the dYdX Indexer API that wraps these queries.

The practical split:

• Consensus RPC (CometBFT) — reading blocks, monitoring the chain, broadcasting standard transactions. This is what a flat-rate RPC endpoint gives you.
• Module queries (abci_query) — reading trading state (positions, markets, orderbook state). Requires protobuf-encoded request data.
• Indexer API — the high-level query layer that most frontends and dashboards use. Wraps the module queries with a friendlier REST interface.

If you're building a trading bot, a position tracker, or a liquidation monitor, you'll typically use the Indexer API for market data and positions, and the CometBFT RPC for broadcasting transactions and monitoring block-level events. The Indexer API is maintained by the dYdX team and reads from the chain — it's not a separate service you need to run yourself.

How this compares to other Cosmos chains

dYdX shares the CometBFT RPC surface with every other Cosmos chain, but the application layer is where it diverges. Injective also puts an orderbook in modules — but Injective's orderbook is fully on-chain (orders are transactions). dYdX's orderbook is off-chain (orders are gossiped, matched in memory, then settled on-chain). The difference matters for latency: dYdX can match orders in microseconds because matching doesn't wait for consensus; Injective's matching waits for the next block.

Osmosis puts a spot DEX in modules. Celestia is a data availability layer. dYdX is a perpetuals exchange. The pattern is the same — Cosmos SDK modules extend the base chain with application-specific state — but the domain is different each time.

Finality and block structure

dYdX has single-block deterministic finality via CometBFT BFT consensus — once a block is committed by the validator set, it's final. No reorgs, no probabilistic confirmation waits. With sub-second block times, trades settle in under a second from order placement to on-chain confirmation.

For an indexer, this means you can trust a committed block immediately. Read blocks via block, transaction results via block_results. The same reorg-handling patterns you'd build for probabilistic chains like Ethereum don't apply here — once it's committed, it's done.

The fast block times also mean higher block volume. At ~0.7s per block, dYdX produces roughly 125,000 blocks per day — more than Ethereum's ~7,200. If you're indexing every block, plan for the throughput.

The short version

dYdX Chain is a decentralized perpetual-futures exchange built on the Cosmos SDK. Its RPC is CometBFT JSON-RPC — the same surface as every other Cosmos chain. Use status, block, block_results, and tx to read chain state. Use abci_query with dYdX-specific module paths (dydxprotocol.clob, dydxprotocol.perpetuals, dydxprotocol.subaccounts) to read trading state, or use the dYdX Indexer API for a higher-level interface. The orderbook is off-chain (gossiped and matched in memory by validators); settlement is on-chain. It has single-block BFT finality, sub-second blocks, Noble USDC for margin, and the DYDX token (18 decimals) for staking and governance.

For monitoring dYdX chain activity, tracking trading state, or broadcasting transactions, you need a reliable CometBFT endpoint. A flat-rate dYdX RPC endpoint gives you that across load-balanced nodes, alongside 74 other chains under one key. Grab a free key and point your app at:

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