Building a Hyperliquid Strategy Backtester from Public On-Chain Data

Most retail traders don't backtest. They develop intuitions from chart-reading, paper-trade for a few weeks, and start risking real money once they feel "confident." Then they're surprised when the strategy that felt right in the charts loses money over enough trades to be statistically meaningful.

Backtesting fixes this — but most backtesting infrastructure is built around equities or CEX-listed futures, where historical data is expensive and quirky. Hyperliquid is different. Every trade, every position, every funding payment lives on-chain, queryable for free, with no rate limit on historical reconstruction. That makes it one of the most backtestable trading environments in crypto. Most traders just don't know they have this resource.

This article walks through what's required to build a Hyperliquid strategy backtester from on-chain data, what shortcuts to take, and how to validate the backtest against real outcomes before deploying capital.

What you're actually backtesting

A backtest answers a structured question: "if I had executed this strategy at every signal it generated over period T, what would my PnL look like?" The answer requires four ingredients:

1. Signal generation. What conditions would have triggered an entry or exit. These conditions need to be reproducible from data available at the time, not data from the future.
2. Position simulation. Given the signal, what position would have opened, at what entry price, with what leverage and what stop.
3. Realistic execution assumptions. Slippage, fees, funding payments, partial fills. The difference between a paper backtest and a realistic one is the execution assumptions.
4. PnL computation. Position close → realized PnL → portfolio equity curve.

The challenge isn't the math. The math is straightforward. The challenge is sourcing the data and modeling execution honestly.

Sourcing the data

Hyperliquid publishes historical fills, funding rates, mark prices, and order book snapshots on-chain. The data is queryable via:

1. Hyperliquid's native L1 explorer. Direct access to the chain, free, no rate limits. Good for foundational data (fills, funding, mark price).
2. HyperTracker API. Normalized, indexed, with cohort attribution. Pulse tier ($179/mo) gives you historical positioning data, cohort-level metrics, and aggregate OI/funding time series.
3. Order book reconstruction. Harder. Order book history isn't natively persisted in a clean format. You can reconstruct it from order events, but it's compute-intensive.

For 90% of strategies, you don't need order book reconstruction. Fills, funding, mark price, and aggregate positioning data cover the universe of practical strategies.

A minimum-viable backtester

A backtester for cohort-based signals on Hyperliquid:

import pandas as pd
from hypertracker import api

def backtest_cohort_strategy(asset, start_date, end_date,
                              signal_fn, position_size_pct=0.02):
    # 1. Load historical data
    fills = api.get(f"/historical/fills/{asset}",
                     params={"start": start_date, "end": end_date})
    funding = api.get(f"/historical/funding/{asset}",
                       params={"start": start_date, "end": end_date})
    cohorts = api.get(f"/historical/cohort_positioning/{asset}",
                       params={"start": start_date, "end": end_date})

    # 2. Iterate through time, generating signals
    portfolio = {"equity": 10_000, "position": None, "trades": []}

    for ts in pd.date_range(start_date, end_date, freq="1H"):
        # Snapshot of state available AT THIS TIME (no future data)
        cohort_state = cohorts.at_time(ts)
        funding_state = funding.at_time(ts)
        mark_price = fills.last_price_at(ts)

        # Generate signal from current state
        signal = signal_fn(cohort_state, funding_state, mark_price)

        # Execute
        if signal == "long" and portfolio["position"] is None:
            entry = mark_price * 1.0005  # slippage assumption
            size = portfolio["equity"] * position_size_pct
            portfolio["position"] = {"side": "long", "entry": entry, "size": size, "ts": ts}
        elif signal == "close" and portfolio["position"]:
            exit = mark_price * 0.9995
            pnl = (exit - portfolio["position"]["entry"]) * portfolio["position"]["size"]
            # Subtract accrued funding
            pnl -= compute_funding_cost(portfolio["position"], funding, ts)
            # Subtract fees
            pnl -= portfolio["position"]["size"] * (entry + exit) * 0.00045
            portfolio["equity"] += pnl
            portfolio["trades"].append({**portfolio["position"], "exit": exit, "pnl": pnl, "close_ts": ts})
            portfolio["position"] = None

    return portfolio

