The venue trust board
We audit our own liquidation feed. Every venue below is checked on a ~5-minute cadence against an independent exchange reference, and the verdicts, sample sizes and confidence floors are published exactly as measured, including the venues still accruing history.
binance
CLEAN → stableIndependent check: open-interest-signature confidence-interval check; Binance's public REST liquidation endpoints are geo-blocked/discontinued from this VPS, and the OI-history endpoint is independent of the WebSocket broker.
bitfinex
CLEAN → stableIndependent check: independent reconciliation (method per venue).
bitget
CLEAN → stableIndependent check: independent reconciliation (method per venue).
bitmex
CLEAN → stableIndependent check: real-time integrity spot-check: our event-level WS tape is cross-checked against BitMEX's public REST active-liquidation snapshot.
bybit
CLEAN → stableIndependent check: open-interest-signature confidence-interval check; no clean public REST liquidation endpoint exists at any tier.
deribit
CLEAN → stableIndependent check: event-level REST reconciliation against the public trade tape (liquidation flag) plus feed-liveness verified silence.
dydx
CLEAN → stableIndependent check: independent reconciliation (method per venue).
gateio
CLEAN → stableIndependent check: independent reconciliation (method per venue).
hyperliquid
CLEAN → stableIndependent check: 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.
kraken_fut
CLEAN → stableIndependent check: event-level public feed capture (type=liquidation) with independent OI corroboration via Kraken's public tickers REST (separate infra from the WS).
okx
CLEAN → stableIndependent check: direct REST liquidation-orders event-level reconciliation.
What this means
What reconciliation is
Liquidation feeds are easy to claim and hard to prove; exchange APIs are known to underreport liquidations. So we measure ours: on a ~5-minute cadence, each venue's ingested events are checked against an independent surface the venue's own WebSocket broker cannot influence (the method is disclosed per venue above). reconcile accuracy is the share of assessable checks that came back clean over the rolling 7-day window. Every score carries its sample size n and, where the sample supports it, a Wilson 95% lower bound: the floor, not just the headline.
What clean and drift mean
clean = the independent check corroborated what our feed ingested. drift = the check found a verified miss (for example events visible on the exchange's REST surface that our feed never ingested). Drift counts against the score. Windows we cannot verify at all (a reference endpoint down, a structurally unmeasurable surface) are not counted as failures; they show up as coverage gaps instead.
Why coverage matters
coverage is the share of checks that were assessable at all. A high accuracy on low coverage would mean "clean when we can check", so the two numbers are always published together. An accuracy figure without its coverage is not an honest figure.
What the trend arrow is (and is not)
trend compares the trailing 3 days' measured clean-rate with the preceding up-to-27-day baseline (assessable-weighted; ±1.0pp bands; minimum-sample guards). 'accruing' means the measured history is still too short to grade; it is shown honestly, never hidden. A trend describes the measured history only; it says nothing about the future.
The honesty contract
Every venue's ingested liquidation events are reconciled against an independent exchange reference surface on a ~5-minute cadence. reconcile_accuracy_pct = the share of assessable reconciliation runs whose verdict was clean over the rolling 7-day window; coverage_pct = the share of runs that were assessable at all. Unverifiable windows are coverage gaps, never counted as failures. This is a descriptive measurement of our own data quality, independently reconciled against exchange references; it is not a guarantee of future accuracy, and it is not a trading signal.
Machine-readable forms: /feeds/trust (this board as JSON) and
/proof/feed_trust (the rolling verdicts). The track-record page for the prediction
side of the product is /proof; metric definitions
are frozen at /methodology; the Data API
(including tiered trust history) is documented at /docs.