A single implied-volatility number tells you almost nothing about the shape of a market. If you're pricing, hedging, or backtesting anything on Deribit options, what you actually need is the full picture across strikes and expiries: trades, order-book depth with Greeks attached, and how implied volatility varies across the whole surface, not just one headline figure. Deribit's own API gives you a real-time feed and a limited historical window, and that's often where the useful part of the research starts to run out.
This guide covers what Deribit historical options data contains, how it's captured, where to get it, and what tends to break research that treats it too casually. Written for quants and developers working with the data programmatically, not for people looking for a trading dashboard.
What Deribit historical options data actually includes
Deribit options data splits into three related pieces: trades, order-book depth with Greeks, and the volatility surface.
Trades are individual executions on an options instrument: timestamp, direction, size, fill price in BTC or ETH, plus the mark price and index price at the moment of the trade, and often the implied volatility at fill. Order-book data goes further than trades. It captures the resting bid and ask depth at each price level, typically alongside the Greeks (delta, gamma, vega, theta, rho) computed for the instrument at that snapshot, across multiple levels on both sides. Volatility surface data is the third piece: implied volatility by strike and expiry at a point in time, which is what actually lets you study skew, term structure, and how the market prices tail risk.
A dataset built only from a single "current IV" or last-price feed misses most of this. Anything involving hedging, spread construction, or comparing implied to realized volatility needs the surface, not a single point estimate.
| Endpoint | Key fields | Coverage | Typical use |
|---|---|---|---|
| GET /trades | timestamp_ms, trade_id, trade_seq, instrument_name, direction, amount, price, mark_price, index_price, iv, liquidation | BTC, ETH options | Execution research, volume analysis |
| GET /orderbook | 53 columns: mark price, Greeks (delta, gamma, vega, theta, rho), bid/ask price and size across 10 levels | BTC, ETH options | Slippage modeling, spread and depth research |
| GET /surface | snapshot timestamp, instrument name, expiry, strike, option type, underlying price, mark IV, bid/mid/ask, volume, open interest | BTC, ETH options | Skew and term-structure analysis, options pricing research |
Coverage today is BTC and ETH options specifically; futures and perpetuals aren't part of this dataset. Instrument names follow Deribit's own convention: {CURRENCY}-{DDMMMYY}-{STRIKE}-{C|P}, for example BTC-10AUG26-60000-P.
A single IV number vs. the full volatility surface
Deribit publishes DVOL, an implied-volatility index built the same way the VIX is built for equities: a 30-day forward-looking estimate of expected BTC or ETH volatility, derived from option prices. It's a genuinely useful single-number summary, and several providers, including Deribit itself, publish DVOL history directly.
It's not the same thing as a volatility surface, though. DVOL compresses an entire market's worth of options into one number per timestamp. A surface keeps the detail: implied volatility broken out by strike and expiry, which is what shows you the skew (why out-of-the-money puts often trade at a different IV than calls) and the term structure (why near-dated and far-dated volatility diverge). If your research question is "has volatility gone up," DVOL answers it well. If it's "which part of the curve moved, and does my hedge account for that," you need the surface. Worth checking exactly which one a provider is actually selling you before assuming they're interchangeable.
Deribit's official API vs. third-party providers
Deribit's own API doesn't gate historical market data behind identity verification the way some regulated exchanges do; the public endpoints are reachable without an account for a lot of what you'd want. The limits show up elsewhere. Recent trades and orders are only available without the historical parameter for a short window (minutes for orders, roughly a day for trades) before they age out of the live tier, and full-depth order-book history with Greeks attached isn't something the official API hands you in bulk at all. Rebuilding a clean, normalized time series still means paginating through the historical endpoints, computing or backfilling Greeks yourself, and storing the result somewhere.
That gap is what third-party providers fill, and they don't all fill it the same way. Some specialize in Deribit tick data captured across many venues with a shared client library. Some focus specifically on the options surface and Greeks, pre-computed. Some bundle Deribit alongside other prediction and derivatives venues under one schema, which matters if your research spans more than one exchange.
| Source type | Orderbook depth / Greeks | Setup effort | Best for |
|---|---|---|---|
| Deribit official API | Live book only; historical trades with a short live window, no bulk depth archive | You build storage, pagination, Greeks computation | Teams that already have derivatives data infrastructure |
| Tick-level multi-venue providers | Full L2 depth, options chain, quotes; Greeks depend on provider | Client library or downloadable files | Cross-exchange tick research |
| Options-analytics platforms | Pre-computed Greeks and IV surface, delivered via API or dashboard | API integration or dashboard access | Vol surface and skew research without building Greeks calculations yourself |
| Convex Lake | Trades, 10-level order book with Greeks, and a volatility surface endpoint, for BTC/ETH options | REST API, documented endpoints | Deribit market data research spanning prediction-market venues in one place |
How historical options data is captured and stored
Options data has a wrinkle that plain spot or futures data doesn't: Greeks and implied volatility aren't raw exchange fields, they're computed from an options pricing model applied to the observed price, the underlying, and time to expiry. Two providers capturing the exact same trade can report slightly different IV or delta if they use different pricing conventions or a different underlying reference price at the moment of calculation.
Capture itself follows the same two patterns as other tick data. Continuous polling or a persistent WebSocket connection records order-book state on a schedule or on every change; event-driven capture only writes when something moves. Either way, order-book depth is forward-only. A provider that started recording in 2026 has no way to reconstruct 2023's order book after the fact, even if it can backfill trade history from Deribit's own historical endpoints.
Storage format matters at scale here too. CSV is fine for a single expiry's chain; a full multi-year BTC and ETH options archive with Greeks across strikes gets large fast, and columnar formats compress and query better once you're past a few million rows.
Downloading and querying Deribit historical data via API
Convex Lake's Deribit historical data API returns CSV files for trades, order book, and volatility surface requests. A typical download flow:
- Get an API key on the Convex Lake dashboard and send it as
x-api-keyon every request. Volatility surface data specifically requires a Research or Pro key; trades and order-book access are available on lower tiers. - Pick an instrument or currency. Requests are scoped by currency (BTC or ETH) and, for a specific chain, an instrument name in Deribit's own format.
- Pull the file. Trades, order book, and surface each come as a downloadable CSV for the requested date and instrument.
- Store and join. Land the files and join on instrument name and timestamp if you're combining trades with order-book or surface data.
curl -O -J -H "x-api-key: do_YOUR_KEY" \ "https://api.convexlake.com/trades?exchange=deribit¤cy=btc&date=2026-08-10"
Exact parameters differ by endpoint. Check the API docs for the current /trades, /orderbook, and /surface reference, including which tier each requires, before building against it.
What's covered, and what isn't
Deribit itself lists a broader instrument set than most third-party historical archives actually capture: options, futures, and perpetuals across several currencies. Convex Lake's current Deribit coverage is BTC and ETH options specifically, which is where most of the volatility-surface and skew research questions live, but it means futures and perpetual data aren't part of this dataset today. If a research question needs futures funding history or a currency outside BTC/ETH, that's worth confirming with a provider before assuming coverage, rather than after building a pipeline around it.
Common research and backtesting use cases
Volatility surface research looks at skew and term structure over time: how far out-of-the-money puts trade relative to calls, and how near-dated implied volatility compares to far-dated. Backtesting a hedging or spread strategy means simulating fills against recorded order-book depth rather than assuming a fill at the mid, the same principle that applies to any execution-sensitive strategy. Comparing DVOL to realized volatility is a common signal for volatility risk premium research. Cross-asset and cross-exchange work often means lining up Deribit's options data against spot or futures pricing from Binance or another venue, or against prediction-market pricing for correlated events.
Data quality pitfalls to watch for
Pricing convention mismatches. Deribit options are priced and settled in the underlying coin (BTC or ETH), not USD, and different providers sometimes convert to USD notional differently. Confirm which convention a dataset uses before comparing prices or Greeks across sources.
Mark price, index price, and fill price aren't the same thing. A trade's execution price can differ meaningfully from the mark price used for margining, which in turn is distinct from the underlying index price. Conflating them in a backtest overstates or understates realized slippage depending on which one gets used where.
Instrument-name parsing. Deribit's compact instrument format is easy to parse incorrectly, especially around expiry date formats and strike precision. A silent parsing bug here quietly corrupts an entire chain rather than throwing an obvious error.
Greeks computed with different conventions. Greeks aren't a raw exchange field. Two datasets showing different deltas for the same instrument at the same timestamp may both be "correct" under different pricing-model assumptions.
Glossary: key terms in Deribit historical options data
Greeks are the sensitivities of an option's price to underlying inputs: delta (price vs. underlying price), gamma (delta vs. underlying price), vega (price vs. implied volatility), theta (price vs. time), and rho (price vs. interest rates). Implied volatility (IV) is the volatility level that, plugged into an options pricing model, reproduces the option's observed market price. DVOL is Deribit's own 30-day forward-looking implied volatility index. Volatility surface is implied volatility broken out by strike and expiry rather than compressed into one number. Mark price is the reference price used for margining and P&L, distinct from the last traded price. Index price is the underlying spot reference Deribit uses for settlement and margin calculations. Options chain is the full set of strikes and expiries available for an underlying at a point in time.
Historical data formats and delivery
CSV is the standard delivery format for Deribit trades, order book, and surface data, which suits both ad-hoc analysis and most backtesting pipelines without extra parsing work. JSON shows up mainly in live REST or WebSocket responses rather than bulk historical files. For a genuinely large Deribit historical data download, spanning years of tick-level order-book data across many instruments, a columnar format like Parquet compresses and queries noticeably better than raw CSV, though it's less universally supported out of the box.
FAQ
Does Deribit's own API include historical options data?
Yes, to a point. Deribit's historical endpoints cover trades and settlement data, but full order-book depth with Greeks isn't available in bulk from the exchange itself, which is the main reason a dedicated Deribit options data API from a third party is usually part of the stack.
What's the difference between DVOL and a volatility surface?
DVOL is a single 30-day forward-looking implied-volatility index, one number per timestamp. A volatility surface breaks implied volatility out by strike and expiry, which is what you need for skew or term-structure research rather than a single market-level summary.
Does Deribit historical options data require a verified account?
Not for the public market-data endpoints on Deribit's own API, and not for Convex Lake either: access there is a self-service API key, with volatility surface specifically requiring a Research or Pro plan.
Can I get Deribit futures and perpetual historical data the same way?
Not through Convex Lake currently; coverage there is BTC and ETH options specifically. Other providers cover futures and perpetuals alongside options if that's part of the research scope.
How far back does Deribit historical options data go?
It depends on the provider. Deribit as an exchange has offered options since 2016, but any specific historical archive, including order-book depth, only covers the period after that provider began capturing it.
What format is Deribit historical data delivered in?
Most providers, Convex Lake included, deliver historical trades, order book, and surface data as CSV files. JSON is more common for live API responses than for bulk historical downloads.
Getting started with Convex Lake's Deribit historical data
Convex Lake covers Deribit BTC and ETH options (trades, 10-level order book with Greeks, and volatility surface) alongside Kalshi, Polymarket, predict.fun, and Limitless under one API. See the API docs for the current endpoint reference, or create an account to get access.