Skip to main content

When HIP-3 Research Outgrows the Venue API

5 min read

Venue APIs are excellent for narrow checks. The gap opens when the same HIP-3 reconstruction keeps getting rebuilt for a larger study.

Hyperliquid's own API cannot answer the question Arrakis's HIP-3 study asked. Its docs cap userFillsByTime at the 10,000 most recent fills and historicalOrders at 2,000: fine for a live check, nowhere near enough for the three-week, seven-market, wallet-level study Arrakis published April 8, 2026, crediting 0xArchive alongside HyperTracker for the data behind it. Answering that question meant reconstructing market state by hand before the actual research could start. The order-level, wallet-attributed record used for that reconstruction is what 0xArchive supplied. The companion benchmark tests whether that record holds up on a rerun.

Where native is still right

Keep it for what it's good at: one disputed trade, one live check, the final call before a number goes out. Nothing beats being closest to the exchange for that, and this comparison doesn't change it.

Where it runs out

The moment the question turns into "how did 175,703 wallets behave across seven markets over three weeks," native stops being an option. TreadFi's $1.19B from 555 wallets and Phantom's $867M from 6,569 wallets don't show up as a line in a live response; the record that shows that split exists because someone rebuilt three weeks of order flow by hand, market by market, before the wallet work started.

Comparison of native Hyperliquid live-order access with 0xArchive historical order-book, trade, and order-state coverage.

What actually holds the history

/trades/{symbol} holds every fill, wallet-attributed, verified back to February 2026. /v1/hyperliquid/hip3/orderbook/{symbol}/history holds the order book, back to February 16, 2026 for the earliest of the seven Arrakis study markets and March 4 for the latest; newer HIP-3 markets outside the study start later still. /orderbook/{symbol}/l4/diffs holds the add, modify, and cancel events live from March 10, 2026; /orderbook/{symbol}/l4 reconstructs the resting book from the nearest checkpoint at or before any requested moment, available once the first checkpoint lands shortly after that date. /orders/{symbol}/history holds wallet-attributed order state from that same date.

WebSocket replay returns the same routes and window in the same order on each run. It provides the three weeks of history rather than the market's current state. For a notebook-first workflow, Parquet export from /data provides the same window as files instead.

Building the benchmark this argument rests on

Five routes only matter if a rerun actually holds up. The companion benchmark tests exactly that: pull the same window twice, diff the wallet-to-bucket assignments, and confirm any disagreement traces to how the pipeline reassembled the data, not to the market history itself, which is already fixed. That test only works if the underlying book and order state are queryable from the nearest checkpoint at or before a label was assigned, which is what these routes are for and what native, capped at a few thousand recent records, cannot provide.

The actual purchase

Native access is useful for a live check. A rerun needs historical state that can return the same answer to a question such as which wallets held the largest position in xyz:TSLA last week. Without that history, the team must rebuild the data pipeline before repeating the analysis.

It also has nothing like /wallets/classify: a precomputed daily behavioral row per wallet, cancel rate and maker ratio and order-to-trade ratio already assembled, no reconstruction required. Native's own historical order endpoint caps out at the 2,000 most recent orders per user, nowhere near market scale. A team would have to build a wallet-behavior pipeline from scratch just to reach the starting line this endpoint ships with.

Pull it

curl "https://api.0xarchive.io/v1/hyperliquid/hip3/trades/xyz:TSLA?start=1782777600000&end=1782864000000" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"

Every route, schema, and served depth is available on every plan, including Free; Free history covers the most recent rolling 30 days, with a maximum 30-day span per request, and Build and above keep the full retained archive. The fixed March 2026 study window now sits outside Free's rolling window, so reproducing it takes Build or above, or the Data Catalog; a fresh three-week study inside the current 30 days runs on a free key. Pulling the full dataset still means paging through cursor results, not a single response.

See the difference on your own window: create a free key and pull one known HIP-3 range, or walk the full route-by-route contrast in the docs.

Sources