Paper trading
Paper trading runs a strategy live on real market data with simulated money. It is the honest middle step between a backtest ("how would this have done?") and risking capital: the same engine that scores your backtests keeps trading your strategy forward in real time, and you watch it happen.
Starting a run
Start from the Library — every strategy row's menu has a Paper trade action — or from the Paper Trading page's Start paper trading button (which can also run the built-in strategies). Pick:
- Symbol and timeframe — from the markets we have live data for.
- Initial capital and leverage — simulated, of course.
- Risk settings — the same sizing methods, drawdown kill-switch, and dynamic-risk options a backtest accepts.
- Run for — an optional end period. The run stops itself when it expires; you can stop it earlier at any time.
The run starts immediately. Its first update arrives within about a minute (the first bar close after warm-up).
Watching it live
The run page is a live view:
- The price chart updates in place — the forming candle moves with the live market price (trade-speed when the exchange stream is available, a few seconds' cadence otherwise), and closed bars append as they complete. The live price feed is display-only: fills always execute on the recorded market data, exactly as in a backtest.
- Fills appear on the chart and in the feed as they happen, so you see exactly when the strategy opens and closes positions.
- The stats block tracks equity, PnL since start, max drawdown, and open positions, updating on every processed bar. Fill totals, fees, and maximum drawdown are maintained for the entire run even when the browser only loads a recent chart window.
- When a run stops, the Paper performance report records final equity, net PnL, return, maximum drawdown, fill count, fees, and duration. These are simulated results, not a forecast of live performance.
Leaving the page (or closing the browser) does not affect the run — it executes server-side and is exactly where you left it when you come back.
Run states
| State | Meaning |
|---|---|
| Running | Trading normally, evaluating each bar as it closes. |
| Paused | You paused it. Any open positions are closed at the last simulated price and open orders are cancelled, so nothing trades while paused. Resume continues from the present — the paused period is never traded. |
| Catching up | The processing loop briefly fell behind (deploy, data-feed gap). Your run is fine — it replays the missed bars exactly as if live, then returns to Running. |
| Stopped | You stopped it, or its end period expired. Any open positions are closed at the last simulated price, so the final report is fully realized. Final stats stay available. |
| Error | The strategy raised repeatedly and the run was halted. The error message is shown on the run page. |
An outage can never produce wrong fills — only late ones. Missed bars are replayed deterministically on recovery.
Limits
Concurrent runs and daily starts are limited per tier: Free 1 running / 1 start per day, Trader 5 / 5, Quant 10 / 10. A start that the server rejects (validation, coverage) refunds the day's start; stopping a run yourself does not.
Paper runs also bound the amount of state they rebuild. A strategy may require at most 20,000 primary-timeframe bars of warm-up after all declared higher-timeframe views are converted to the primary timeframe. Strategies above that limit are rejected before the run starts, with the limiting history view named in the error. This keeps expensive multi-timeframe strategies from consuming unbounded worker memory or CPU.
Catch-up is deliberately incremental. One tick processes at most 500 primary bars and at most 20,000 one-minute fill bars; higher timeframes use a smaller primary batch when necessary to stay inside the fill budget. A long outage can therefore take several ticks to recover, but no closed interval inside the selected horizon is silently skipped. (Pauses are different: resuming skips the paused period entirely instead of replaying it — you paused precisely so the strategy would not trade that window.)
How faithful is it to a backtest?
Very — by construction. A paper run uses the same engine, the same per-bar fill model, the same fees and slippage, and the same data source as a backtest, so a paper run over a window reproduces what a backtest over that same window computes, with three deliberate exceptions:
- Fill model. Paper v1 fills on 1-minute bars. Backtests default to L2 order-book fills where book data exists (falling back to the same 1-minute model), so a backtest can price intra-minute liquidity slightly differently.
- Timing. Paper acts on a bar a few seconds after it closes (data ingestion latency), rather than instantly on the close as a backtest effectively does. Order decisions are identical; only the wall-clock moment differs.
- Late data. If the market-data feed backfills a bar after the run has already advanced past it, that bar is skipped, not reprocessed — determinism is preserved at the cost of ignoring late rewrites.
Funding events are merged with candle events in timestamp order. The run stores a separate funding cursor and the latest observed rate, so each funding payment is applied once and strategy code sees the same current funding context after restarts.
Everything else — sizing, brackets, funding, liquidation mechanics — behaves identically to a backtest of the same settings.