Leak-free is a checkable claim.
Here is how to check it.
Most data vendors ask you to trust the words “point-in-time”. This page explains exactly what those words mean in our codebase — and gives you a reproducible protocol to falsify us. No invented numbers anywhere on this page.
What point-in-time actually means here
Every value is computed strictly from data stamped at or before your as_of — never after. The serving store has one read discipline: every query is capped at ts ≤ as_of, so a row recorded after your timestamp physically cannot enter a computation. Transforms (z-scores, deltas, rolling windows) are computed over that capped series only.
Live and historical answer through the same code path: a live call is simply a historical call with as_of = now. There is no separate backfill pipeline that could quietly drift from what you saw in production — within the stored window, what the API said at time T is what it will say about time T when you ask again.
# the read discipline, end to end historical(asset, feature, as_of=T) # only rows with ts ≤ T live(asset, feature) # ≡ historical(as_of=now) — same resolver # consequence: live@T and historical@T are the same number, by construction
The outcome series is honest
The analytics — backtests, information coefficient, signal quality — run over the real stored series of each signal joined to real mark-price returns. The join is a leak-free as-of merge: each feature bar sees the last price stamped at or before its own timestamp, never a later one. The trading loop is causal too — a decision at bar i uses only data with ts ≤ bar i, and collects the return of the bar that closes after it.
When the stored history is too shallow to say anything real, we do not fake depth: the response carries simulated: true and the dashboard shows a visible badge. Every analytics response also carries the actual covered window — span_days and bars— never the months you asked for if the data doesn’t cover them.
// every analytics response declares what it really ran on
{ "simulated": false, // true = stub series, history still too short — badged in the UI
"span_days": 9.4, // the REAL covered window, not the requested months
"bars": 900, … }GET /v1/sample.csv — public, no API key. A short, watermarked extract of the 3 free discover signals (flow.ofi, liquidations.liq_imbalance, orderbook.spread_bps). Every row is real and timestamped.
Call /v1/features/live at some time T and store the response — it carries as_of and the resolved values for your keys.
Later — hours or days — request the SAME (asset, feature) keys from /v1/features/historical with as_of = T.
historical@T must equal what live answered at T. If it ever doesn’t, our point-in-time claim is broken — report it and we treat it as a critical bug.
Our live archive is young — the sample is short, and we won’t pad it to look deeper than it is. But every row is real and timestamped, every file carries a watermark header, and the archive grows every day the harvesters run.
Download the sample CSV ↓Trade resolution is oracle-only
Wherever our analytics touch prediction-market trades, a trade is resolved by the official oracle outcome only— never the order-book bid, never a mid-price proxy, never “it would probably have settled”. Until the oracle resolves, a position is simply unresolved: it counts as neither a win nor a loss. Proxies flatter results; we don’t use them.
Exports are watermarked and audited
Every historical matrix and every dataset export carries a unique watermark_id, and exports persist an audit manifest — what was exported, by which account, under which accepted license terms. A leaked file traces back to the account that produced it. This protects paying customers: the data you license doesn’t quietly become everyone’s data. Details on /security.
Skepticism is the correct default with data vendors. Run the protocol above on a free account — the trial is 14 days, no card — and check the numbers yourself.