Hyperliquid Historical Data for Backtesting: Native vs 0xArchive

If you are evaluating a Hyperliquid historical data API for backtesting, start by sizing the job honestly. Pulling a recent window to inspect by hand is easy. Keeping the same study rerunnable after model changes, incident reviews, or weekly refreshes is where the historical layer starts to matter.

Short answer: use native Hyperliquid when you want direct venue truth, a narrow recent window, and full control over collection. Test 0xArchive when repeated backtests, replay jobs, or order-level studies keep reopening pagination, dedupe, gap checks, replay prep, and rate-limit scheduling. A hybrid setup works well when you want managed history for repeated research and native venue responses ready for disputes.

In 30 Seconds

Native is enough when you are validating a narrow recent window or debugging venue behavior directly.
Rerun tax is the real threshold once the same study keeps reopening window walking, overlap handling, gap checks, and replay prep.
0xArchive is worth testing when you need published coverage checks, checkpoint history, replay, or deeper order-level routes without rebuilding all of that glue first.
Hybrid works well when you want managed history for repeated research and native venue responses ready for anomaly checks.

Why this decision matters

This often gets lumped into a generic build-versus-buy debate. That hides the actual cost. A notebook can tolerate some manual stitching. A rerunnable research loop cannot.

Once the same backtest needs to rerun across multiple windows, model versions, or incident reviews, the work shifts from fetching rows to proving completeness, protecting boundaries, and preparing replayable state. That is where hidden rerun tax starts to matter more than the fact that the first request was free.

When native is enough

You need a recent slice of trades, candles, funding, open interest, or liquidations to decide whether a hypothesis deserves deeper work.
You are working on one or a few markets, not a recurring research program.
You want direct venue behavior for live verification or exchange-specific debugging.
You already own mature collectors, storage, normalization, and replay tooling, so Hyperliquid is only one more input.

That is a credible lane. Hyperliquid native is attractive because it keeps your assumptions close to the venue and the invoice cost at zero. For early research, that can be the right trade.

When a static export is enough

Sometimes you do not need an API loop at all. If the job is a bounded offline study, a static export can be enough. 0xArchive already exposes Bulk Download on the public site, and the live pricing page states Build and Pro include monthly export credits with Apache Parquet downloads. If your study is mostly offline analysis rather than repeated API reruns, that is worth testing before you build more collection code.

Where native starts to cost more than it looks

The first request is rarely the painful part. The pain shows up when the ask becomes “rerun this study reliably every time the model changes.” Hyperliquid’s public docs are explicit about the constraints evaluators have to plan around:

info time-range responses return at most 500 elements or distinct blocks.
userFillsByTime returns at most 2000 fills per response, and only the 10000 most recent fills are available.
Rate limits specify 1200 weight per minute per IP, a maximum of 10 WebSocket connections, and 1000 subscriptions.

Those limits are workable for exchange access. They do not automatically cover every long-window historical workflow you might layer on top. A 48-hour trade pull is one thing. A six-month rerunnable study across trades, funding, open interest, and replay state is another.

# Representative native long-window burden
cursor = start_ts
rows = []

while cursor < end_ts:
    chunk = get_info_window(symbol, cursor, end_ts)
    rows.extend(chunk)
    cursor = advance_with_overlap(chunk)

rows = dedupe(rows)
assert no_gap_breaks(rows)
replay_seed = rebuild_state(rows)

Native is free in invoice terms. The comparison is about recurring engineering time, rerun reliability, and how much historical plumbing you still own once the work stops being a one-off pull.

What 0xArchive adds to the evaluation

The current public 0xArchive surface is specific enough to inspect directly. The live llms.txt describes two top-level venue APIs, Hyperliquid and Lighter.xyz, with HIP-3 under the Hyperliquid namespace. It also publishes checkpoint history, replay/backtesting support, data-quality coverage endpoints, CLI and MCP access, and order-level routes such as /v1/hyperliquid/orders/{symbol}/flow, /v1/hyperliquid/orders/{symbol}/tpsl, and /v1/hyperliquid/orderbook/{symbol}/l4/history.

Coverage endpoints let you inspect the historical span before you commit to collection work.
Replay and checkpoint history let you test whether the historical layer gets you closer to rerunnable state.
Order flow, TP/SL, and L4 routes let you test deeper market-structure questions without pretending candles answer everything.
CLI and MCP surfaces let you evaluate the same historical layer inside repeated operator and agent workflows.

Next step: run one-symbol parity

Keep the next move small. One symbol, one historical window, and one study you already know you will rerun will tell you more than a long migration debate.

Hold the symbol, timestamps, and downstream job constant.
Measure the second run, not only the first fetch.
Keep native venue responses as the dispute fallback.
Run the full parity method here, then come back to the category decision with evidence.

Decision matrix

Workflow	Native is enough when...	0xArchive is worth testing when...	Better default
One-off prototype	You need a recent slice and direct venue truth.	You already know the study will become recurring.	Native
Static offline study	You only need a bounded export and no rerunnable API logic.	You expect repeat pulls, replay, or follow-on QA work.	Export or native
Weekly reruns	You already own strong collectors, QA, and replay prep.	The same backtests keep reopening historical plumbing work.	0xArchive worth testing
Replay workflows	You already rebuild state internally with confidence.	Checkpoint history or replay support may shorten setup materially.	0xArchive worth testing
Order-level research	You already run a mature internal order-history stack.	You need published routes for order flow, TP/SL, or L4 work.	0xArchive Pro worth testing

Next steps are simple: run one parity test, keep native in the loop for disputes, and move the highest-friction workflow first instead of migrating everything at once.

Final takeaway

Hyperliquid native is a strong starting point when the work is still narrow, recent, and easy to inspect by hand. Move the evaluation to 0xArchive when historical retrieval starts eating repeatable engineering time that no longer helps the actual research.

Start the 14-day Build trial with no credit card and run one parity test before you commit more engineering time.

Hyperliquid Historical Data API for Backtesting: Native API vs 0xArchive