Quant Research Infrastructure — from hypothesis to a live bot
Backtesting Engines
Walk-Forward Validation
Hyperparameter Optimization
Distributed Systems
Over the last year I built — end to end, alone — the full stack a systematic crypto trader actually needs: a backtesting engine, a walk-forward validation harness, a parameter optimizer, a market-data pipeline, and the execution layer that runs the winning configuration against a live exchange account.
Not three toy scripts. Three generations of the same system, each one a deliberate answer to the limits of the previous:
flowchart TB
data[("OHLCV history<br/>13 GB · gap-aware")]
subgraph research ["RESEARCH LOOP"]
direction TB
saw["<b>SAW</b> — own engine<br/>TypeScript · Node 22<br/>backtest · walk-forward<br/>genetic search"]
temporal["<b>SAW / temporal-based</b><br/>Temporal.io · Optuna<br/>InfluxDB 3 · 3 workers<br/>durable orchestration<br/>Pareto search"]
saw -. "one machine<br/>wasn't enough" .-> temporal
end
subgraph execution ["EXECUTION LOOP"]
hb["<b>Hummingbot fork</b><br/>Python 3.12 · Cython<br/>Strategy V2 controllers<br/>live MEXC spot"]
end
data --> saw
saw -- "params" --> hb
temporal -- "params" --> hb
click saw "/docs/development/quantitive_analyst/saw-backtesting-engine"
click temporal "/docs/development/quantitive_analyst/temporal-optimization-pipeline"
click hb "/docs/development/quantitive_analyst/hummingbot-execution"
The three subsystems
| Project | Stack | What it is | Scale |
|---|---|---|---|
| SAW — backtesting & optimization engine | TypeScript, Node 22, Zod, decimal.js | Custom candle backtester, walk-forward harness, evolutionary optimizer, research CLI, results dashboard | ~12.9k LoC, 119 commits, 13 GB of market data, 7 research campaigns |
| Live execution — Hummingbot fork | Python 3.12, Cython, pandas/NumPy | Own Strategy V2 controllers, a grid-executor simulator written from scratch, ~7× faster backtest engine, Ansible/Docker deploy | ~2.2k authored LoC inside a 26 000-commit upstream |
| Distributed walk-forward on Temporal.io | Temporal.io, Optuna, InfluxDB 3, Postgres, Ansible | Durable multi-node optimization pipeline, multi-objective Pareto search, gap-aware OHLCV ingestion, Electron/SciChart analytics UI | ~16.1k LoC, 3 worker nodes, live VPS deployment |
Methodology I care about
- Out-of-sample or it didn’t happen. Every configuration is scored on data the optimizer never saw, across rolling in-sample / out-of-sample windows, with an explicit robustness ratio per segment.
- Overfitting is an engineering problem, not a vibe. Constrained domination (minimum trade count for statistical significance, drawdown ceiling, profit-factor floor), fitness weights that punish a beautiful Sharpe earned on two trades, early abort on instruments that fail the positive-segment threshold.
- Metrics must be comparable. Indicator warm-up windows are decoupled from the evaluation window, so trials with different EMA/Bollinger lengths are scored over an identical period.
- Costs are modelled, not assumed. Minimum break-even take-profit is derived from the exchange’s real maker fee rather than hardcoded — see the formula in the execution write-up.
Related open-source research: Hummingbot MexC Rate Limits Research — a full reverse-engineering of how MEXC actually meters its API, and where the upstream framework gets it wrong.