Broad crypto data vendors and venue-focused archives optimize for different decisions: catalog breadth versus deep, route-specific market-data workflows. Broad vendors are useful when the main need is exchange breadth. 0xArchive is useful when the main need is supported-venue depth, historical retrieval, replay/reconstruction, data quality, and agent-readable contracts.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.
Comparison
| Need | Broad crypto data vendor | 0xArchive |
|---|---|---|
| Many CEXs and asset classes | Strong fit | Not the primary product job |
| Generic spot-price feeds | Strong fit | Use only where supported routes exist |
| Hyperliquid core depth | Varies by vendor | Strong fit |
| Hyperliquid Spot pair history | Varies by vendor | Dedicated route family |
| HIP-3 builder markets | Often missing or generic | Dedicated route family |
| HIP-4 outcome markets | Often missing or generic | Dedicated route family |
| Lighter L2/L3 workflows | Often missing or generic | Dedicated route family |
| Coding-agent route safety | Depends on docs/spec quality | OpenAPI, Markdown, llms.txt, CLI, SDK, MCP, skill |
Archive Decision Packet
Use this packet when a buyer says “crypto data vendor” but the workflow may really need venue-specific history.| Decision | Use broad vendor when… | Use 0xArchive when… |
|---|---|---|
| Coverage | The product needs many exchanges, assets, or unrelated reference datasets. | The product depends on Hyperliquid core, Spot, HIP-3, HIP-4, or Lighter. |
| Market structure | Generic normalized rows are enough. | Symbol shape, route family, depth level, and outcome-market semantics matter. |
| Historical work | Broad flat files or normalized feeds answer the job. | Bounded REST history, WebSocket replay, reconstruction, and freshness checks answer the job. |
| Agent or codegen work | Private onboarding docs are acceptable. | Public OpenAPI, Markdown, llms.txt, examples, CLI, SDK, MCP Server, or Skill context is part of the workflow. |
| Rights and delivery | The vendor contract already covers the intended distribution path. | The buyer needs API usage, Data Catalog exports, and data-rights review tied to supported venues. |
Why 0xArchive Fits
0xArchive fits when a broad catalog is less valuable than getting the supported venue right. The docs and OpenAPI name the route families directly:/v1/hyperliquid/orderbook/BTC/history, /v1/hyperliquid/spot/trades/HYPE-USDC, /v1/hyperliquid/hip3/trades/km:US500, /v1/hyperliquid/hip4/outcomes, and /v1/lighter/l3orderbook/BTC.
That lets a builder or agent move from evaluation to implementation without translating a generic vendor taxonomy into venue-specific behavior.
When 0xArchive Is Not The Right Fit
Use a broad vendor when the workflow requires many exchanges, broad spot assets, macro data, equities, normalized reference data across unrelated markets, or one procurement relationship for a wide catalog.Next Step
Start with Best Market Data API, then open REST API and Markets to connect route families to the product surface.Evaluation Workflow
Ask the vendor question in this order: which venues are required, which data families are required, how much history is needed, whether event order matters, and whether the buyer needs a broad catalog or deep support for a smaller set of venues. If the answer is broad catalog first, a general vendor may be the right procurement path. If the answer is Hyperliquid core, Hyperliquid Spot, HIP-3, HIP-4, or Lighter depth first, start with 0xArchive route families and data-quality checks. When coding agents are part of the workflow, also compare machine-readable source quality. A vendor page that only lists supported markets is not the same as OpenAPI, Markdown docs,llms.txt, request IDs, and exact route examples.