Backtest Config

Detailed config for a backtest: strategy and pair, time and capital, fees and slippage, per-pair execution config—use it for finer control over backtest behavior.

Backtest configuration decides what data to use and under what constraints to simulate trading and compute metrics. A backtest task uses a task-level + per-pair-level two-layer structure; required and common items are summarized in Create Backtest, while this page expands on every configurable item—useful when you need finer control (fee structure, slippage type, etc.). For concepts and the overall flow, see Backtest Basics.


Configuration overview

ItemLayerMain role
Exchange, market type (spot / futures)TaskSource of historical data and the order / leverage model
Time rangeTaskSample size and the regimes covered
Fees / slippageTaskApproximate live cost so the backtest isn't overly optimistic
Trading pairPer pairOne task can hold multiple pairs running independently
K-line timeframePer pairThe pair's execution main timeframe
Initial capital / leveragePer pairSimulated capital scale and leverage
Strategy (signals)Per pairThe bound strategy
Execution config (risk)Per pairPosition, stop-loss / take-profit, max drawdown, scale-in, etc.

Each item is detailed below by category.


Basic configuration

Exchange and market type (task level)

  • Exchange: pick whose historical K-lines to backtest with (Binance, OKX, etc.); align with the exchange you plan to live-trade on so cost and liquidity profiles are comparable.
  • Market type: spot / futures. This drives the order and leverage model—spot is full-amount buy / sell, futures supports leverage and shorting; after switching, confirm the selected pair is actually available on that market.

Trading pair (per pair)

  • Pick pairs: add pairs to the task one by one (e.g. BTC/USDT); make sure the pair has enough historical K-lines in the selected time range, otherwise the backtest may not run or results may be incomplete. The same strategy can behave very differently across pairs—compare on 1–3 representative pairs first.
  • Multiple pairs: one task can hold many pairs; the engine runs each pair independently and reports per pair too. Good for comparing across coins or checking the strategy's generality.

Strategy (per pair)

  • Bind a strategy: pick a previously-created strategy for each pair; the same strategy can be bound to multiple pairs simultaneously, with indicators and signals computed independently per pair.
  • Indicator parameter overrides: in the per-pair configuration you can adjust any of the strategy's indicator parameters (turn MA(5)/MA(20) into MA(10)/MA(30), change the RSI threshold, etc.); the change only affects this pair's run in this backtest and does not modify the original strategy in the library—useful for per-pair tuning or for cross-comparison in Optimization.

Execution config (per pair)

For each pair added to the backtest, set its own execution config (see Execution Config):

  • Position: per-trade and total position ratio
  • Stop-loss / take-profit: percentage or ATR-based dynamic thresholds
  • Max drawdown: the overall drawdown that triggers reduce or pause
  • Scale-in logic: whether scale-in is enabled, conditions, and ratio

If multiple pairs share the same parameters, look for a "copy to other pairs" shortcut in the system (whatever the UI ships).


Time configuration

Time range (task level)

  • Start / end date: the backtest's date range, usually in YYYY-MM-DD; only K-lines within this range are simulated. At least 1 month, 3–6 months recommended, ideally covering different regimes; too short means too little sample, too long means earlier data may not represent today's market well. See Create Backtest.
  • Duration: determined by start and end dates. The system offers shortcuts (1 day / 3 days / 7 / 14 / 30 / 90 days / 2 / 3 / 6 months) for one-click ranges. The maximum range depends on the pair's available history.

K-line timeframe / execution main timeframe (per pair)

  • Execution main timeframe: the K-line period used in this pair's backtest (1m, 5m, 15m, 1H, 4H, 1D, etc.); the engine "ticks" at this period to evaluate buy / sell conditions and emit signals. Keep it the same as the planned live main period for cleaner comparison. Shorter periods mean more data and longer runs.
  • Relation to indicator timeframes: the execution main timeframe decides "how often we judge"; each indicator condition in the strategy can declare its own period (e.g. with main period 1H, a condition can still reference 1D bullish alignment as a higher-period filter). For the difference between the two layers see Timeframes.

Capital configuration

Initial capital (per pair)

  • Amount: the per-pair simulated starting capital (e.g. 10000 USDT)—the tradable capital allocated to this pair, used to compute position, return, and drawdown. Match it to the live capital scale you plan to use, so expected returns and max drawdown make intuitive sense; for parameter comparison, just keep the same initial capital across runs.

Fees and slippage (task level)

  • Fee rate: one-side fee rate (default 0.1%); the system deducts it on every fill. Match the live exchange's fee or set it slightly higher to keep results conservative and close to live. Skipping fees will noticeably overestimate returns.
  • Slippage: adverse offset from the current price when simulating a market fill (default 0.05%); approximates the cost from liquidity and latency. For liquid majors you can leave the default; raise it for less-liquid or more volatile pairs.

Configuration tips

Beginner / quick validation

  • Use defaults: time range 1–3 months, fees 0.1%, slippage 0.05%.
  • First check whether signals and risk controls behave as expected, then gradually tune time range and cost settings. See Create Backtest.

Advanced / closer to live

  • Time range 3–6 months covering different regimes; initial capital matched to live scale.
  • Fees set to the live exchange's rate (slightly higher is fine); slippage tuned to pair liquidity (raise to 0.1%–0.2% for less-liquid or volatile pairs).

Pro / parameter optimization and comparison

  • In Optimization, the system runs many backtests; keep everything except the parameters being optimized consistent (same time range, pair, fees, slippage) so comparison is fair.
  • Watch out for overfitting—do out-of-sample validation.

Common configuration examples

Illustrative combinations—the actual fields depend on what the system supports:

ScenarioInitial capitalFeesSlippageTime range
Standard (default)10000 USDT0.1%0.05%Last 3 months
Conservative10000 USDT0.2%0.2%Last 6 months
Low fee / high liquidity10000 USDT0.05%0.05%Last 1–3 months

Common questions

Can't find a configuration item in the UI: some advanced options may be hidden under "Advanced configuration" or only available on certain versions; the actual UI is whatever the system ships—core items are covered in Create Backtest.

Big differences in results after changing configuration: fees and slippage have a significant impact on returns—raising them lowers net return; different time ranges and pairs will also produce different results. Keep other conditions constant when comparing.

How should I configure things for optimization: optimization usually varies one type of parameter (strategy indicator periods / thresholds, or execution config like position and stops). Keep time range, pair, initial capital, fees, and slippage fixed so comparison is meaningful. See Optimization.


Next steps