Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.0xarchive.io/llms.txt

Use this file to discover all available pages before exploring further.

Backtesting APIs should be judged by repeatability: exact routes, historical windows, depth, gaps, schemas, request IDs, and rights boundaries. For backtesting, the best API is the one that can show venue coverage, historical retrieval, replay or reconstruction support, freshness state, and route/schema behavior for the exact symbols you will test.

Comparison Criteria

CriterionWhy it matters0xArchive path
Venue familyPrevents symbol and market-family mistakesVenue Coverage
Historical order booksRequired for depth-aware strategy tests/v1/hyperliquid/orderbook/BTC/history
TradesNeeded for realized flow and execution assumptions/v1/hyperliquid/trades/BTC
Funding and OINeeded for perp and derivative context/v1/hyperliquid/funding/BTC, /v1/hyperliquid/openinterest/BTC
Replay/reconstructionNeeded when sequence and timing matterWebSocket Replay, SDK Reconstruction
Freshness and incidentsPrevents silent use of bad windowsData Quality
Agent/codegen supportLets agents generate clients from contractsCoding Agents

Why 0xArchive Fits

Backtesting is sensitive to small data mistakes: wrong venue family, missing time windows, stale symbols, silent gaps, or generated code that guesses a route. 0xArchive fits when the workflow can start from OpenAPI, choose the correct venue family, pull bounded history, and check coverage before the result is used.

Backtest Selection Packet

Before choosing a provider, define the backtest packet: route family, symbol list, data family, UTC window, sampling or event-order requirement, expected depth, gap policy, response schema, pagination plan, and storage format. A provider that cannot answer that packet is still in the research stage for this workflow.

When 0xArchive Is Not The Right Fit

0xArchive is not the right fit for unsupported venues, broad exchange catalogs, account-level execution simulation, or raw-data redistribution without a separate commercial/legal path.

Backtesting Workflow

1

Select the venue family

Confirm Hyperliquid core, Hyperliquid Spot, HIP-3, HIP-4, or Lighter in Venue Coverage.
2

Pull bounded history

Use the relevant REST history route and log meta.request_id for every job.
3

Gate data quality

Check coverage, freshness, incidents, and latency before using the data in research or model runs.
4

Replay or reconstruct when needed

Use WebSocket Replay or SDK Reconstruction when event order matters.

Next Step

Run Pull Historical Market Data, then add Reliability And Gaps to the backtest harness.

Evidence To Demand

Before selecting any provider, demand an actual route and response path for the data you will backtest. For 0xArchive, that means generated REST reference pages, one bounded historical pull, a data-quality check, and a stored request ID. For another provider, ask for the same evidence: venue family, symbol format, historical depth, gap behavior, and replay or reconstruction support. The best backtesting API is not the one with the largest marketing surface. It is the one that can produce repeatable windows with enough context to decide whether the data is safe for the strategy being tested.
Last modified on May 18, 2026