Crypto derivatives research datasets
We collect and normalize each dataset ourselves, and we document its method. History starts at our first observation, with no synthetic backfill. Missing data shows as missing, never as zero.
Self-collected datasets
Status reflects the latest stored observation38.4% BTC 30D IV (Deribit DVOL, shown verbatim)
+0.0011% OI-weighted 1h rate · 25 venues
Basis vs index · BTC
UTC daily median-4.72 bpsBinance mark price against its own index price, in basis points. Positive means the perp traded above the index that day. Window starts 2026-09-25 · sweeps stored since 2026-07-16 · established series.
Median of 2,839 stored sweeps over the 30 days shown. 24 of 27 covered venues publish a mark price but no index price, so their basis is not computable and is left out — never shown as zero.
18/18 venues with complete order-book data this sweep
45+ perp venues · fee + spread + slippage from real depth
Total cost history · BTC $100k
6-hour sweepsFee + half-spread + price impact for one standardized $100,000 taker buy, at the base fee tier.
- Median across venues
Newest stored sweep: 2026-10-24 12:55 UTC, methodology v9. 39 venues had a ranked total cost for a $100,000 BTC buy. The median of those totals was 5.13 bps. The lowest was Lighter at 0.37 bps. 125 stored sweeps of this methodology start at 2026-09-23 12:00 UTC.
A venue that could not fill the order publishes no total cost, so it is left out of that sweep's median and its own line breaks. Gas and referral discounts are excluded.
Published reports
7 published · All reports · RSSIn ISO week 38 of 2026, the stored daily snapshots hold $1,446.54 billion of centralized perpetual volume. The perp-DEX protocols hold $153.65 billion over the same days, a share of 9.60 percent. The open-interest-weighted BTC funding rate held a median of 0.000890 percent per hour, or 7.80 percent at a simple annual rate. A $1,000,000 BTC perpetual order cost a median of 6.348 basis points across 950 order-book observations.
In ISO week 37 of 2026, the stored daily snapshots hold $1,300.02 billion of centralized perpetual volume. The perp-DEX protocols hold $129.50 billion over the same days, a share of 9.06 percent. The open-interest-weighted BTC funding rate held a median of 0.000677 percent per hour, or 5.93 percent at a simple annual rate. A $1,000,000 BTC perpetual order cost a median of 6.423 basis points across 756 order-book observations.
In ISO week 36 of 2026, the stored daily snapshots hold $1,413.29 billion of centralized perpetual volume. The perp-DEX protocols hold $140.45 billion over the same days, a share of 9.04 percent. The open-interest-weighted BTC funding rate held a median of 0.000709 percent per hour, or 6.21 percent at a simple annual rate. A $1,000,000 BTC perpetual order cost a median of 6.330 basis points across 537 order-book observations.
From 2026-09-12 12:00 UTC to 2026-09-23 06:00 UTC, PerpFinder stored 44 volume-quality sweeps under methodology version 3. In the latest sweep, 20 centralized perpetual venues reported $243.3 billion of 24-hour volume. 99.8 percent of the stored venue rows reached the $1,000,000 top of the standardized ladder, so the reported-to-support ratio ranks venues mostly by reported turnover and not by depth. The daily snapshots from 2026-07-01 to 2026-09-21 hold 28 venue-days above the 3× spike rule. This issue covers part of the quarter.
The PerpFinder Cost Index for September 2026 covers a partial month. It uses 43 stored 6-hour sweeps from 2026-09-12 12:00 UTC to 2026-09-23 00:00 UTC. For a $10,000 BTC market buy, Lighter had the lowest median all-in cost, 0.394 bps. Lighter also had the lowest $10,000 median for ETH (0.474 bps) and SOL (0.766 bps).
In ISO week 35 of 2026, the stored daily snapshots hold $1,476.96 billion of centralized perpetual volume. The perp-DEX protocols hold $158.87 billion over the same days, a share of 9.71 percent. The open-interest-weighted BTC funding rate held a median of 0.000796 percent per hour, or 6.98 percent at a simple annual rate. A $1,000,000 BTC perpetual order cost a median of 6.464 basis points across 926 order-book observations.
In the 2026-09-04 18:00 UTC sweep, 20 centralized perpetual venues reported $258.6 billion of 24-hour volume, and the same venues absorbed $15.0 million in total at the top of the standardized order ladder. That ladder stops at $1,000,000 per venue, and every venue reached the top rung, so the reported-to-support ratio ranks venues by reported turnover rather than by depth. Order size separates the books: 16 of 20 venues filled a $10,000,000 BTC order, and 7 of 20 filled $50,000,000 in the live walk on 2026-09-04.
Market tools
Live screeners over the same feeds — useful daily, not proprietary datasetsRelated data surfaces
The same order-book and funding collection feeds two public surfaces outside this hub. The RWA perpetual markets table applies it to stocks, forex and commodities traded on-chain, next to the TVL and assets ranking. The free embeddable widgets expose the funding, cost and liquidation views for any site, with no API key. The perp DEX vs CEX volume page shows the DEX share of perp volume for each stored day.
Methodology and trust
- How we test — ranking and testing method
- Data definitions — every metric, defined
- Corrections — how errors get fixed, on the record
Methodology changelog
- cost v9 (2026-09-23) — Paradex is read from the retail order book (GET /v1/orderbook/{market}/interactive), which includes Retail Price Improvement (RPI) orders. Paradex charges retail orders a 0 percent taker fee, and only retail orders can fill RPI orders. Up to v8 the Paradex row used the retail 0 percent fee with the Pro book (GET /v1/orderbook/{market}), which excludes RPI orders. The two inputs described different orders. On 2026-09-23 the BTC-USD-PERP Pro book had a full effective spread of 254 bps, so v8 rejected the row as invalid data (spread above 100 bps), and a 10,000 USD ETH buy cost 17.87 bps. In the retail book, the same 10,000 USD buys cost 1.05 bps (BTC) and 0.32 bps (ETH). The depth cap stays at 100 levels. Retail orders have a 300 ms speed bump; the engine does not model it. The engine does not measure a Pro Paradex order book: the api execution channel changes only the fee. All other venues, formulas and thresholds are unchanged. Historical v1 through v8 observations remain unchanged and separate from v9.
- cost v8 (2026-09-11) — Order-book VWAP now equals filled quote notional divided by filled base quantity for both buys and sells. The former quote-notional weighting counted price twice. Invalid prices, negative quantities and non-finite inputs cannot produce an executable quote. The 2 percent band, 99.5 percent fill threshold and effective touch are unchanged. UI rankings retain depth confidence and ranking eligibility. ALL-assets comparisons require the complete requested basket, apply pair-specific fee adjustments before averaging, and retain null costs for incomplete coverage. Historical v1 through v7 observations remain unchanged and separate from v8.
- volume-quality v3 (2026-09-11) — Observable slippage uses cost methodology v8, whose VWAP divides executed USD by executed base quantity. The sweep asserts that methodology before recording slippageBpsAt100k. Historical v1 and v2 observations remain unchanged and separate from v3.
- cost v7 (2026-09-10) — Avantis opening costs use the official v2 risk-engine spread quote. The request uses coin exposure, order size and trade direction. Spread percentages convert to basis points. Capacity follows the official SDK limits for total, group, pair, side and wallet open interest, plus published liquidity and block limits. Wallet capacity assumes a new position in an empty wallet. Existing wallet positions can reduce this limit. Pool quotes reject missing prices, fees, required capacity fields and source timestamps. Closed markets and zero capacity cannot fill a trade. Ostium rejects invalid bid/ask quotes. Gains rejects missing depth inputs. Favorable signed impact stays separate from adverse cost. Historical v1 through v6 observations remain unchanged and separate from v7.
- cost v6 (2026-09-04) — GMX v2 opening price impact is measured per order size. Until v5 the GMX row published only the oracle min/max half-spread, which is the same number at 100,000 and 10,000,000 USD, because the public GMX REST surface publishes no position-impact factors. The engine now calls the GMX Reader contract (0x470fbC46bcC0f16532691Df360A07d8Bf5ee0789) getExecutionPrice view against the on-chain DataStore (0xFD70de6b91282D8017aA4E741e9Ae325CAb992d8) on Arbitrum, over a public RPC with no key. That view runs the protocol own pricing code, so the published number carries the same positionImpactFactor, positionImpactExponentFactor and long/short open-interest imbalance the protocol would charge for this exact size and side, and it cannot drift from the protocol when GMX changes a parameter. priceImpactBps is now the signed deviation of the returned execution price from the oracle mid, which contains both the oracle entry side and the position impact; favorable impact is still floored at zero in slippage and total cost. slippageModel is onchain-position-impact-v2, slippageConfidence rises from low to medium, and GMX re-enters the headline ranking at every size. Measured on 2026-09-04 for a BTC buy in the BTC/USD [WBTC.b-USDC] pool: 0.00 bps at every size before, 2.64 bps at 100,000 USD, 3.17 bps at 1,000,000 USD and 7.60 bps at 10,000,000 USD after. Single-token GMX pools, where the long and short collateral token are the same, are excluded from the GMX row: they take no stablecoin collateral, so a USD-margined order there also pays a swap this ladder does not price, and GMX configures them with a near-zero impact factor. A failed on-chain read falls back to the labelled v5 oracle half-spread at low confidence and does not take a headline rank over 1,000,000 USD; it is never replaced by an invented number. Funding, borrowing, closing impact and network gas fees stay excluded. Historical v1, v2, v3, v4 and v5 points remain unchanged and must never be merged into a v6 series.
- cost v5 (2026-09-04) — Depth honesty release. (1) Hyperliquid is read at two book aggregations (nSigFigs 5 for the touch and half-spread, 4 — and 3 when 4 still cannot cover the size — for the deep walk) and merged: fine levels apply inside their own price range, coarser aggregated levels apply only beyond it and fill AT the aggregated level price; the coarse bucket that straddles the seam is dropped, which under-counts depth. Phemex (md/v2/fullbook), KuCoin (level2/snapshot), XT.COM (level=1000) and BingX (limit=1000) are now read at the API maximum, each proven by a live probe returning more levels. Every row carries depthFetchedUsd, and a row that cannot fill on a capped endpoint reports fillStatus beyond-fetched-depth instead of plain insufficient depth. (2) A depth-plausibility gate labels each row depthConfidence high or low: low when in-band depth on the walked side exceeds max(3x the venue own open interest for that market, 1.5x the deepest tier-1 book in the sweep), or when one level holds over 25 percent of in-band depth and exceeds the largest tier-1 level by 5x. Tier-1 is Binance, Bybit, OKX and Hyperliquid. Public order is sufficient-and-high, then sufficient-and-low, then insufficient. No venue is removed. (3) A row that cannot fill the order now publishes totalBps, slippageBps and vwap as null; the partial-fill numbers move to results[].partial. (4) GMX keeps its measured oracle entry cost but is labelled slippageConfidence low, because the GMX REST surface publishes no v2 position-impact factors; size-independent oracle rows leave the headline ranking over 1,000,000 USD and are labelled rankingEligible false. (5) The anchor price for oracle quotes is the median mid of the valid tier-1 books, with the median of all valid books as the fallback, and referenceMidSource states which was used. (6) The engine fee table is reconciled to the canonical venue registries (Aster 4, Crypto.com 4, Ondo 1/2.5, RISEx maker 1, Reya 3/3, SunX 4 bps) and a CI guard now fails on any drift between them. Historical v1, v2, v3 and v4 points remain unchanged and must never be merged into a v5 series.
- volume-quality v2 (2026-09-04) — Correction: slippageBpsAt100k is null when the 100,000 USD ladder row could not fill. v1 took the cost engine slippage figure with no sufficiency check, so a partial-fill VWAP was published beside maxSufficientFillUsd, which did check it. The number was not comparable with a complete fill. No other input, formula or threshold changed. Historical v1 points remain unchanged and must never be merged into a v2 series.
- volume-quality v2 (2026-09-05) — Coverage and labelling rule (no methodology version bump: no input, formula, threshold or stored value changes, so v2 observations stay comparable). A venue whose reported turnover PerpFinder cannot verify now enters an unverified tier (lib/volume-verification.ts) and is held out of every headline aggregate and every ranking until an editorial review removes the entry. The reported figure stays visible, muted and labelled, next to the dated observations behind it. The existing spike rule (above 3x a venue own 7-day median) is temporary by construction: once a large print becomes the venue own median the hold-out clears, so it cannot carry a venue whose figure has nothing to check it against. First entry, WEEX from 2026-09-05: no open-interest feed to verify reported turnover against; reported 24h volume ran 8-12x its own 7-day median on 2026-09-04/05; order-book depth within 270 bps measured at about 95 million USD against about 90 billion USD reported. These are measurements, not accusations, and PerpFinder makes no claim about why the figures differ. Historical v1 and v2 points remain unchanged.
- cost v4 (2026-08-03) — Favorable signed oracle impact is now separate from adverse execution cost. Slippage and total cost floor favorable impact at zero. GMTrade crypto position fees now use the documented 4 or 6 bps rate based on market balance. Historical v1, v2 and v3 points remain unchanged.
- cost v3 (2026-08-01) — Canonical all-in execution cost: fee + one-sided half-spread + VWAP impact beyond the effective touch. Adds explicit buy/sell semantics and BTC, ETH, SOL, XRP, BNB, DOGE and HYPE coverage. Historical v1/v2 points remain unchanged.
- options v1 (2026-07-16) — Initial: ATM=nearest-forward strike mean(call,put) mark IV; strike-curve skew ≥2 DTE; null-safe P/C; linear interval math.
- volume-quality v1 (2026-07-16) — Initial: venue-native reported volume vs order-book ladder ($10k–$1m, both flagship markets); winsorized p5/p95 percentiles; confidence = availability formula 30/20/30/20.
- funding v4 (2026-09-25) — Predicted rows now point at the next settlement strictly after the observation time. Hyperliquid info.predictedFundings reports nextFundingTime for its hourly HlPerp view as the start of the running hour, which has already passed; v1 to v3 stored that value, so every stored Hyperliquid predicted row (2,453 v2 and v3 rows and 2,974 v1 rows readable on 2026-09-25) had nextSettlementAt 7.0 to 52.5 minutes before its own sourceTimestamp, always on the hour. v4 adds one reported interval (60 minutes) when the reported time is not after the observation, and stores null for any other lag. dYdX now uses the next whole UTC hour strictly after the observation (Math.ceil returned the observation itself on the hour). Gate.io keeps funding_next_apply, which was 7.5 to 472.5 minutes ahead on every stored row; Kraken reports no settlement time and stays null. A predicted row whose settlement is not after its observation is invalid. Rates, intervals and normalization are unchanged, so hourly rates join across v2, v3 and v4. Stored v1 to v3 rows remain unchanged. The prediction-accuracy ledger reads v1 to v3 Hyperliquid predicted rows with a labelled reader correction of +1 interval only when nextSettlementAt is on the hour, not after sourceTimestamp and less than one interval before it; against realized settlements this alignment gave a mean absolute error of 0.0022 bps per hour versus 0.0185 (BTC) and 0.0139 (ETH) at +2 intervals, and no pairs at +0. The ledger now matches realized settlements and predictions over one shared window per venue and asset: realized settlements after the first usable stored prediction and not after the furthest settlement a stored prediction targets, inside a 30-day read window.
- funding v3 (2026-09-23) — Per-market funding intervals for every venue whose feed reports one. Aster (fundingInfo), BingX (fundingIntervalHours), HTX (settlement_period), Phemex (fundingInterval), Orderly (funding_period) and BloFin (fundingInterval) used a blanket 8h divisor, so their 1h markets read 8x too low and their 4h markets 2x too low. Hibachi settles hourly and is no longer divided by 8. Binance, Bybit, Bitget, Gate.io and KuCoin no longer fall back to 8h when the interval is missing: the market gets no rate. Rows keep rawRate, intervalHours and intervalSource. The sweep no longer assumes an interval for those venues. Crypto.com is reconstructed as hourly (was 8h), and Apex Omni, Bluefin, Hibachi and Kraken aggregate rows now use their documented hourly interval. BTC and ETH normalized rates did not change on the venues fixed here (all settle every 8h), but v2 Aster rows stored a raw rate and raw interval reconstructed from a wrong 1h assumption, and v2 Crypto.com rows from a wrong 8h assumption. Stored v1 and v2 points remain unchanged. Public readers (overview, history default, arbitrage spread, prediction ledger) join v2 and v3 on the hourly rates, which are comparable for BTC and ETH, and null the v2 Aster and Crypto.com raw fields; methodologyVersion=1|2|3 reads one version only. When only a venue interval request fails, a market uses its last reported interval up to 24 h old (intervalSource last-known); otherwise no rate. Audit: docs/funding-interval-audit.md.
- funding v2 (2026-09-12) — Current funding uses each OKX market timestamp interval and the MEXC bulk funding collectCycle. Raw rates and reported intervals are retained in sweep rows when available. Unknown intervals are omitted from the live matrix. Historical v1 points remain unchanged; current series use v2 only and v1 remains available by version.
- funding v1 (2026-07-16) — Initial: strict realized/current/predicted separation; linear per-period normalization with raw+interval preserved; prediction error vs last pre-settlement prediction with lead time.
- cost v2 (2026-07-25) — Effective-touch spread: bid/ask/mid and the slippage base are the first level with >=$5k cumulative notional, not the raw top of book. Raw tops are routinely dust ($12-$2.7k measured live), which understated 43% of venue-rows by >0.5 bps and let thin books advertise near-zero spreads. v1 rows remain stored under their own version.
- funding v1 (2026-07-17) — Coverage expansion (methodology unchanged): Gate.io added to the direct subset with current + predicted (funding_rate_indicative) + realized — third venue with both realized and predicted, making the prediction-accuracy gate (3 venues × ≥30 settlements) reachable ~2026-07-27.
- cost v1 (2026-07-17) — Initial: engine taker ladder persisted 4×/day — perp BTC/ETH/SOL/XRP × $10k/$100k/$1m + spot × $10k/$100k; per-venue fee/spread/VWAP-slippage/total bps, sufficiency and oracle flags verbatim from the audited engine.
- cost v1 (2026-07-18) — Coverage expansion (methodology unchanged): BNB/DOGE/HYPE added to both perp and spot ladders after per-venue probe verification (BNB 15 spot venues, DOGE 17, HYPE 12 + Hyperliquid native @107); venues without the pair are structurally unsupported, never "unavailable".
Method changes never rewrite history: a change gets a new version and a visible boundary marker.