---
title: "When HIP-3 Research Outgrows the Venue API"
description: "Keep native Hyperliquid for narrow checks. Move recurring HIP-3 research to the order-level record: L4 book, lifecycle, wallet attribution since March 2026."
canonical_url: "https://0xarchive.io/blog/0xarchive-vs-hyperliquid-native-hip3-orderflow"
markdown_url: "https://0xarchive.io/blog/0xarchive-vs-hyperliquid-native-hip3-orderflow.md"
route: "/blog/0xarchive-vs-hyperliquid-native-hip3-orderflow"
robots: "index, follow"
generated_from: "prerendered_html"
---

# When HIP-3 Research Outgrows the Venue API
Keep native Hyperliquid for narrow checks. Move recurring HIP-3 research to the order-level record: L4 book, lifecycle, wallet attribution since March 2026.
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 that reconstruction ran on is what 0xArchive supplied. [The companion benchmark](https://0xarchive.io/blog/hip3-wallet-classification-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](https://0xarchive.io/blog/who-is-trading-on-hip3-arrakis-data-stack) exists because someone rebuilt three weeks of order flow by hand, market by market, before the wallet work started.

![Native shows the live order. 0xArchive keeps the history.](https://api.0xarchive.io/cms-assets/2026/07/db897835-4965-4824-889b-895b268ac541.webp)

## 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.

Same routes, same windows, on the tenth rerun as the first. Reconstruction work like Arrakis's needs replay, not a live stream: WebSocket replay hands back the same three weeks in original sequence, not wherever the market happens to sit right now. For a notebook-first workflow, Parquet export from `/data` hands over 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](https://0xarchive.io/blog/hip3-wallet-classification-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 already gives live access to HIP-3 data. What it doesn't give is a rerun: pull "which wallets built the largest position in `xyz:TSLA` last week" today, and get the same answer pulling the same question a month from now. Native was built for the live check, not the rerun, and treating it like the second thing is where a study loses its first week to plumbing instead of research.

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

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

Full history on every plan, including Free; each query's time span is capped at 90 days, and the three-week study window sits well inside that. 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](https://0xarchive.io/signup?utm_source=blog&utm_medium=referral&utm_campaign=proof_network_hip3) and pull one known HIP-3 range, or walk the full route-by-route contrast in [the docs](https://docs.0xarchive.io/comparisons/native-hyperliquid-api-vs-0xarchive).

## Sources

- [0xArchive HIP-3 REST docs](https://docs.0xarchive.io/rest-api/hip3)
- [Hyperliquid API docs](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/info-endpoint)
- [0xArchive pricing](https://0xarchive.io/pricing)