Where every number comes from.
This page is the supply chain behind everything we publish: which venues we ingest, how the liquidation feed is independently reconciled, how open interest and funding are aggregated, how the model is graded historical, and what happens to a symbol that stops clearing the bar. Every specific here is a mechanism running in production today, dated, with the live values one click away.
1 · The venue plane: what we ingest
The coverage universe is the union of perpetual markets across 15 tracked venues: Bybit, OKX, Binance, Hyperliquid, Kraken Futures, BitMEX, Bitget, Gate.io, HTX, MEXC, BingX, Bitfinex, Phemex, dYdX and CoinEx. It is our own aggregate, built from direct venue connections, not a reseller's feed. A 16th venue (Coinbase INTX) is ingested for internal completeness but is stripped from every public surface per its redistribution terms, so public venue counts never include it.
The union snapshot built 2026-08-19 covered 2,172 perpetual markets. Each market carries per-venue price, open interest, funding and 24h volume, plus a cross-venue aggregate with a tier label (liquid, multi-venue, single-venue) computed from measured open interest.
Source of record: the live multi-venue perp snapshot, rebuilt continuously; the union basis text above is quoted from its own disclosure block. As of 2026-08-19.2 · The liquidation-event plane: independently reconciled
Exchange liquidation feeds are easy to claim and hard to prove. So we audit our own: a reconciliation harness checks each venue's ingested events against an independent reference surface the venue's own streaming connection cannot influence, on a 5-minute cadence, over a trailing 60-minute comparison window, and publishes rolling 7-day verdicts with sample sizes and Wilson confidence floors.
2·1Coverage, stated exactly
As of 2026-08-19, 11 of the 15 tracked venues carry independent liquidation-event reconciliation; those 11 are the complete measured set, and the wider OI/funding coverage is never implied to be reconciliation-measured. The reconciliation harness has run continuously since 2026-05-10.
The reference method is disclosed per venue, because "independent" means something different at each one:
| Venue | Independent reference method |
|---|---|
| OKX | Direct REST liquidation-orders event-level reconciliation |
| Deribit | Event-level REST reconciliation against the public trade tape (liquidation flag) plus feed-liveness verified silence |
| Kraken Futures | Event-level public feed capture with independent OI corroboration via Kraken's public tickers REST (separate infrastructure from the stream) |
| BitMEX | Real-time integrity spot-check: our event-level tape cross-checked against BitMEX's public REST active-liquidation snapshot |
| Bybit | Open-interest-signature confidence-interval check (no clean public REST liquidation endpoint exists at any tier) |
| Binance | Open-interest-signature confidence-interval check (Binance's public REST liquidation endpoints are geo-blocked or discontinued from our region; the OI-history endpoint is independent of the streaming broker) |
| Hyperliquid | Addressable non-HLP vault-fill capture with independent OI corroboration; the HLP-vault side is structurally unmeasurable via public APIs and carried as a coverage caveat, never as a failure |
2·2The measured result, worst venue first
Over the rolling 7-day window as of 2026-08-19, the worst-measured venue is Deribit at 98.42% clean (n = 30,197 assessable reconciliation runs, Wilson 95% lower bound 98.27%). The other ten measured venues sit at 99.92% or better (n ≈ 50,400 assessable runs each; per-venue Wilson 95% lower bounds are published beside every score). Reconcile accuracy is the share of assessable checks whose verdict was clean; windows that cannot be verified at all are published as coverage gaps, never counted as failures and never counted as successes.
Source of record: the reconciliation state journal's rolling-7-day block, written by the reconciliation harness every 5 minutes; republished verbatim (never re-derived) by /trust and /feeds/trust.3 · The open-interest and funding plane
Cross-venue open interest is summed only over unit-verified USD venues: each venue's OI is honesty-checked for its unit convention (USD-direct, coin times mark price, or contracts times contract size times mark) before it is allowed into an aggregate. Where a venue's OI cannot be unit-verified it is kept raw and excluded from sums: Binance OI is per-symbol only (bulk figures omitted), Kraken OI is unit-unverified (kept raw, never summed). Absences are shown, never faked.
Funding rates are annualized per venue interval (1-hour on dYdX, Hyperliquid and Kraken; 4-hour or 8-hour per symbol on Gate and Phemex; 8-hour on most others), because raw funding prints at different intervals are not comparable. The aggregate carries the per-venue annualized figures plus mean, spread and price dispersion, so the mix is always inspectable.
Basis text quoted from the multi-venue snapshot's own disclosure (its published basis field), rebuilt continuously. As of 2026-08-19.4 · The model pipeline: snapshot, grade, gate
4·1Snapshots: the model's inputs, journaled every 5 minutes
A snapshot pipeline writes the liquidation-density ladder (7 leverage bands × 2 sides, peak mass per band) to an append-only journal every 5 minutes, per symbol. The 5-minute cadence is deliberate: the slowest input (the long/short account-ratio) only refreshes every 5 minutes, so 5 minutes is the accuracy ceiling. The live journal is bounded to 7 days; aged-out rows are archived to gzipped segments and synced off-box, so the record is never deleted, only rotated.
Source of record: the snapshot pipeline's append-only journal, with aged-out rows kept in gzipped archive segments synced off-box. Cadence fixed since 2026-06-18.4·2Historical grading: scored only on what came after
The calibration harness replays each historical liquidation event's prior one-hour window through the model exactly as its inputs stood at that moment, then scores the prediction against the events that subsequently occurred. Parameter selection and scoring never touch the same data; every published rate carries its sample size (n) and a Wilson 95% lower bound computed on the de-overlapped effective n. The full metric contract is frozen at /methodology, with a public changelog of every revision.
Source of record: the historical calibration harness; live per-symbol values on /proof.4·3Kill-gates: symbols below the bar stay on the ledger
Any symbol whose public record falls below the release bar is auto-disabled: the model stops serving it, and the symbol is displayed as off everywhere it appears, including the public proof page, with the record of why. The verdict binds only on an adequate sample: each symbol's n and Wilson 95% lower bound are published beside its state, and a small-sample symbol is labeled insufficient-data rather than carrying a verdict. Re-enabling requires recovering above the bar across consecutive clean calibration cycles. Disabled symbols are never hidden from the ledger; a dashboard that only shows its winners is not publishing a record.
Strategy promotions clear one gate, implemented once in the shared calibration library: net_usd > 0 and ci95_low > 0, measured historical. The gate has fired against the house's own models on the record (two retirements in July 2026, journaled with full numbers; see /methodology section 7).
Current per-symbol status (including every disabled symbol) live on /proof.5 · The publication plane: receipts, not renderings
Every published number is served from a measurement artifact, byte-equivalent: the rate, its n, its Wilson lower bound and the time it was measured are written by the measurement loop and read back verbatim, never re-derived at render time. When an artifact is missing or stale the surface fails closed ("accuracy data temporarily unavailable; we don't estimate") rather than interpolating a plausible figure. The measurement journals are append-only: losing streaks, downgrades and disabled symbols stay on the record permanently.
Inspect the plane directly: /accuracy, /proof, /trust, and the machine-readable /feeds/trust.6 · Reliability and uptime: what we publish today
Desks ask for an SLA. Here is exactly what exists, and what deliberately does not.
Measured uptime, from the external monitor's own probe history
We do not print an uptime percentage we cannot source. The external monitor's history turned out to be machine-readable, so this figure is computed from it, not asserted: 99.95% uptime for hunterkiller.io over the monitor's full history, 2026-07-03 through 2026-08-19 (n = 48 daily measurements, about 13,800 probes per monitor at its 5-minute cadence; worst single day 97.53% on 2026-07-22). The monitor's second probe, against the API health endpoint, reads 97.98% over the same window: its first day (2026-07-03, the day the monitor was created, only a partial day of probes) scored 3.40%, and 2026-08-03 scored 99.65%, the same site-down event the on-box guard records below. Both monitors are published, including the ugly day.
The monitoring behind the figure
External, off-box: an independent third-party monitor probes the public site on a 5-minute cadence and publishes the results on a public status page: stats.uptimerobot.com/Gls2Na9d2T. That page, not our own infrastructure, is the source of truth for "is it me or them".
On-box, self-healing: a site-uptime guard runs continuously on the host. It probes the public root through the full serving chain, and on failure it repairs serving automatically (recreating the release tree, reloading the edge) and re-verifies independently before declaring health; it only ever restores public serving. Its state file records the most recent detected site-down event as 2026-08-03; current state is healthy.
The data plane, measured continuously: the feed-reconciliation figures in section 2 are the service's own data-quality measurement: worst venue 98.42% clean over the rolling 7 days (n = 30,197, Wilson 95% lower bound 98.27%), every other measured venue at 99.92% or better, recomputed every 5 minutes and published with sample sizes on /trust.
The commitment
The figure above is a measured historical record, not a contracted SLO: no guaranteed service level is sold yet. When a formal SLO is published it will keep this same standard, computed from the external monitor's probe history over a stated window with the probe count shown, never self-asserted. Until then, the status page and the trust board are the honest answer.
Sources: the external monitor's daily probe ratios (UptimeRobot, third party, off our infrastructure; read 2026-08-19 from the status page's public JSON backend); the on-box guard's state journal (read 2026-08-19); the reconciliation state journal (rolling 7 days as of 2026-08-19).
7 · Commitments
The rules this page operates under. They bind us, not you.
Every stage is named and dated
Each link in the chain above names its producing mechanism and dates its figures. Where a number can drift, the live value is one click away on /trust or /proof.
Coverage is never rounded up
11 of 15 venues reconciled means 11 of 15. The wider OI/funding coverage is disclosed as not reconciliation-measured, and structurally unmeasurable surfaces are carried as caveats, never as silent passes.
Unverifiable is not a pass
Windows that cannot be independently checked are published as coverage gaps. They never count as failures, and they never count as successes either.
Now check the live plane.
A lineage page is only as good as the measurements it points at. The trust board republishes the reconciliation verdicts continuously: per venue, with n, coverage and Wilson floors, accruing venues shown as accruing.
Diligence questions? support@hunterkiller.io, we answer data-lineage questions directly.