← Back to home
How our engine actually works

Anti-bias methodology.

Most backtesters lie by omission. Survivorship, look-ahead, cherry-picked metrics — all invisible in a pretty PnL curve. Here are the nine rules our engine enforces on every result. If your strategy trips one, we tell you loud before we show you the money.

1

No survivorship

Every position that opens must close. Positions still open at the horizon get force-closed at the last real market price — not silently dropped from the statistics. This is the #1 way backtests lie: showing a 60% win rate while omitting 40 losing trades that "haven't closed yet."

Enforced by: horizon check in backtest_engine — every open position is closed with a synthesized "timeout" trade at last known price if it hasn't hit TP/SL.
2

Slippage + fees applied both sides

Realistic entry and exit prices, not theoretical fills. We apply Bybit's maker/taker fees and 5 bps of slippage on both open and close. What you see in the result is what you'd actually realize on the exchange — not what a hypothetical zero-friction fill would give you.

Applied to: every trade — entry_price × (1 + slippage) for long entry, symmetric for short and for exits.
3

Full metric set — nothing hidden

Win rate, expectancy, max drawdown, profit factor, Sharpe, longest losing streak, average trade duration, largest win, largest loss — all reported. You cannot cherry-pick a favorable number by hiding the rest. If profit factor is 1.05 but max drawdown is 60%, both are visible side by side.

Reported fields: n_trades, wr_pct, expectancy_usd, max_drawdown_pct, profit_factor, sharpe, longest_losing_streak, avg_trade_hours, total_pnl_usd, ending_capital, return_on_starting_pct.
4

Walk-forward validation, mandatory

Every backtest is split by time into train (70%) and test (30%) halves. We compute win rate on each. If test WR is less than 70% of train WR, a RED banner appears at the top of the result — this is the classic sign of overfit. The strategy learned patterns specific to the training period that don't generalize.

Threshold: test_wr < 0.70 × train_wr → red banner + deploy blocked.
5

Out-of-sample horizon

The most recent 168 hours of price data are excluded from entry logic — the engine only opens trades where the full horizon has already elapsed in real history. This eliminates a subtle form of look-ahead where recent, still-open positions would inflate results.

Rule: no entry is opened within horizon_hours of the last available bar.
6

Sample size checks

Under 30 trades? A small-sample warning appears — the result is noise, not edge. Under 10 trades? We refuse to render summary numbers at all; you get the trades list and nothing else. Nobody should be deploying a strategy based on 5 trades because it happens to show 100% win rate.

Thresholds: <30 → warning banner; <10 → summary suppressed.
7

Regime awareness

We break down win rate month by month. If the best month's WR is more than 2× the worst month's WR, a regime-dependent flag appears. This is the strategy telling you: "I worked in one market condition — I will not work in another." Bull-only strategies get flagged. Chop-only strategies get flagged. You get to decide if that's what you want.

Trigger: max(monthly_wr) > 2 × min(monthly_wr) → regime flag.
8

Transparency log

Every backtest returns the exact data source, the last-update timestamp of the price database, the number of bars scanned, and the full strategy JSON (as executed, not as described). You can audit our methodology on any single result — no black box.

Included in every result: data_source, data_last_updated_utc, n_bars_scanned, executed_strategy_json.
9

Deploy gate

Any red warning — walk-forward fail, regime-dependent, small sample, look-ahead trip — automatically sets ok_to_deploy: false on the result. The Deploy button is disabled. The Publish-to-Marketplace flow refuses the submission. The frontend cannot override this — it lives in the backend. No matter how pretty the equity curve looks, if a rule tripped, you can't put real money on it through our platform.

Effect: any red warning → result.ok_to_deploy = false. Deploy + Publish endpoints hard-refuse.

Why we bothered

The founders of Trading Bot House ran a memecoin scanner for two years before building the SaaS. We watched hundreds of "profitable" backtests fail in production — almost every failure traced back to one of these nine rules being violated. We baked them into the engine so nobody has to learn that lesson the expensive way again.

What this means in practice

Compared to what you'd get from most retail backtest platforms:

✓

Fewer green results

You will see more red banners than on other platforms. That's the point. The industry standard is to hide problems until you deploy real money.

✓

Comparable numbers

Every strategy on our platform is judged by the same 9 rules. WR here means the same thing as WR there — you can rank marketplace strategies by their honest WR, not their filtered/marketed WR.

✓

Forward test proves it

Because paper trading runs on live Bybit prices with the same engine, if your backtest passes all 9 rules and paper trade matches over 30+ days, you have real evidence — not just curve-fit numbers.

Ready to test your own strategy?

Describe it in plain English. See if it survives our 9 rules. Then paper-trade it live on real Bybit data before risking a cent.

Try free · Sign in with Google → Back to home