The path-dependent backtest — what most crypto track records hide

Most "verified backtest" track records in crypto are mathematically impossible to lose. Not because the strategy works — because the simulation doesn't model how trades actually exit. Path-dependent simulation is the right answer, it produces lower numbers, and almost nobody publishes them. Here's how we run ours.

Vectorized vs path-dependent — the fundamental difference

A vectorized backtest looks at a strategy and computes the outcome of each trade in isolation: entry price, exit price, P&L. The exit is whatever the rules say it should be — TP hit, SL hit, time-based exit. The simulation sequence: list all trades, compute each independently, aggregate.

A path-dependent backtest walks the timeline minute-by-minute (or bar-by-bar) and at each step asks: what's currently open, what's the price doing right now, did anything just trigger? Trades exit only when they actually would in production — when price physically reached SL or TP, in the order it reached them, accounting for the fact that intra-bar price moves matter.

Why does this matter? Because vectorized backtests routinely credit profitable exits that couldn't have happened in the order assumed.

The classic vectorized lie

Imagine a SHORT position with entry at $100, SL at +2% ($102), TP at -10% ($90). Over the next 4 hours, price action looks like:

• Hour 1: high $103, low $98 (in real time, $103 came first)
• Hour 2: high $99, low $95
• Hour 3: high $97, low $89 (TP hit at $90)
• Hour 4: low $86

A naive vectorized backtest sees: TP was hit (price reached $89, which is below the $90 TP). SL was also hit (price reached $103, which is above the $102 SL). The backtest must pick one. Many naive backtests pick the favorable one (TP) and report +10%. Others pick the worst one (SL) and report -2%.

The honest answer: SL hit first, in hour 1. The position closed at $102 with a -2% loss before TP was ever reachable. A path-dependent simulation would correctly report -2%. A vectorized one frequently reports +10%, because it never knows the order of events within a bar.

How we run ours

The Hedonist backtest engine processes 1-minute klines:

1. For each strategy, generate the list of candidate entry signals (timestamp, coin, side).
2. For each entry, fetch 1-minute kline data from entry_ts to entry_ts + hold_window.
3. Walk forward bar-by-bar, tracking running P&L from entry.
4. At each bar, check: did high cross SL (for SHORT) or TP partial level? did low cross SL (LONG) or TP partial level? Apply realistic intra-bar order: high/low order is unknown within a single 1-minute bar, so we use the conservative assumption that the worst (SL) is reached before the best (TP) when both happen in the same minute.
5. On exit, compute net P&L with slippage (0.2% round-trip), fees (0.08% round-trip), and funding accruals.
6. Update portfolio balance. Continue to next signal, but only if portfolio CONC limit allows (we cap at 2 concurrent positions).

The CONC cap matters more than people realize. Without it, every backtest looks great because you can have 50 positions open simultaneously. With CONC=2, you have to pick which signals to take and which to skip — which mirrors what actually happens in production with limited capital.

What this changes

Three things that vectorized simulations get wrong, that path-dependent simulations get right:

1. Realistic exit ordering. SL fires before TP if it should. The hypothetical "wins" that depend on TP firing first stop being credited.

2. Compounded balance over time. Vectorized simulations sum P&L. Path-dependent simulations let your $1k grow to $1.5k over the first week, then size the next trade as 2% of $1.5k (not 2% of $1k). This compounds gains AND losses correctly. The number you see at the end is what you'd actually have, not the sum of percentages.

3. CONC-limited opportunity cost. When you can only run 2 positions, you have to choose. Some signals get skipped. The honest backtest replays this skipping behavior, which often reduces total return relative to "take every signal".

What it costs us

The numbers we publish are lower than what a vectorized run would show on the same strategies. By how much depends on the strategy:

• Our flagship directional algo: vectorized would inflate the equity curve by roughly 30-40% over a typical month. The difference is mostly opportunity-cost from CONC=2.
• Listing/event strategies: vectorized and path-dependent are close (rare events; CONC rarely binds).
• BURST (when we still believed in it): vectorized showed ~+12% / 30d. Path-dependent showed -28%. The difference came from realistic SL-before-TP ordering. This is part of why we killed BURST.

The path-dependent number is the honest one. Other services would publish the higher vectorized figure on the same data. They wouldn't be lying explicitly — their methodology just permits the inflation.

How to spot a path-dependent backtest from the outside

Three questions to ask any service publishing a track record:

1. What's your assumed slippage and fee structure? If they say "we don't model fees" or "slippage is negligible", they're vectorized.
2. What's your concurrent-position cap? If they say "no cap" or shrug, they're vectorized.
3. What's your assumption when SL and TP are both touchable in the same bar? If they say "we take TP in profit and SL in loss" — that's actually wrong (which they don't usually say). If they say "we use 1-minute bars and assume worst-case ordering within the bar", they're path-dependent.

What this looks like in production

The hero number on intel.hedonist.trading is updated continuously by the path-dependent engine. As live trades close, they're stitched into the equity curve. As new historical signals are detected (the algorithms run on every bar of every day), they're path-replayed and added to the simulation. The 30-day window rolls forward.

The hero number you see on the page right now is the actual simulation output for a $1,000 starting balance run forward through a 30-day window, CONC=2, slippage 0.2%, fees 0.08%, no leverage compounding shenanigans. It's reproducible internally. The proprietary scoring weights stay private; the methodology is what we describe here.

Why we publish this

If you're evaluating a crypto signal service, the question to ask isn't "what's your win rate?". It's "how is your win rate computed?". Most of the marketing-friendly numbers in the industry would survive a path-dependent rerun at 50-70% of their advertised level. Some wouldn't survive at all.

We publish ours at the path-dependent number. That's the honest answer. Other services publish vectorized numbers because they look better. You should know the difference.