How Genesis backtesting works.

What you configure before a run

A backtest is defined by a handful of inputs. The data source tells Genesis which historical candle series to replay. The symbol selects the market. The timeframe sets the bar interval (the engine accepts 5m, 15m, 30m, 1h, 4h, and 1d). Initial capital is the notional account the simulation starts with. Leverage — an integer multiplier, typically between 1 and 10 — scales position size against that capital. Taker fee defaults to 0.06% per fill; you can override it to match the exchange you intend to run on.

Everything else — entry logic, exit logic, scale-in behaviour, take-profit rules, partial-profit rules, DCA level allocation — is defined by the template's parameters. Open a baseline template and the parameters come pre-populated with defaults; adjust them and the next backtest will reflect the changes.

How signals turn into fills

The engine iterates bar by bar. On each bar, the strategy sees that bar's OHLC data and the indicator values derived from all prior bars. If the logic emits a signal, the engine fills the resulting order at the close of that same bar — the moment at which the simulation evaluated the strategy.

This close-of-bar fill is a pragmatic choice. A live strategy evaluating a closed bar generally has its order in the exchange's order book within milliseconds of the close, and for most timeframes the live fill sits close to — but not identical to — that close price. The backtest does not separately model the micro-delay between bar close and live fill, or the order-book slippage that delay can introduce.

That means close-of-bar fills are well-suited to evaluating strategy logic but are not a substitute for live paper-trading when you want to evaluate execution quality. A real exchange matches orders continuously, not on bar boundaries, and slippage varies with order-book depth. On short timeframes or thin symbols the divergence between backtest and live can be material.

Fees and leverage in the calculation

When a fill occurs, the engine debits the specified fee percentage from the notional size of the fill. For perpetual-futures simulations, leverage acts as a multiplier on position sizing: a 5× leverage setting with $1,000 notional capital opens a $5,000 position, with the remaining capital unposted.

Funding rates and exchange-specific borrow costs are not reflected in the backtester's PnL calculation. If you are backtesting a strategy that holds positions across funding intervals, your live PnL will diverge from the backtest by roughly the net funding paid or received over the hold period.

What the output shows

After the run, Enigma renders four views:

• An equity curve — the running account balance over the test window, plotted against time.
• A drawdown chart — the percentage deviation from the running peak. Flat sections are periods of new highs; dips show drawdowns.
• A trade table — every filled trade with entry time, exit time, direction, size, PnL in currency and percentage, and duration.
• A summary metrics panel — the aggregate statistics described below.

The summary metrics, and what they actually measure

Win rate is the percentage of closed trades whose PnL was positive. On its own it says very little — a strategy that wins 80% of the time but gives everything back in the losing 20% is not a useful strategy. Always read it alongside the average-win-to-average-loss ratio.

Net PnL % is the total PnL as a percentage of initial capital. Use it to compare runs against each other inside the same data window, not to compare runs across different data windows or different assets.

Sharpe ratio compares the strategy's returns to the volatility of those returns — the higher, the smoother the ride for a given total return. Sharpe assumes returns are roughly symmetrical around the mean; it penalises upside volatility the same as downside.

Sortino ratio is a variant that only penalises downside volatility. For a strategy with asymmetric return distributions — large occasional winners and small frequent losers, for example — Sortino often reads more intuitively than Sharpe.

Profit factor is gross winning PnL divided by gross losing PnL. A profit factor of 1.0 means you broke even; above 1.0, winners outweigh losers; below 1.0, the opposite. Very high profit factors over short test windows are often the fingerprint of overfitting.

Max drawdown is the largest peak-to-trough decline that occurred during the run, in percent of the peak. It is the single most important risk statistic to look at — a strategy with a 95% max drawdown has, at some point, destroyed nearly all of the account.

Max trade duration flags the longest time a trade remained open. Strategies that hold trades for much longer than you expected on one or two outliers are often hiding a bug in the exit logic.

The optimiser, and why it can mislead you

Genesis ships with a parameter optimiser. You pick the parameters you want to tune and define a sweep range for each (minimum, maximum, step). The optimiser uses coordinate descent: it holds every parameter fixed except one, sweeps that one through its range and records the result of each backtest, picks the best value, then moves to the next parameter and repeats. Once every parameter has been swept once, it begins again from the best-so-far configuration. You can request up to three such refinement passes; each one starts from the previous pass's best configuration.

You can also set constraints on the search — for example, discard any run whose max drawdown exceeded a threshold, or whose maximum trade duration exceeded a cut-off. Backtests within a sweep are run in parallel to cut wall-clock time.

The result is a best configuration plus a record of how the objective behaved along each parameter's axis. That record is genuinely useful for understanding how sensitive your strategy is to each parameter — a parameter whose best-performing value sits in the middle of a broad, gently-sloping ridge is far more robust than one whose best value sits on a narrow spike.

However, the optimiser's best configuration will almost always underperform its backtest result in live conditions. This is curve fitting: by design, the optimiser has searched for parameters that fit the noise in the historical data as well as the signal. When the noise changes — which it always does — the edge evaporates. Reasonable defences include walk-forward validation, testing across regime changes, stress-testing the top candidates on out-of-sample data, and preferring parameter values that sit on a stable plateau rather than at a sharp peak.

A realistic workflow

A reasonable sequence when evaluating a template is: run the default parameters on at least two different symbols and two different historical windows; read the equity curve, the drawdown chart, and the trade table before reading the summary metrics; identify which parameters dominate the result; sweep those with the optimiser across a sensible range; pick candidates from stable regions of the parameter space; test them out-of-sample on a time window the optimiser never saw; and only then consider enabling live mode on a connected exchange in a small size. Nothing here is a recipe for any particular outcome — it is simply the workflow the engine is built to support.