SonarX

Indexed dYdXBlockchain Data

dYdX is the Cosmos appchain that runs the dYdX exchange, with perpetual markets, margin and liquidations as protocol modules and the order book held in validator memory rather than in blocks.

dYdX logo

How to query dYdX data with SonarX

Instant Data Share

Enabled on request

Snowflake, and file dumps to your object storage

Query dYdX blockchain data with plain SQL from a live database inside your own Snowflake account, populated with the indexed chain dataset. There is no pipeline to build and no second copy to store. The same dataset ships as file dumps to your own object storage for lakes and warehouses that are not Snowflake.

  • Full history as a Snowflake data-share
  • File dumps to S3 or your own object storage

Used for:

  • Analytics teams already on Snowflake that want dYdX data beside their existing tables
  • Fund accounting and treasury reporting that reconciles against a fixed history
  • Cross-chain questions answered in one SQL statement instead of one query per chain
  • Loading dYdX history into BigQuery, Databricks, Redshift or a Spark lake
  • Replacing a self-hosted indexer and the engineering time that keeps it running
  • Serving one governed dataset to several desks without copying it per team

Realtime API

Enabled on request

REST over the indexed dataset

Query indexed dYdX records over REST, reading the same dataset the share reads, with no warehouse in the path.

Used for:

  • Applications that need one answer rather than a table scan
  • Customer-facing screens where query latency is visible to a user
  • Services that have no data warehouse and do not want to run one
  • Prototyping against production data before committing to a share
  • Backend checks that run per request instead of per batch
  • Teams that want indexed dYdX data behind their own API layer

dYdX data: frequently asked questions

What is dYdX?

dYdX has produced its own blocks since 2023, when the exchange stopped running as contracts on another network and became a Cosmos SDK appchain. Validators run CometBFT under proof of stake, so a committed block is final immediately, DYDX is the staking and governance token, and accounts are bech32 strings carrying a dydx prefix. There is no general contract platform here: perpetual futures markets, margin, positions and liquidations are protocol modules, and traders hold collateral in subaccounts beneath a single address. The design decision that separates this chain from every other onchain venue is where the order book sits. Each validator keeps the book in memory and passes orders to its peers off chain, so placing or canceling an order is a message between validators rather than a transaction. The proposer writes only what matched.

dYdX data on SonarX

SonarX indexes what the chain commits: blocks and transactions with their typed messages, fills and clearing prices, subaccount collateral and open positions, funding payments, liquidations, IBC transfers and staking records. Margin here is USDC that arrived from Noble rather than an asset minted on this chain.

Full historical coverage is provisioned for dYdX on request.

How SonarX indexes dYdX

The order book never reaches a block, and that governs everything downstream. Because orders travel between validators off chain, a resting order, an amendment and a cancellation leave no trace in the chain’s history, so the venue is reconstructed from settlements and from the state the exchange modules keep. Depth and queue position at a past moment cannot be recovered, while fills, positions and liquidations are exact. Funding is the second consideration, since it accrues against open positions on a schedule instead of moving as a transfer, so a carry series is rebuilt from state nobody signed.

What teams build with dYdX data

Perp market-structure research is the first workload: funding and basis series, liquidation clustering, and fill distribution measured from the venue’s own settlements rather than sampled. Margin reconstruction is the second, following subaccount collateral against open positions through stress windows, which is a question about state rather than about trades. Provenance work is the third and is specific to this chain, because a fill here has a different evidentiary trail from a fill on Injective, where the orders themselves are protocol records. Fee and reward accounting is a fourth, since trading fees are distributed to validators and the accounts delegating to them rather than kept by an operator. DeFi analytics covers position-level work of this kind across chains.

Getting dYdX data from SonarX

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. dYdX coverage is provisioned on request, so tell us the history depth and the delivery target and we will scope it. Say which markets matter, because scoping by market beats taking the venue whole. The published coverage matrix for every network SonarX indexes lives in the data documentation, and the rest of the catalogue is at all indexed chains.

Is there a dYdX data API?

APIs over indexed dYdX data are enabled on request: the same indexed dataset the Snowflake share reads, served over REST once provisioned. Tell us the lookup pattern you need.

How do I get dYdX data into Snowflake?

SonarX provisions a data-share into your own Snowflake account. The share appears as a database you query with SQL, so there is no pipeline to build and no second copy to store, and it stays current as SonarX advances the indexing pipeline.

How far back does dYdX coverage go?

The historical data-share and file delivery cover this chain's recorded history from its 2023 genesis forward, and are provisioned on request. Markets have been listed and delisted since then, so an individual market's history can be much shorter than the chain's, and the share is scoped against the markets an analysis actually needs.

Do dYdX records include resting orders and cancellations?

No, and this is the first thing to plan around. Orders and cancellations are exchanged between validators off chain and never enter a block, so the chain records the matches, the resulting positions and the funding they accrue. Order-book depth and queue position at a past moment cannot be recovered from chain history, while every fill and every liquidation can be.

dYdX logo

Get dYdX data from SonarX