The short comparison
| Stage | Data and clock | Best question | Does not prove |
|---|---|---|---|
| Backtesting | Historical data, replayed faster than real time | Did these explicit rules behave coherently across selected history? | Live reliability or realistic execution |
| Paper trading | Current or replayed feed with simulated capital | Does the running strategy make the expected decisions and maintain state? | Exchange-specific order behavior |
| Exchange sandbox | Sandbox venue APIs and test assets | Does the integration submit and reconcile simulated orders correctly? | Real liquidity, fills, or profitability |
Backtesting: test the historical logic
Backtesting replays historical bars through a fixed strategy. It is efficient because a long period can be evaluated quickly and repeated after a controlled change. That makes it the right first environment for rejecting broken logic and examining how a rule set reacted to different recorded regimes.
What backtesting can reveal
- whether entries and exits match the intended rule graph;
- how results vary across historical regimes and instruments;
- turnover, drawdown patterns, losing streaks, and dependence on a few trades;
- sensitivity to parameters and explicit cost assumptions;
- look-ahead mistakes or conflicts visible in the trade ledger.
What remains artificial
Historical bars compress the real order book and the path inside each bar. A model may omit spread, slippage, partial fills, latency, outages, and market impact. Backtesting also makes repeated experimentation cheap, which creates overfitting risk. Readthe no-code backtesting workflowbefore tuning a strategy.
Paper trading: test the running system
Paper trading evaluates decisions with simulated capital while the strategy runs over time. Unlike a fast historical replay, it exposes operational behavior: scheduling, state transitions, late or missing data, restarts, duplicate signals, and the discipline required to observe a rule set without editing it after every loss.
What paper trading is good for
- confirming that signals appear only when expected;
- checking position and cash accounting over a continuous run;
- observing how the strategy behaves when there is no completed future dataset;
- testing monitoring, logs, recovery, and reproducibility;
- collecting forward evidence without risking funds.
Paper execution is still a simulation. A generous fill model can make it look better than an exchange would behave. It may never exercise authentication, rate limits, order-state transitions, or venue rejection rules.
Exchange sandbox trading: test the adapter
An exchange sandbox, testnet, or demo environment exposes an API designed to resemble the venue’s order interface while using test assets. It is useful for checking whether a strategy’s intent survives the boundary between the strategy engine and the exchange adapter.
What a sandbox can validate
- request signing and sandbox authentication configuration;
- symbol, quantity, precision, and minimum-order validation;
- order submission, cancellation, rejection, and status reconciliation;
- rate-limit and transient-error handling;
- restart behavior when local and remote order state differ.
Sandbox liquidity and fills are not real-market evidence. Some venues simplify matching, provide sparse test data, reset environments, or behave differently from production. A sandbox passing proves an integration path under test conditions—not the economics of a strategy.
A practical progression
Gate 1: logic is explicit
Before any run, write the hypothesis, define evaluation timing, and make the visual graph readable. Record data and execution assumptions. If two reviewers could interpret a rule differently, it is not ready.
Gate 2: historical behavior is explainable
Run the baseline, inspect individual trades, use out-of-sample data, and stress parameters and costs. Advance only when you understand where the strategy works and fails. A high metric without an explanation does not pass the gate.
Gate 3: forward paper behavior matches the model
Freeze the rules for a defined observation window. Compare each paper decision with the rule graph and investigate differences. Restarts, delayed bars, and state recovery should not silently create new behavior.
Gate 4: sandbox order lifecycle is correct
For supported adapters, test submission and reconciliation with test assets. Exercise failures deliberately: rejected size, expired credentials, rate limiting, temporary network loss, and restart during an open order.
When should a strategy move to the next stage?
Use evidence criteria instead of a target return:
- the same frozen configuration can reproduce the backtest;
- trade-level behavior agrees with the written rules;
- results are not dependent on one narrow parameter or one trade;
- known model omissions are documented and treated conservatively;
- paper decisions reconcile with the live or replayed inputs;
- sandbox orders reconcile from submission through final state;
- failures are visible and recoverable rather than silently ignored.
Where Koval stops
Koval is designed for this research and validation ladder: backtesting, paper trading, and supported exchange sandbox execution. Implemented sandbox support is described for Binance and WhiteBIT. The platform does not enable real-money order execution.
That boundary is intentional. A tool can help you benchmark logic, inspect assumptions, and validate an adapter without implying that simulated results justify financial risk.
Common category mistakes
- Calling historical replay “paper trading.” The operational clock and evidence are different.
- Calling sandbox fills realistic. They validate API behavior, not production liquidity.
- Changing rules during a paper observation window. That destroys the value of forward evidence.
- Ignoring disagreements between stages. A discrepancy is information about the model or implementation.
- Treating any stage as a forecast. Each stage reduces a specific uncertainty; none guarantees future performance.
Want to build this workflow visually? Read thestrategy builder guide, thenjoin the Koval waitlist for one launch email.