console
watch a search overfit itself.
Set the population loose and follow two lines. The in-sample score climbs almost at once, because a large enough search will always find something that fits. The out-of-sample score barely moves. The distance between them is not a bug in the run — it is the measurement the whole system exists to take.
run config
real backtestuniverse
batch size
generations
embargo days
book size $
spread bps
fee bps
objective
240 configurations will be backtested against 2,799 days of real Coinbase candles. Every one counts toward the trial correction, reported or not.
sharpe by generation
stream
waiting for a run…
Runs execute in a Netlify background function against the same tape the leaderboard was built from, and are stored under a content-addressed id — so the same config returns the same run rather than recomputing it. See the attestation for what a sealed run contains.
the contract
one endpoint, one socket.
A run is a POST and a subscription. The console above is written against exactly this — the local mock emits the same events, in the same order, with the same shapes, so nothing in the interface would need rewriting the day it points at a server instead.
Behind it: a Rust simulation core over Arrow, ClickHouse for bars, Postgres for run metadata, object storage for artifacts. Agents execute as WebAssembly in a sandbox with no network and no clock — time is injected by the host, which is what makes lookahead unavailable rather than merely forbidden.
how the fills are decidedapi
POST /v1/runs
content-type: application/json
{
"universe": "perps-major",
"train_start": "2021-01-01",
"train_end": "2024-06-30",
"test_end": "2025-12-31",
"embargo_bars": 48,
"bar": "4h",
"population": 64,
"generations": 12,
"latency_ms": 40,
"fee_bps": 4.5,
"max_participation_pct": 0.6,
"objective": "dsr",
"seed": 20260829
}
→ 202 { "run_id": "run_…" }
WS /v1/runs/:id/stream
{ "type": "data", … }
{ "type": "generation", … }
{ "type": "gate", … }
{ "type": "done", "receipt": { … } }