This is a deliberate sketch, not a complete library. The execution model is simplified (constant 5bps slippage, no partial fills, no liquidation risk modeling). For exploratory strategy validation, that's fine. For production strategies, you need to harden each assumption.

The execution honesty problem

The single biggest mistake retail backtesters make is using execution assumptions that wouldn't have been achievable in practice. Three common sins:

Filling at mid price. Real fills happen at bid/ask, not mid. For a market entry, expect to pay 1-3 bps to the spread depending on book conditions. For large size, expect more.

Ignoring funding accrual on multi-period holds. A position held for 48 hours during persistent negative funding could earn meaningful funding income (or pay meaningful funding cost) that materially changes PnL. Backtests that ignore this look better than reality.

Trading on signals that use future information. Subtle bug: signals computed using rolling windows can accidentally include data from after the signal time. A 24-hour moving average computed at time T should only include data from T-24h to T, not T to T+24h. Off-by-one errors here invalidate the entire backtest.

A useful sanity check: run the backtest, then re-run it with only the past 30 days of data (simulating a real production deployment that just turned on). If the live-mode backtest performs dramatically worse than the historical sweep, you have execution assumptions that don't survive contact with reality.

Walk-forward validation

The cleanest backtest validation is walk-forward analysis. Instead of running the strategy over the full history with one parameter set, you:

1. Optimize parameters on the first half of the data
2. Test the optimized strategy on the second half (which the optimization never saw)
3. Compare in-sample vs. out-of-sample performance

If the strategy degrades significantly out-of-sample, the in-sample optimization overfit. The strategy doesn't actually have edge — it has a parameter set that happened to fit historical noise.

The honest result for most strategies is that they look great in-sample and mediocre to bad out-of-sample. That's not a failure of the backtester; it's an indictment of the strategy. Better to find that out before deploying capital than after.

What this enables

Once you have a working backtester, you can validate any signal-based strategy idea before risking money. A few practical examples:

• Cohort positioning extreme strategies. "When Money Printer cohort net long > 70%, fade with shorts." Backtestable from cohort positioning history.
• Funding rate arbitrage. "Enter long when 24-hour funding < -0.05% on Hyperliquid AND > -0.02% on Binance." Backtestable from funding history (Hyperliquid native + CEX historical from elsewhere).
• Cascade fade. "Enter long after liquidation cascade clears > $50M in 1 hour." Backtestable from liquidation event history.

None of these require sophisticated infrastructure to test. A weekend of work gets you a backtester. The discipline to actually run strategies through it before deploying — that's the rare part.

Access historical cohort + positioning data via API →

The bigger framing

The reason most retail traders don't backtest isn't that the tools are missing. It's that backtesting honestly is psychologically uncomfortable. Most ideas don't survive the test, which means most of what feels like good intuition turns out to be noise. Skipping the test preserves the comfortable feeling at the cost of preserving the actual edge of profitable strategies.

Hyperliquid's data transparency lowers the friction to backtest dramatically. The only thing left is the willingness to know whether your strategies actually work.

Tuning the realism dial

A practical workflow for taking a backtest from "looks promising" to "deployable":

Tier 1 — initial screen. Run the strategy with optimistic execution assumptions (fills at mid, no slippage, no funding accrual). Most strategy ideas die here. The point is to cheaply rule out concepts that don't work even with the wind at their backs. If the optimistic backtest barely breaks even, no amount of execution honesty will save it.

Tier 2 — realism pass. Re-run with conservative assumptions: 5bps slippage on entry and exit, funding accrual modeled, 0.045% taker fees. This should cut Tier 1 returns by 30-50%. If the strategy survives this and still has positive expectancy, it's promising.

Tier 3 — adverse selection modeling. The hardest assumption to model is that your fills get worse when the strategy is right. If you're entering longs at moments when the market is about to move up, the sellers willing to fill you at your entry price are doing so because they expect price to go against you in the short term. This is real and it eats into PnL. The crude proxy: add another 5bps of slippage on top of Tier 2. If the strategy still works, it's likely deployable.

Tier 4 — live shadow trading. Run the strategy live but in paper-trade mode for 30-90 days. Compare live signals to backtest signals at the same timestamps. Discrepancies between live and historical executions are where deployment surprises hide.

Most retail traders skip Tier 3 and Tier 4. That's where the gap between backtest performance and live performance comes from.