Backtests, paper tests and live markets are different systems

A backtest, a paper test and a live bot may share strategy rules, but they do not share the same operating conditions. A historical replay asks what those rules would have done with a selected dataset and execution model. Paper mode checks how the current software behaves with simulated orders. Live execution adds real liquidity, exchange controls, credentials, network dependencies and funds at risk. A result from one system is not proof of a result in another.

Backtests depend on their data and model

A backtest processes known historical observations under assumptions chosen by its operator. The result changes when the time range, candle source, fee model, spread, slippage, fill rule or missing-data treatment changes. Repeatedly adjusting a template after seeing the same history can also make the rules fit that sample without establishing that the relationship will persist.

Keep the input dataset, versioned strategy parameters and execution assumptions beside every reported result. Test on periods that were not used to tune the configuration, and inspect trade sequences rather than relying on a single return or win-rate number. These practices make a result easier to audit; they do not make it a forecast.

Paper tests exercise the running product

Paper mode can reveal whether scheduled jobs run, fresh market data arrives, risk rules reject an entry, state persists and alerts reach an operator. It is useful for finding configuration and operational faults that a standalone historical replay cannot expose. It should therefore be evaluated for correct behaviour and recoverability, not only for simulated profit and loss.

Simulated orders still use simplified fills. They cannot reproduce queue position, every partial fill, sudden spread changes, an account-specific fee tier, an exchange rejection or the delay of a real network request. A paper result is evidence about the configured simulation and the software paths it exercised, not evidence that the same orders would have completed at the same prices.

Live markets add execution and account risk

Live execution depends on the exchange order book and account at that moment. Liquidity can move while an order is in transit, credentials can expire, rate limits can delay requests and an outage can interrupt monitoring or exits. Crypto markets can also move sharply and may offer fewer protections than users expect. Programmed limits can refuse or size an intended order, but they cannot guarantee a fill price or cap the realised loss.

A move from paper mode to live mode is therefore a new operational decision, not the final step of the same experiment. It requires separate access controls, small exposure, independent account monitoring, an emergency procedure and a tested manual way to manage positions at the exchange. Even then, the user remains responsible for whether automation is enabled and for the connected account.

Compare evidence without merging it

• Label every result as backtest, paper or live and record the software version.
• Keep data, fee, spread, slippage and fill assumptions with historical results.
• Use paper mode to test monitoring, rejection paths, recovery and manual intervention.
• Reassess credentials, permissions, limits and exchange access before any live decision.
• Stop automation when observed behaviour differs from the documented configuration.

The useful conclusion is not that one environment validates another. It is that each produces a different kind of evidence, with different gaps. Decisions about real funds should account for those gaps and should never rely on a historical or simulated result as a promise of profit.