My crypto backtest had a sharpe of 13.4. Then I added trading costs

Pavel Kazantsev — Wed, 23 Sep 2026 19:53:44 +0000

I was not trying to prove a grand theory about crypto. I was testing simple, falsifiable baselines and looking for one result worth a second experiment.

Cross-sectional reversal looked almost too clean: Sharpe 13.44 before transaction costs, with positive returns in 67 / 76 reported out-of-sample windows. Then I charged the same signal for the trading it required. At 10 bps per side, net Sharpe fell to -40.13, and not one of those 76 windows remained positive.

That is not a typo. I genuinely did not see it coming — the pre-cost numbers looked clean enough that I spent twenty minutes checking whether I had made an error somewhere before I accepted the result. It is what can happen when a short-lived pattern asks for a new portfolio every 15 minutes.

The less glamorous part of the experiment: execution delay, turnover, fees, slippage, and funding inside the same evaluation path.

What I actually tested

This article covers one intentionally narrow reproduction of H3, a cross-sectional reversal baseline, on cached Bybit USDT perpetual data:

15-minute bars from January 2021 to the pre-lockbox boundary in September 2025;
an eight-bar, or two-hour, return signal;
90-day formation periods followed by 21-day OOS periods;
76 non-overlapping OOS windows, rolled every 21 days;
causal volatility targeting at 10% annualized volatility, using a 96-bar trailing estimate and a 3× leverage cap;
a sealed lockbox beginning September 1, 2025, which was not opened for this article.

A window counts as positive when the sum of its per-bar returns is greater than zero. That is the exact definition used by the evaluator for the window fractions below.

The current cache contains 451 symbol directories. That is not the same thing as a properly reconstructed point-in-time liquid universe. The panel uses the histories available in the cache, but the current reproduction does not apply a historical liquidity screen. Survivorship and availability bias therefore remain possible. This result is a development diagnostic, not evidence of a deployable alpha.

The signal was deliberately boring

At each timestamp, H3 measures every available asset's return over the previous eight bars, standardizes those returns across the cross-section, and reverses the sign.

Recent relative losers receive positive weights. Recent relative winners receive negative weights. The vector is scaled to unit gross exposure before portfolio-level volatility targeting.

The core signal is short enough to inspect:

recent = prices.select(
    "ts", (pl.col(symbols) / pl.col(symbols).shift(config.lookback_bars) - 1.0)
)
long = recent.unpivot(
    index="ts", on=symbols, variable_name="symbol", value_name="return"
).drop_nulls("return")
stats = long.group_by("ts").agg(
    mean=pl.col("return").mean(),
    standard_deviation=pl.col("return").std(),
)
signal = long.join(stats, on="ts").with_columns(
    signal=pl.when(pl.col("standard_deviation") > 0)
    .then(-(pl.col("return") - pl.col("mean")) / pl.col("standard_deviation"))
    .otherwise(0.0)
)
gross = signal.group_by("ts").agg(
    gross_signal=pl.col("signal").abs().sum()
)
normalized = signal.join(gross, on="ts").with_columns(
    weight=pl.when(pl.col("gross_signal") > 0)
    .then(pl.col("signal") / pl.col("gross_signal"))
    .otherwise(0.0)
)

The production implementation also handles an empty cross-section and zero variance. No model is fitted here. There is no feature search hidden behind the result.

A weight computed at time t becomes live at t+1. The evaluator enforces that delay centrally:

def live(column: str) -> pl.Expr:
    return pl.col(column).shift(1).fill_null(0.0)

Without the shift, the backtest would earn the same closing-bar return used to calculate the signal.

The number that made me stop

With fees and slippage set to zero, the current run produced the following.

I am not a professional quant. I run these experiments on my own time, publish the results as I go, and try to document what actually happens rather than what I hoped would happen. When I saw 13.44 I let myself get briefly excited. That was a mistake.

The zero-transaction-cost baseline still includes funding PnL and is not a pure gross-price-return series. Funding belongs to holding a perpetual position rather than transaction execution, so 13.44 is the baseline Sharpe before fees and slippage.

Metric	Zero-transaction-cost baseline
Annualized Sharpe	`13.44`
Positive OOS windows	`67 / 76` (`88.2%`)
Maximum drawdown	`-11.62%`
Summed absolute turnover	`29,451`

That last row is the warning. A huge pre-cost Sharpe and huge turnover can be two descriptions of the same fragile result.

The comparison above is controlled: both bars come from the same code revision, data fingerprint, walk-forward windows, signal weights, and normalization. Only the cost model changes.

Making the backtest pay its bill

Gross PnL uses execution-shifted weights. Turnover is the sum of absolute changes in live positions. Fees and slippage are fixed basis-point charges on turnover; funding is aligned separately with the long/short sign.

