- BTC ·
ETH · SOL · XRPAssets - 5m ·
15m · 1h · 1dTimeframes - UP +
DOWN eachTokens - UniformSchema
The crypto dataset is a grid: four coins by four timeframes, each cell a stream of full-depth order-book snapshots. The reason a single loader can walk the entire grid is that every market is keyed the same way and every snapshot carries the same fields. Learn the keying once and the whole panel opens up.
A cross-asset panel only works if the pieces fit together without bespoke handling. Here the pieces are uniform by design: BTC, ETH, SOL and XRP each run on 5m, 15m, 1h and 1d cadences, every market resolves to a condition id, and every snapshot has identical fields regardless of which coin or timeframe produced it.
How a market is keyed
conditionId
The canonical 0x identifier for a market. Everything, snapshots, summaries, orderbooks, hangs off this key.
- 0x condition id
- Stable across queries
- The real primary key
UP + DOWN tokens
Each market has two tradable tokens with their own books. You query a side explicitly when pulling history.
- Two tokens per market
- side = UP or DOWN
- Separate ladders
Human-friendly slug
A slug like btc-updown-5m is the readable alias. Resolve it to a conditionId before pulling data.
- btc-updown-5m
- by-slug lookup
- Alias, not the key
The slug is convenient but the conditionId is canonical. A typical loader takes a slug, resolves it once to a conditionId, then issues every subsequent request against that id, so a renamed or re-listed slug never breaks the pull.
Enumerating the grid
You do not hard-code market ids. Two endpoints enumerate the grid for you: one for what is trading now, one for what has already closed. Closed markets stay queryable, so an enumeration over history has no survivorship bias, the markets that resolved and disappeared from the live list are still there to pull.
- 1Call /v1/markets/live to enumerate every currently active crypto market across all four coins and timeframes.
- 2Call /v1/markets/history/recent to pull markets that have already closed, these remain in the archive, not dropped.
- 3For each market, resolve the slug to a conditionId if you started from a slug, then note its UP and DOWN tokens.
- 4Iterate the conditionIds, pulling /v1/markets/:id/snapshots per side, the same call shape for every cell of the grid.
Why one loader serves everything
best_bidbest_askTouch, identical across coinsmid_pricespreadDerived fields, pre-computedbid_depth_totalask_depth_totalResting size per side- bids[] ·
asks[]Full ladder when include_book is set
Because a SOL 1h snapshot has the same columns as a BTC 5m snapshot, the parsing code is written once. The only things that vary between cells of the grid are the conditionId you point at and the cadence of the underlying market. That uniformity is what turns four-by-four into a single tidy panel.
Closed markets stay in the archive
Short-dated crypto markets resolve constantly. If only the survivors were queryable, any cross-asset study would be skewed toward markets that happened to stay open. Because closed markets remain queryable through the history endpoint, you can enumerate the full population, winners and losers alike.
Building a cross-asset panel
- Tag every row with its coin, timeframe and side so the flattened panel stays self-describing after the join.
- Align across coins on timestamp, all feeds are UTC at millisecond precision, so a common time index lines them up.
- Treat 5m and 1d markets differently in analysis: they share a schema but a 5m market churns through far more conditionIds over a week.
- Remember depth is resting size, not executed volume, uniform across coins, but still a proxy for intent, not fills.
Four coins, four timeframes, one schema. The grid is large, but you only ever learn to read one snapshot.
Walk the whole grid
The dashboard shows every live crypto market; the docs cover the enumeration and snapshot endpoints you loop over.
Frequently asked questions
How is a crypto market identified in the dataset?
By a 0x conditionId, which is the canonical key for every query. Each market also has two tokens, UP and DOWN, with separate order books, and a human-friendly slug like btc-updown-5m that resolves to the conditionId. You point snapshot, summary and orderbook calls at the conditionId.
How do I list every available crypto market?
Use /v1/markets/live to enumerate the currently active markets across BTC, ETH, SOL and XRP on all four timeframes, and /v1/markets/history/recent to pull markets that have already closed. Closed markets stay queryable, so enumerating history gives you the full population without survivorship bias.
Why can one loader handle all four coins and timeframes?
Every snapshot carries the same fields, best_bid, best_ask, mid_price, spread, the depth totals, and the full ladder when requested, no matter which coin or cadence produced it. The parsing is written once; only the conditionId you target changes from cell to cell of the grid.
Do shorter timeframes have the same schema as daily markets?
Yes. A 5m market and a 1d market share an identical snapshot schema. The difference is volume and lifecycle, a 5m market resolves and is replaced far more often, so over a week it spans many more conditionIds than a 1d market does.