Backtesting

Backtesting Best Practices

Read ../../references/unified-runtime.md for the shared API lifecycle. Submit every run with POST /runtime/backtests; creation queues it, so there is no separate start request. Use the framework and venue fields defined by GET /openapi.json and the relevant venue skill. This page is about the judgment calls — picking a window that means something, telling signal from noise in the result, and knowing when to give up vs. iterate.

The trade-count bar (sample size first)

Trade count is the single most important number on a result page. Look at it before PnL, before Sharpe, before win rate.

Watch for the trap: backtests with 5-10 trades and a 100% win rate. They look like world-beaters and almost always disintegrate live. The strategy is too selective — every signal is a coin flip you've cherry-picked, not a repeatable edge. Widen the entry threshold, lengthen the window, or accept that there's no statistical signal here.

Pick a backtest window that means something

A great backtest over the wrong window is a great fiction.

The window should answer: "if I had deployed this strategy on day one of this window, what would have happened?" — not "what's the prettiest curve I can fit?"

Cover at least one regime change

Pure bull, pure bear, sideways chop — your window should include at least two of the three. A 90-day backtest in a one-direction market is a 90-day cherry-pick. A momentum strategy that prints +50% over a +60% trending window has told you nothing about itself; it's just measured beta.

Useful default windows

• 6 months of 1h data, or
• 18 months of 1d data

Less than that and you're really looking at noise. More than that and Hyperliquid's history may not cover the pair (HL was launched in 2023; many alts have < 12mo of data).

When you can't get a long window

Some HIP3 / new-listing pairs only have a few weeks of data. Two pragmatic responses:

1. Walk-forward to a similar pair. Pick a sibling perp with longer history (e.g. test the strategy on BTC if BTC-AAPL is too new), then assume the result transfers ±20%.
2. Defer the deployment recommendation. A 14-day backtest is too thin to recommend live capital, period. Tell the user that.

Don't optimize against the test set (the cardinal sin)

If you tune parameters and validate on the same window, your backtest is a souvenir, not a forecast. This is the single most common reason strategies that look brilliant on paper die in the first week of live trading.

The honest workflow:

1. Pick parameters from theory or a single observation, NOT from a sweep.
2. Run the backtest.
3. If results are bad, change the idea, not the parameters.

If you do sweep, walk forward to a different period or pair before promoting the winner. A parameter that wins on Q1 BTC and also wins on Q1 ETH (out-of-sample for the second pair) is real. A parameter that wins on Q1 BTC and gets re-validated on Q1 BTC is theatre.

Red flag

If the user's "strategy" started as a 5-variant sweep and now they want to deploy the winner — the result on the test window is overstated. Tell them to either run an out-of-sample check or accept they're deploying on optimistic numbers.

The 3-variant parameter sweep

When the user wants to find the right parameter (e.g. RSI threshold, ATR multiplier, lookback length), run 3 variants in one batch, not iterative single backtests. The shape of the 3-result table tells you what to do:

Read the shape:

• All 3 profitable → pick the best Sharpe (not best PnL — PnL rewards luck on small samples). Parameter is robust; proceed to walk-forward / deployment with confidence.
• 1-2 profitable → pick the winner, but flag that the param is sensitive. Either (a) walk-forward to a 2nd pair, or (b) one tighter sweep around the winner.
• All 3 unprofitable / < 10 trades each → the idea doesn't work on this pair. Don't sweep again. Switch pair or strategy.
• Monotonic edge (PnL strictly improves A → B → C) → the best variant is at the edge of the grid. Run one more variant past it (e.g. RSI < 40). Don't run another full 3-grid; just extend by one.

Read the exit-reason mix

After the backtest completes, look at the breakdown of how trades ended. A healthy strategy ends through a mix of:

• Take-profit / minimal_roi
• Signal-based exit (populate_exit_trend)
• Trailing stop
• Time-based timeout (custom_exit)

Each one tells a different story. Distortions diagnose specific bugs:

Zero-trade diagnosis

Zero trades from a backtest means the entry condition never fired. Five common causes, in order of likelihood:

1. Indicator threshold too strict (e.g. RSI < 30 rarely triggers on BTC 15m).
2. startup_candle_count larger than available data — the indicator stays NaN forever.
3. Pair has no data for the requested timerange.
4. Wrong pair format for trading mode (BTC/USDC for futures will silently produce no fills).
5. Multi-condition entry that's effectively false AND false — each condition individually rare, joined by AND rarer still.

The escalation rule (don't burn cycles)

• 1st zero-trade backtest: Diagnose. Widen the threshold, drop one of the AND conditions, or extend the window. Next attempt should be a 3-variant sweep, not a single guess — gives sensitivity in one shot.
• 2nd consecutive all-zero result: STOP. Don't run a third. Tell the user: "Two consecutive attempts returned zero trades. The strategy needs a fundamentally different approach." Suggest a different signal (mean-reversion vs momentum, BB vs RSI), a different timeframe, or a different pair.
• Never run 3+ all-zero attempts in a row on the same idea. Wastes compute and user trust.

Compute cost (estimate before submitting)

Backtest run time scales with candle count. Estimate before submitting so you can set the user's expectations:

candles ≈ (days × 24) / timeframe_hours × number_of_pairs

Reference points:

• 1 pair × 15m × 90 days = 8.6K candles (fast)
• 3 pairs × 5m × 90 days = 78K candles (fast)
• 12 pairs × 1m × 90 days = 1.5M candles (slow — warn upfront)

Always allow the user to proceed. Just set expectations. Don't block on size.

Exponential polling cadence

When polling backtest_status on long runs:

• Polls 1-3: every 10s
• Polls 4-6: every 20s
• Polls 7-9: every 30s
• Polls 10+: every 60s

This prevents hitting the 20-step tool limit on million-candle backtests.

What headline numbers to trust (and not)

Walk-forward (the honest validation)

Before recommending live deployment, run the strategy on out-of-sample data at least once:

1. Out-of-sample period: take the most recent 30 days that weren't in your tuning window. Re-run unchanged. Numbers should be in the same ballpark — not better, not dramatically worse.
2. Out-of-sample pair: run on a sibling pair (ETH if you tuned on BTC). Allow ±30% degradation; anything beyond that means the parameters were pair-specific not regime-specific.

If both walk-forwards survive, you have a defensible recommendation. If either falls apart, you have a backtest, not a strategy.