What Each Job Returns
| Need | Node or RPC provider | 0xArchive |
|---|---|---|
| Blockchain RPC access | Raw JSON-RPC to the chain | The historical and live market-data API for Hyperliquid and Lighter |
| Contract reads, transaction submission, mempool | Signs and broadcasts transactions, reads contract state | Order books (L2), trades, funding, OI, liquidations, and order-level (L4) depth as normalized JSON |
| Node failover and chain connectivity | Manages endpoints and uptime | One key returns every venue route; no collectors to run |
| Hyperliquid order books and trades, live and historical | A different data object | 20-level snapshots about every 1.2 seconds since April 2023, 24.6B+ records, 176 symbols |
| Funding, open interest, liquidations | A different data object | Funding and OI since May 2023; liquidations since December 2025 |
| Order-level depth (L4) and lifecycle | A different data object | Every order add, fill, cancel, and TP/SL with wallet attribution since March 2026 (Hyperliquid families) |
| Lighter market data | A different data object | Trades and funding/OI since August 2025; L2 tick since January 2026; L3 since March 2026 |
| Backtesting, replay, reconstruction | You build archives and retention | REST history plus WebSocket replay and reconstruction on one socket |
| Freshness and incident gates | You build monitoring | Coverage, freshness, incidents, and latency at /v1/data-quality/* |
When To Use 0xArchive
One key returns the records a node provider was never built to serve. Hyperliquid order books and trades go back to April 2023 across 176 symbols and more than 24 billion records, with funding and open interest since May 2023, liquidations since December 2025, and full order-level (L4) depth with wallet attribution since March 2026. Lighter trades and funding land from August 2025, L2 tick from January 2026, and L3 from March 2026. Every response carries a request ID and a data-quality path you can check before a backtest trusts the window. 0xArchive is not the right fit for RPC access, transaction submission, or contract reads; that stays with a node provider. Live or historical, every order, trade, and fill, one API.Run One Route
/v1/hyperliquid/orderbook/BTC/history and /v1/data-quality/coverage, not an RPC method call. Keep RPC for chain access and 0xArchive for venue market data, and name both systems in architecture docs so a coding agent asked for “market data” reaches for the market-data route instead of a chain-access primitive.