How Algonney backtests work

Algonney backtests read one dataset: Binance Spot historical OHLCV. It is ingested from Binance’s public spot market data and stored as one-minute candles in our own time-series database, then read back for every run.

The dataset does not change when you change the exchange you intend to deploy to. There is no Bybit historical dataset and no OKX historical dataset behind these results, and backtests do not read futures markets. If you are testing a strategy you plan to run on Bybit or OKX, you are testing it on Binance Spot prices.

Candle rows are versioned. When a candle is later corrected or backfilled, the newest version of that minute wins on read, so a corrected history produces a corrected result rather than a silently mixed one.

The source interval is 1 minute. A minute is only stored once it has closed — in-progress minutes are discarded at ingest, so a partially-formed candle can never enter a backtest.

Your selected timeframe is produced by resampling those 1-minute candles: open = first open in the bucket, high = maximum high, low = minimum low, close = last close, volume = sum. A resampled candle is marked complete only when every source minute it needs is present; incomplete candles are excluded from the simulation rather than traded on. Current backtests run under a closed_only candle policy, which is the only policy the engine accepts — results saved before this contract existed may carry a legacy policy instead.

Weekly candles are built from daily candles rather than directly from minutes, with weeks starting Monday 00:00 UTC. All timestamps are UTC.

Symbols are handled in concatenated form (for example BTCUSDT). A single backtest runs one symbol; testing a set of symbols at once is a Strategy Boost feature, not a backtest feature.

Your requested date range is preserved exactly as you entered it, and the range the engine actually resolved is recorded separately. If you request a start date before the symbol’s first available candle, the read is clamped forward to the earliest real candle — the engine does not invent history to fill the gap. If the entire requested window predates the symbol’s listing, the run fails with an explicit error instead of returning an empty or misleading result.

Because requested and resolved ranges are both stored, a result can always tell you whether you got the window you asked for.

The engine’s default behaviour is strict: if candles are missing inside the requested window, the run fails with an error rather than guessing. A configuration typo cannot silently downgrade this to gap-filling. Duplicate or out-of-order candles always fail, under any policy.

Gap-filling exists as an explicit non-default option. When enabled, a missing minute is filled with a flat candle at the previous close with zero volume, filled candles are flagged as synthetic, the amount of synthetic data is measured and reported with the run, and an excessive share of synthetic data fails a quality gate. We prefer a failed backtest to a plausible-looking one built on invented candles.

Fees are charged on both sides of a trade — once on entry and once on exit — as a percentage of position notional, using a taker model. Partial exits are charged on the portion actually closed.

Slippage is applied in basis points to both entry and exit fills, and it always works against you: a buy fills slightly higher, a sell slightly lower.

The fee rate and slippage are yours, not ours. The engine has no default of its own — it applies exactly the values submitted with the run, and they are recorded in the result. Setting them to zero produces a result with no trading costs, which is not a realistic result. Fees and slippage are also part of the identity of a Boost cache entry, so changing them re-runs the work rather than returning a previous number.

Entries use a next-open model: when your rules produce a signal on the close of one candle, the position is opened at the open of the following candle, adjusted for slippage. A strategy can never enter at the same candle’s close that triggered it. This model is fixed in the engine and validated on every run rather than being a configurable preference.

Signal-based and maximum-duration exits fill the same way, at the next candle’s open. Stop-loss and take-profit exits fill at their level, except when the candle opens beyond that level — in which case the fill is the worse opening price, not the level. Backtests simulate market fills only; there is no limit-order fill model.

Strategies run long-only, short-only, or both, with symmetric handling of entries, exits, fees, and slippage in each direction.

Leverage caps position notional relative to account equity. With a risk percentage set, the position is sized from your stop distance and then capped by leverage.

Liquidation is simulated: a maintenance-margin level is computed from entry price, position size, and equity, and if a candle’s extreme reaches it the position is closed as a margin call before any other exit is considered. This is an approximation. The engine uses a single flat maintenance-margin rate and a cross-margin assumption, while real exchanges use tiered maintenance-margin schedules that vary with position size. Treat modelled liquidations as an indication that a configuration is fragile, not as a prediction of the exact price at which a venue would liquidate you.

If equity falls to the ruin floor, the run marks the result as liquidated and stops opening new positions from that point instead of continuing to trade an account that would not exist.

Indicators need history before they mean anything, so the engine computes the warm-up your specific strategy requires — the longest lookback across all of your entry, exit, and monitoring rules — and extends the candle read backwards beyond your start date to cover it. Your requested window is therefore evaluated with fully-warmed indicators rather than with the first N candles of it silently wasted. There is no fixed warm-up length: it is a property of your strategy.

Protections against using information the strategy could not have had:

• Entries fill on the next candle’s open, never on the signal candle itself.
• Higher-timeframe conditions read the last closed higher-timeframe candle, so a 4-hour condition cannot consult a 4-hour candle that has not finished.
• Trailing stops cannot ratchet on a candle’s favourable extreme and then be triggered by the opposite extreme of that same candle.
• Entries are skipped while an indicator is still warm-up-limited.

A candle records only open, high, low, and close — not the order in which the high and low occurred. When a single candle could have hit more than one of your exits, the engine cannot know the true sequence, so it resolves the ambiguity with a fixed, conservative priority:

1. 1.Liquidation, if the candle reached the margin-call level.
2. 2.Stop-loss — if both stop-loss and take-profit were reachable, the stop is taken.
3. 3.An existing trailing stop, ahead of take-profit.
4. 4.Take-profit, only when no protective level was reachable.

