Editorial · By Stephan Kulik · Updated 2026-09-09

Data definitions

This page is the contract behind every number on the site: what each dataset is, where it is fetched from, how often it moves, and which automated check fails when it drifts. The methodology explains the editorial rules; this page explains the plumbing.

The two dates on every page

Each content page ends with a provenance block carrying two dates that mean different things, and they are never conflated.

• Editorial review · updated. The last shipped change to the page’s own text. A scheduled check compares this date with the page’s commit history and fails if it trails by more than seven days, so it cannot silently go stale.
• Facts verified. The date the page’s venue facts were checked against official documentation, with the source named. It moves only when a human re-verifies. Fee and rate stamps fall due for re-check after 90 days, review prose after 180; past the window the stamp itself turns to “re-check due” rather than pretending otherwise.
• Live data. Whether the page’s moving figures are fetched in your browser, rendered from a dated weekly snapshot, both, or absent. Automatic refreshes are labelled as automatic; they are not an editorial review.

Fetched live in your browser

Live figures come straight from each venue’s public API in your browser — never through our servers and never from a third-party aggregator. If a fetch fails, the page shows the failure instead of a substitute number.

Weekly snapshots, committed to the repository

Three datasets are refreshed by scheduled pipelines that open a pull request with the new file. Every refresh validates before it writes, so a bad response leaves the previous snapshot in place and turns the run red. A daily check fails if any snapshot is older than ten days.

Hand-verified data files

Everything that does not move minute to minute lives in typed data files that pages read from, so a figure is stated once and rendered everywhere. Each carries its verification date and source; components may not hard-code a rate or an outbound link.

• fee-comparison.ts — Base maker/taker rates, tiers and discounts for twelve venues. Each row carries the date it was checked against the venue’s fee documentation.
• feature-comparison.ts — Product surface per venue (trading model, spot, non-crypto markets, login and KYC, collateral), each cell linked to its source.
• earning-comparison.ts — Six income strategies across five venues; every cell cites the site page carrying the verified claim, and unverified cells say so.
• strategy-catalog.ts — The scenarios behind the earning tools. May only restate claims already verified on an existing page.
• venue-status.ts — Operational notices (halts, incidents) rendered on a venue’s hub and comparison pages, with a staleness monitor.
• affiliate-links.ts — The single registry of outbound referral links. An entry marked pending renders the venue’s official URL instead.

The checks that watch all of this

On every pull request, in order, and any failure blocks the merge:

• Strict type check and a full production build.
• Link integrity across the built site; every key page must exist; every page in an indexed section must be listed in llms.txt; the provenance block must be present on every content page.
• Market-symbol normalisation, funding-history cadence, chart mathematics and motion rules, the 11 px type floor, live-request de-duplication, and title length.

Daily at 06:17 UTC, on a schedule so the pull-request gate stays fast:

• Every live API contract above: HTTP 200, open CORS, the exact fields the islands read, and the identity pins (the HLP address still resolves to HLP, Lighter market 1 is still BTC).
• Venue-status freshness, snapshot age against the ten-day limit, and the editorial-stamp drift check described above.

Known limits

• Visible order-book depth is what each venue publishes, not total liquidity; a low slippage figure on a shallow published book is why the execution-cost tool shows how much of that depth an order consumes.
• “24h volume” is defined differently by each venue; the site labels each figure’s method rather than ranking them as comparable.
• Reported volume can include wash trading. Where a venue’s own figures are in question the hub says so, as on the Aster review.
• Venue-reported yields (vault and pool APRs) are shown as the venue publishes them and are not independently measured.
• Funding history is charted only for venues with an hourly-native series; the comparison chart shares one axis so bar heights are comparable.

Open data

Three JSON files are published for other publishers, researchers and answer engines. Each is built from the same committed or hand-verified data the pages use, carries a schema id, a build timestamp and the snapshot's own date, and is served with open CORS so a browser on any site can fetch it. They are rebuilt on every deploy; the snapshots behind them refresh weekly.

• Endpoint

  /api/v1/markets.json · perpdexguide.markets/1

  Contents

  every perp market across the seven tracked venues, one entry per asset: per-venue symbol, published max leverage and its basis, contract scale, venue-published name and categories, and the market page URL

  Source

  venue-markets.json (weekly, fail-closed refresh; ten-day staleness guard)

• Endpoint

  /api/v1/fees.json · perpdexguide.fees/1

  Contents

  base-tier maker and taker rates for the twelve venues on the fee comparison, as display strings and decimals, with the fee model, discount paths, caveats, the dated source page and its verification date

  Source

  fee-comparison.ts (hand-verified against official docs; each row dated)

• Endpoint

  /api/v1/funding-history.json · perpdexguide.funding-history/1

  Contents

  seven days of hourly funding, per venue and coin, for the venues with an hourly-native history (Hyperliquid, dYdX)

  Source

  funding-history.json (weekly, fail-closed refresh; cadence guard pins the hourly period)

Licence. The data is free to republish with a visible "Data: PerpDEX Guide" link to perpdexguide.com; every payload repeats this in its attribution block. Editorial content — reviews, guides, comparisons — is all rights reserved. The schema id changes only when a field's meaning changes; new fields may be added without a version bump.

Embeddable fee table

/embed/fees/ renders the base-tier fee table with no site chrome, for use in an iframe. The "Data: PerpDEX Guide" link inside it is the licence condition and must stay visible. Add ?theme=light or ?theme=dark to force a theme; by default it follows the viewer's system setting.

<iframe src="https://perpdexguide.com/embed/fees/" title="Perp DEX fees — Data: PerpDEX Guide" width="100%" height="420" loading="lazy" style="border:0"></iframe>

Errors are logged on the corrections page. To report one, write to [email protected].