Genetic-algorithm parameter optimisation for trading strategies — without overfitting your way to ruin

Every trader who has ever run a parameter sweep has had this thought: “I’ll just try a few hundred combinations of fast/slow periods and stop-loss widths and pick the best.”

A few hours later the optimiser triumphantly returns “fastPeriod=7, slowPeriod=25, stopLoss=1.8% → +38.6% PnL, Sharpe 1.84”. The strategy ships. It loses money.

What happened: there was no edge. The optimiser found the parameter set that best fit the noise in that particular historical window. The same sweep on a different year would have produced a different “winner”, with the same false confidence.

This is the central failure mode of strategy optimisation, and most tools make it embarrassingly easy to fall into. The Backticks optimiser is built around making it hard.

What the optimiser actually does

Define what to optimise:

• Parameter ranges — for each indicator parameter or threshold, a min, max, and step.
• Constraint expressions — like slowPeriod > fastPeriod * 1.5 — to filter candidates before they run.
• Scoring rule — what “best” means: Sharpe, Sortino, total return, max drawdown, or a custom expression.
• Data window — historical range to evaluate over.

The optimiser samples the parameter space using a genetic algorithm — async-aware, so candidate evaluation fans out across cores or workers without losing determinism.

A typical run:

• Generation 1: ~240 random candidates, each backtested on the data window.
• Generation 2: the top scorers’ parameters are crossed and mutated to produce the next 240, plus a small fraction of fresh randoms to keep diversity.
• Generation 3+: repeat until score convergence flattens or a generation cap is hit.

The score distribution narrows live. By generation 5–10, the population usually concentrates around a handful of score tiers — clusters of parameter sets that produce similar PnL via similar mechanics.

Why genetic, not grid search

For low-dimensional sweeps (2–3 parameters), grid search is fine. For a real strategy with 5–10 parameters, exhaustive exploration becomes infeasible — the candidate count is the product of per-parameter buckets and explodes fast.

Genetic search gets most of the value of a grid search at a fraction of the cost:

• Most of the parameter space is bad. Random sampling concentrates compute on fertile regions.
• Crossover preserves “what’s working” across generations. If fastPeriod ∈ [7, 12] consistently scores well, the GA exploits that.
• Mutation prevents premature convergence on a local maximum.
• Async evaluation parallelises trivially. The optimiser doesn’t block the canvas while it runs — strategies stay editable while a search is in flight.

The overfitting problem, and how the optimiser fights it

A naive optimiser maximises the score on the data window and reports the winner. That’s exactly the recipe for overfitting.

The Backticks optimiser does three things differently.

1. Walk-forward / out-of-sample by default

The data window is split into an in-sample portion (used by the GA to evolve candidates) and an out-of-sample tail. A candidate’s “real” score is its out-of-sample performance, not its in-sample peak. Candidates that look great in-sample but fall apart out-of-sample are demoted — the only honest signal that the optimiser found edge instead of memorised a noise pattern.

2. Score-tier clustering

Instead of returning a single “winner”, the optimiser groups top candidates into score tiers — clusters of parameter sets that produce similar PnL with similar mechanics.

A real edge usually shows up as a plateau: a wide region of the parameter space where the strategy performs well. A lucky backtest shows up as a single sharp peak with garbage on either side.

If the top tier has one parameter set 20% better than the rest, that’s a flag, not a feature. Robust strategies look like a tier of 30+ similar candidates, not a single magic combination.

3. Robustness aggregation

For the top tier, the optimiser reports aggregate metrics across the cluster: median Sharpe, drawdown distribution, win-rate spread. The right move is to pick from a neighbourhood, then default to the median of that neighbourhood.

This is the workflow that turns parameter optimisation from a slot machine into a measurement.

The performance budget

Optimisation only works if thousands of backtests fit into a tolerable wall-clock time. The Backticks engine is sized for it.

A representative run:

• 2,000 candidates per generation × 40 generations × 1 year of m1 data ≈ 42 billion bar-evaluations
• Wall time: single-digit minutes on a laptop, single process

The reasons this is feasible at all: incremental indicator state, monomorphic hot paths, and deterministic evaluation. Parameter search is the most demanding workload the engine sees, and it’s also the workload where the numbers most need to be trusted.

What’s coming next

Two pieces are actively in flight.

Distributed compute (/earn). A network where idle CPUs pick up candidate batches and run useful strategy search instead of empty hash work — same engine, same determinism, with workers cross-validating each other’s results. Coming soon; the waitlist is open.

Walk-forward analysis as a first-class report. Right now out-of-sample evaluation is per-candidate; a rolling-window walk-forward view is being added so the user can see how a strategy’s optimal parameters drift over time and how stable the score is across regimes.

---

The TL;DR: parameter optimisation is one of the most useful tools in systematic trading and one of the easiest ways to lie to yourself with a backtest. The optimiser in Backticks is built so the second is hard to do while doing the first — and it scales to runs that would be an overnight job in any other tool.