Before and after
The native Hyperliquid API streams live data and answers point-in-time queries, but it has no historical order-book or L4 endpoint. To get history, a team runs and maintains its own pipeline:- a WebSocket collector running around the clock, subscribed to every book and trade channel
- storage for the raw stream, sized for the deepest book you keep
- a reconstruction step that replays diffs into a point-in-time book
- gap detection and backfill for every disconnect
- decimal handling for integer-scaled and string fields, per channel
oid and the wallet on every resting order, a checkpoint_timestamp, and the diffs already applied. No collector, no backfill, no decode step. Hyperliquid history reaches back to 2023, including the window you never collected.
Migration plan
Inventory current calls
Separate live venue behavior, account/execution behavior, historical market data, local book maintenance, and data-quality monitoring.
Map supported market data
Map Hyperliquid core, Hyperliquid Spot, HIP-3, HIP-4, or Lighter calls to the matching 0xArchive route family.
Preserve native authority
Do not route execution, account mutation, or official venue control-plane calls through 0xArchive.
Add response and quality handling
Parse the response envelope, preserve request IDs, and add freshness, coverage, incident, and gap handling before replacing historical jobs.
What usually moves
| Native-side job | 0xArchive replacement or support |
|---|---|
| Ad hoc historical order-book pulls | REST history or Data Catalog exports |
| Local archives built from live polling | REST history plus data-quality gates |
| Replay harnesses | WebSocket replay and SDK reconstruction |
| Agent-generated scripts | OpenAPI, docs Markdown, CLI, SDKs, MCP, or Skill |
| Support debugging | meta.request_id, route, parameters, and data-quality records |
What should stay native
Official venue behavior, account operations, execution, wallet mutation, and venue control-plane actions stay with the native API. 0xArchive is the historical and live market-data layer, not an execution venue.Migration boundary checklist
Use this before moving a native integration to 0xArchive.| Native workflow | Move to 0xArchive? | Reason |
|---|---|---|
| Historical order books, trades, candles, funding, OI, liquidations, or orders | Yes, when the venue family is supported | The job is market-data retrieval and can use route-specific history plus data-quality checks. |
| Replay or reconstruction | Yes, when the target depth and route family are supported | WebSocket replay, L3/L4 routes, and SDK reconstruction cover the migration path. |
| Export files for research or warehouse loads | Yes, through Data Catalog when file delivery fits | The export flow keeps schema keys, ranges, credits, delivery state, and rights review attached. |
| Official venue control, execution, or account mutation | No | The native API remains the correct authority for those behaviors. |
| Wallet-owned account verification or payment infrastructure | Only through account/access pages | Use SIWE verification, Authentication, and Facilitator instead of market-data routes. |
When the case is strongest
The migration case is strongest when a team knows the native venue well but does not want to maintain its own historical archive, replay service, freshness checks, or agent-readable route contract. It is weakest when the job is execution, wallet control, live venue governance, or a market family outside the documented 0xArchive surface.Acceptance
A migrated workflow is not finished when the first request returns. It should preserve route family, symbol, time window, cursor chain,meta.request_id, the data-quality result, and the native calls that remain authoritative.