This deliberately resolves ambiguity against the strategy. A real candle might have hit your target first; the backtest assumes it did not. Strategies with stops and targets close together are the most affected, because more candles are ambiguous.

Each run records the dataset it read — the source identifier of the candle store and its market — plus a dataset hash: a fingerprint computed over the exact candles in scope, including their versions, count, latest timestamp, and whether any were gap-filled. Two runs with the same hash read the same candles. If history in your window is later corrected or extended, the hash changes.

Results show the dataset hash when the engine reported one. Runs from before this contract existed do not have one, and the interface leaves the field out rather than displaying a placeholder.

Strategy Boost caches per-variant scores for a limited period so a repeated sweep does not recompute identical work. The cache key includes the dataset hash together with your strategy, symbol, timeframe, window, capital, risk, leverage, fees, slippage, cooldown, candle and intrabar policies, and the engine version — so a cached score is only ever reused for a genuinely identical run. Cached entries are per-account, and if the dataset fingerprint cannot be computed the run is forced to recompute rather than risk reusing a stale score.

Strategy Boost is a deterministic parameter-search tool: it generates parameter combinations from the values you choose, runs a full backtest for each variant, and ranks the results with statistical metrics and robustness checks. It does not use AI, machine learning, or prediction.

Each variant is a full backtest over the same candles, through the same engine, with the same fills, fees, slippage, warm-up, and intrabar rules described above. The ranking pass keeps each variant’s summary metrics rather than its full trade list; entry and exit decisions are identical either way. Top candidates are then re-run in full so their detailed results can be inspected.

Boost searches the parameter values you choose, exhaustively and in a fixed order. The same inputs produce the same output. It contains no machine-learning model, no training, no randomness, and no prediction — a “best” variant is the one that scored highest on past data, which is a statement about the past.

Backtest results will differ from live trading because the historical dataset is Binance Spot while live bots trade perpetual futures. Basis, funding, liquidity, fees, slippage, latency, order-book depth, and exchange conditions can change results.

Backtest vs paper. A backtest replays Binance Spot history as fast as the engine can read it. Paper trading runs the same strategy logic forward in real time on live futures candles from the exchange you selected, with simulated orders and balances. So paper differs from a backtest in both the market it watches and the fact that it cannot see the future.

Backtest vs live. Live trading adds everything a simulation cannot reproduce: your order interacts with a real order book, fills depend on available depth, latency exists between signal and fill, funding is paid or received on perpetual positions, and the exchange can reject, delay, or partially fill an order.

Spot vs perpetual basis. A perpetual contract does not trade at the same price as the spot market. The difference — the basis — moves with funding and sentiment, and it is not constant across time or symbols. Because the backtest is priced on spot and your bot trades perpetuals, some divergence is structural, not a bug.

Funding. Perpetual positions pay or receive funding periodically. Backtests are run on spot data and do not model funding, so a strategy that holds positions for long periods can see a materially different live result for that reason alone.

Liquidity and venue differences. Binance Spot, Binance USDT-M futures, Bybit linear perpetuals, and OKX USDT perpetual swaps have different liquidity, tick sizes, minimum order sizes, and fee schedules. A strategy tested on Binance Spot candles and deployed to a thinner venue can behave differently even with identical rules.

Numbers will not match another platform’s backtest, and a mismatch does not by itself mean either is wrong. Common reasons include:

• A different data source or market — a chart priced on a futures or index feed will not match one priced on Binance Spot.
• A different fill model. Entering on the signal candle's close rather than the next open changes every trade in the run.
• Different fee and slippage assumptions, or none at all.
• A different ambiguous-candle rule. A tool that resolves stop-vs-target the other way will report better results on the same data.
• Repainting, or evaluating on an unclosed candle, which our engine does not do.
• Different indicator definitions or warm-up handling for the same indicator name.

When comparing, align the data source, the fill model, and the costs before concluding anything from the difference.

The honest list of what these results cannot tell you:

• The dataset is Binance Spot. Perpetual basis and funding are not represented in it.
• Order-book depth is not simulated. Slippage is a flat assumption you supply, not a function of your order size or of real liquidity at that moment.
• Latency is not simulated. Fills happen at the modelled price with no delay.
• Funding payments on perpetuals are not modelled.
• Liquidation uses a flat maintenance-margin rate and a cross-margin assumption, not an exchange's tiered schedule.
• Intrabar order of events is unknown, so ambiguous candles are resolved by a fixed conservative rule rather than by what really happened.
• Exchange outages, order rejections, partial fills, and API errors are not modelled.
• A backtest is a single historical path. It measures what a rule set would have done, not what it will do.

Algonney does not guarantee profits. Trading cryptocurrency futures involves substantial risk of loss. Past performance, including backtest results, does not guarantee future results.

To reproduce a backtest, hold every input identical: symbol, timeframe, requested date range, strategy rules, initial capital, risk, leverage, fee rate, slippage, and cooldown. The engine is deterministic — no randomness is involved — so the same inputs on the same candles produce the same output.

The dataset is the input people forget. Compare the dataset hash shown with each result: if two runs share it, they read identical candles, and any difference in results comes from your configuration. If the hash differs, history in that window changed — corrected, backfilled, or extended — and the results are not directly comparable, even with identical settings.

The engine version is recorded with each run for the same reason: an engine change can legitimately change a result. Note that a resolved range can differ from a requested range (see section 3), so compare resolved ranges when reconciling two runs.

If you believe a result is wrong, send the run to support@algonney.com with what you expected and why.