Use case · Research

Strategy research & shadow testing

polybot is a research runtime as much as a trading one. Prototype a strategy, run it in shadow against live markets, and let the analytics store tell you whether it works — before a dollar is at risk.

The loop

1. Prototype. Subclass BaseStrategy, implement on_price_update / on_market_event, and return Signals. The scheduler, risk and execution plumbing is handled for you.
2. Shadow. Enable the strategy in shadow mode so it trades on paper against real, live prices — not a stale historical replay.
3. Measure. The DuckDB analytics store records P&L, Sharpe, trade counts, fill rate and per-pair breakdowns. Query it directly or via the MCP assessment tools.
4. Iterate. Ask an agent to suggest improvements grounded in the code plus the performance report, then apply changes as approved proposals.
5. Promote. When the metrics hold up, promote the strategy to live — per-strategy, reversible, with risk caps intact.

Why shadow beats a naive backtest

A backtest against historical snapshots quietly assumes you could have filled at the printed price. Shadow mode runs your logic against the live book with realistic fill simulation, so slippage and liquidity are part of the picture from day one. See how shadow mode works.

FAQ

How do I test a new strategy without risking capital?

Write a BaseStrategy subclass and run it in shadow mode: it generates real signals against live markets and simulates fills, while the DuckDB analytics store records P&L, Sharpe and fill rate so you can evaluate it before going live.

What data does polybot keep for research?

The DuckDB analytics store holds price history, trade history, strategy stats and market correlations, queryable with millisecond OLAP performance. The SQLite operational store holds live state.