Venue selection is a routing decision, not a label cleanup step. Pick the family before writing code, then carry it into logs, schemas, exports, and agent prompts.
0xArchive exposes two top-level venue APIs: Hyperliquid and Lighter.xyz. Hyperliquid core perps, Hyperliquid Spot, HIP-3 builder perps, and HIP-4 outcome markets are separate Hyperliquid-scoped market families under /v1/hyperliquid/*, /v1/hyperliquid/spot/*, /v1/hyperliquid/hip3/*, and /v1/hyperliquid/hip4/*; HIP-3 and HIP-4 are not additional top-level venues.
| Workflow | Venue family to inspect first |
|---|
| Long-window Hyperliquid perp research | Hyperliquid core |
| Pair-based Hyperliquid Spot research | Hyperliquid Spot |
| Builder-market research | HIP-3 |
| Outcome-market probability and side history | HIP-4 |
| Lighter depth or L3 reconstruction | Lighter |
| Cross-venue comparison | One request family per venue, joined after retrieval |
Cross-venue comparisons should join results after retrieval. Do not try to force all symbols through one namespace.
Symbol Rules
Standard Hyperliquid perp symbols such as BTC and ETH use core Hyperliquid routes. Spot pairs such as HYPE-USDC use Spot routes. HIP-3 symbols commonly carry a builder prefix such as km:US500. HIP-4 outcome sides can use numeric or # identifiers and probability-priced fields. Lighter symbols use /v1/lighter/*.
Route Rules
Make route choice explicit in code, docs, and generated prompts. Similar symbols can belong to different families. For cross-venue work, pull each venue through its own namespace and join results after retrieval.
Coverage Checklist
Use this checklist before publishing examples, generating code, or expanding a job.
| Field | Required before expansion |
|---|
| Venue family | Hyperliquid core, Hyperliquid Spot, HIP-3, HIP-4, or Lighter. |
| Symbol shape | Core symbol, Spot pair, builder-prefixed HIP-3 symbol, HIP-4 outcome identifier, or Lighter symbol. |
| Data family | Order book, L3, L4, trades, candles, funding, OI, liquidations, orders, replay, or export. |
| Time window | UTC start/end, limit, cursor behavior, and any settled-market end state. |
| Quality check | Freshness, coverage, incident, latency, or gap state for the same family and window. |
| Storage context | Route, parameters, request ID, generation time, and venue family attached to downstream records. |
Coverage Boundary
Every coverage claim should name the family it depends on: Hyperliquid core perps, Hyperliquid Spot, HIP-3 builder perps, HIP-4 outcome markets, Lighter, or a cross-venue comparison. If the job needs another venue family, leave that claim out unless a live route exists.
Quality Rules
Coverage is the combination of venue family, symbol, data type, time window, freshness, and plan access. Before a job runs widely, check one small request and one data-quality route for the exact family.
Use /v1/symbols for public symbol discovery and /v1/status/coverage for a public coverage/status summary. Use the deeper /v1/data-quality/* routes when the workflow needs resource-specific coverage, freshness, incidents, latency, or SLA bodies.
Durable Records
Venue-family choice should appear in docs, code, logs, and storage. If a pull is later inspected without the original prompt, the record should still show whether it came from Hyperliquid core, Hyperliquid Spot, HIP-3, HIP-4, or Lighter.
Continue To The Reference
After the family is selected, open the matching REST page and run one bounded request before writing reusable wrappers. 
