Options Data Methodology

Version 1 covers Deribit only — the venue holding the large majority of listed BTC/ETH options open interest. Cross-venue aggregation (OKX, Binance, Bybit options) is planned and will be documented here before it ships; we would rather show one venue correctly than blend venues silently.

• public/get_book_summary_by_currency?currency=BTC|ETH&kind=option — the full option universe in one call. Fields used: instrument_name (parsed into expiry, strike, call/put), mark_iv (percent), open_interest and volume (both in base-currency contracts; 1 contract = 1 BTC/ETH), volume_usd (24h traded premium in USD — verified, not notional), underlying_price (the per-expiry forward) and creation_timestamp.
• public/get_volatility_index_data— Deribit's DVOL index (1-minute candles). We display the latest close.
• public/get_index_price?index_name=btc_usd|eth_usd — spot index.

Refresh cadence: our server queries Deribit at most every 2 minutes (6 requests per refresh) and the dashboard polls on the same interval, well inside the venue's public rate limits. Historical depth in v1 is the venue's own (we snapshot nothing yet); a self-owned history series is planned.

• Venue-reported: mark IV, open interest (contracts), 24h volume (contracts), 24h premium volume (USD), DVOL, forward and spot prices.
• Computed by PerpFinder: USD open interest (contracts × the expiry's forward), notional volume (contracts × forward), put/call ratios, ATM term structure and the strike IV curve. Every computed figure follows a formula on this page.
• DVOL is Deribit's index, not ours. It is always labeled “Deribit DVOL” with the venue named. PerpFinder does not currently publish an implied-volatility index of its own; if we ever do, it will carry its own name (e.g. a “PerpFinder Implied Volatility Index”) and its formula, inputs and validation will be documented here before launch.
• Bid/ask IV and greeks are not shown in v1. Deribit exposes them only per instrument (≈1,600 extra requests per refresh), so v1 uses mark IV alone rather than sampling a subset and calling it complete. This also means a true 25-delta skew is out of scope — the skew chart is an honest strike-based curve.

• ATM IV per expiry: the strike closest to that expiry's forward price; the point is the mean of the call and put mark IV at that strike (or the one side that exists, flagged internally). Expiries with no valid IV are omitted, not interpolated.
• Put/call volume ratio: put contracts traded (24h) ÷ call contracts traded. Put/call OI ratio: put OI notional ÷ call OI notional. A zero denominator renders as a dash — never 0, never infinity.
• Skew chart: mark IV per strike for the nearest expiry at least 2 days out (expiry-day quotes are noise), strikes clipped to 0.5–1.6× the forward.
• Next major expiry: the future expiry with the largest open-interest notional.

Rows failing validation are dropped and counted (the count is in the API payload), never patched:

• strike ≤ 0, malformed instrument names, unknown option type
• expired or same-moment expiries (settlement is 08:00 UTC)
• venue timestamps more than 5 minutes in the future
• duplicate venue/instrument rows (freshest timestamp wins)
• mark IV ≤ 0 or ≥ 1000% → the row keeps its real OI/volume but its IV becomes null and is excluded from curves
• missing/zero forward price → row dropped (USD conversion would be fiction)

Freshness statuses: live (≤5 min), delayed (≤15 min), stale (older, served from the last good payload during venue outages), partial (one asset failed), unavailable (nothing served — the UI says so instead of showing zeros).

• Single venue (Deribit). Deribit-specific quirks — instrument granularity, mark model — carry through.
• Mark IV is the venue's model output; wide markets can put true tradable IV meaningfully away from mark.
• USD open interest uses the current forward, so it moves with price even when contract counts don't.
• No options history of our own yet — charts show current state, not time series.

Since 2026-07-16 PerpFinder snapshots this market itself — venues only retain days-to-weeks of options state, so the series has to be owned to exist. What we do, exactly:

• Frequency: a full snapshot every 15 minutes (raw instrument level and market aggregates together — both come from the same bulk response), plus one daily summary per asset after the UTC day closes. Intraday points are genuinely intraday; daily rows are computed from them, never claimed beyond their coverage.
• Raw layer (append-only): the venue's bulk response is stored verbatim — every instrument with strike, expiry, mark IV, volumes, open interest, the premium bid/ask fields, plus schema/normalizer versions and validation status. Historical raw snapshots are never rewritten when methods change; new methods get a new methodologyVersion and can be replayed against old raw data.
• Two timestamps, never conflated: sourceTimestamp is the market time reported by the venue; ingestedAt is when we stored it. Aggregates additionally carry their bucket (intervalStart) and generatedAt. Future-dated or frozen repeated responses are flagged, not stored as fresh.
• Partial/stale handling: a snapshot missing calls or puts produces no put/call ratio; insufficient IV produces no ATM point; days with under 70% intraday coverage are marked partial. Missing data is never zero-filled.
• Volume semantics: the venue reports rolling 24h volume, so daily rows store that window's close and mean — rolling windows are not summable into a daily flow, and we don't pretend otherwise.
• No synthetic backfill: history begins at our first observed datapoint. Nothing before it is reconstructed from today's contracts, and if we ever import venue-provided history (e.g. DVOL candles predate our collection) it will be marked as imported, separately from observed data.
• Retention: full-frequency raw ≥90 days minimum (nothing is deleted until derived regeneration is proven), intraday and daily aggregates permanent. Current volume: ~7 MB/day of compressed raw data.
• Maturity gating: historical charts appear only when a series is established (≥7 days and sufficient observations); before that the dashboard shows collection status with the first-observation date instead of drawing a two-point “trend”.

Found an error? Use the correction policy. The pipeline is run by PerpFinder Data Team, editorial content by PerpFinder Research, reviewed by PerpFinder Editorial Review. Primary sources: docs.deribit.com(API reference) and Deribit's DVOL documentation. Market data © Deribit, displayed with attribution.