The accounting identity is explicit:

fees = turnover * fee_bps / 10_000
slippage = turnover * slippage_bps / 10_000
net = gross - fees - slippage + funding

This is a rejection model, not an execution simulator. It does not model spread variation, order-book depth, queue position, partial fills, market impact, or adverse selection.

Using 6 bps fees plus 4 bps slippage per side, the same every-bar signal produced:

Metric	Net result
Annualized Sharpe	`-40.13`
Positive OOS windows	`0 / 76`
Cost / gross alpha	`4.00×`
Total return	approximately `-100%`

I was hoping the cost model would hurt but leave something survivable. It did not. At this point I considered just not publishing — a Sharpe of -40.13 is not a great headline. But the result is real, the methodology is documented, and a clean failure is more useful to me than a buried one.

The extreme Sharpe is less mysterious than it looks. A continuously refreshed cross-sectional portfolio creates persistent turnover. A relatively stable negative cost stream, annualized from 15-minute observations, can generate an absurdly negative ratio.

The useful result is not the theatrical -40.13. It is that the modeled trading bill was four times the gross PnL.

Slowing the strategy down

The obvious response was to hold weights longer. Under a deliberately pessimistic 15 bps per-side scenario, net Sharpe improved as turnover fell:

Rebalance interval	Net Sharpe	Positive OOS windows
Every bar / 15 minutes	`-66.00`	`0 / 76`
Every 16 bars / 4 hours	`-16.24`	`0 / 76`
Every 96 bars / 1 day	`-4.45`	`10 / 76`

The friendliest tested corner used daily rebalancing and 3 bps per side. It reached a Sharpe of -0.01, with 39 / 76 positive windows. A 7.5 bps daily scenario produced -1.70, with 27 / 76 positive windows.

Slower trading removed much of the damage, but it did not reveal a robust net edge. The signal decayed while it waited. And the maker-style scenario is especially optimistic because this vectorized test says nothing about queue position or whether a passive order would actually fill.

What failed, and what did not

The experiment does not establish that “crypto mean reverts.” It shows a strong pre-transaction-cost short-horizon reversal pattern inside this particular development sample and cache. It also shows that the naive implementation cannot capture that pattern after even simple modeled friction.

Those are different conclusions:

Research lead: relative two-hour moves contain a repeatable pre-cost pattern in this sample.
Failed strategy: resizing the book continuously consumes more than the pattern earns.
Open engineering problem: reduce turnover without waiting so long that the signal disappears.

That leaves specific follow-ups: threshold entries, hysteresis bands, cost-aware sizing, historical universe reconstruction, and a fill model for passive execution. None is assumed to work. They are simply better questions than adding more indicators to the same high-turnover baseline.

Reproduction boundary

The internal HFM repository reproduces the article slice with two commands once the market-data cache exists:

PYTHONPATH=src python scripts/reproduce_round1_h3_article.py
PYTHONPATH=src python scripts/make_article_h3_charts.py

The first command rebuilds the panel and 76 walk-forward windows, evaluates all seven cost/rebalance scenarios, and writes machine-readable results. It also records the SHA-256 fingerprint of 1,442 cached files (880,708,217 bytes), the hashes of every relevant source module, and the Python and Polars versions. The second command creates both figures directly from that result file.

The public repository contains the article, result snapshot, figures, minimal signal/cost code, deterministic tests, and a manifest that fails CI if any frozen artifact drifts. It does not distribute the market-data cache, so a reader can reproduce the mechanics and verify the published evidence package, but cannot independently regenerate the historical metrics without sourcing the data.

Before treating the numbers as anything stronger than development evidence, keep four limits attached:

The cached-symbol universe is not a point-in-time liquidity universe and may contain survivorship or availability bias.
Trading costs are fixed-bps assumptions, not observed live fills; maker scenarios omit queue and fill risk.
The sealed lockbox was not evaluated, and these are backtest results rather than live returns.
The 76 OOS windows do not overlap, but they are not 76 independent market regimes.

The result

I started the experiment hoping to find an edge. What survived was a better research rule: turnover belongs inside the hypothesis, not in the cleanup after a backtest looks good.

A pre-cost Sharpe is not a strategy. It is a claim before execution. The strategy begins with what remains after the position delay, turnover, fees, slippage, funding, universe construction, and untouched data have all had their turn.

In this run, almost nothing remained.

If you have watched a promising backtest collapse once execution entered the model, what did the damage: turnover, spread, fill probability, market impact, or something less obvious?

Results file SHA-256: fd1f506549b8f43ea33029acb3da760dbc88478f12f0122cf980bc725e6e85a9

DEV Community: Pavel Kazantsev