Arrakis's own study, published April 8, 2026 with 0xArchive credited alongside HyperTracker for the 808 million order events behind it, states a limit up front: the retail share is "a floor, not a ceiling," because the interface cannot tag limit orders. Preserve that limit when rerunning the classification. Pull the same window twice, a week apart, and check whether the buckets agree. Because the window is historical and fixed, any gap has to trace to how the pipeline reassembled the data, not to a change in market history. Read the full study for the participant findings, then use the comparison to see what the native API leaves out.
Where it breaks
A market-by-market classification misses cross-market traders. 209 wallets traded all four silver markets in the Arrakis study. Finding that group requires a classification across markets. Tighten a threshold after the fact, and every borderline wallet needs re-checking against order-book state at the moment the label was assigned, not just the fill that triggered it.
What it runs on
Start with the fill: /trades/{symbol} gives served fill-level trade rows with wallet attribution, verified back to February 2026. That alone tells you what a wallet did, not how it got there. /orderbook/{symbol}/history holds the book state around each labeling decision; across the seven Arrakis study markets specifically, that starts February 16, 2026 for the earliest and March 4 for the latest. /orderbook/{symbol}/l4/diffs holds the add, modify, and cancel events, live from March 10, 2026. /orderbook/{symbol}/l4 holds the resting order-level book itself, reconstructed from the nearest checkpoint at or before any requested moment, available once the first checkpoint lands shortly after March 10: captured resting orders with price, size, and ID. /orders/{symbol}/history holds wallet-attributed order state on the same range. Reproducing a study at this scale means pulling from all five of these routes; a rerun draws from the same five.
The precomputed version of the same fields
/wallets/classify precomputes the same fields, one row per wallet per day: cancel rate, maker ratio, order-to-trade ratio, whether a wallet uses TWAP or trigger orders. There is no symbol parameter: each row covers a wallet's behavior across every HIP-3 market it touched that day, the same cross-market reach that captures a cohort like the 209 silver-market wallets above. A per-symbol pull cannot produce that cross-market view. The endpoint filters directly on the fields a threshold-based taxonomy uses: min_cancel_rate and max_cancel_rate pull exactly the wallets a bucket boundary would separate, without a separate filtering pass. Pull the same date twice, a week apart, and the wallet metrics match exactly; only the request_id in the response envelope changes.
Checking that a rerun actually agrees
Build the taxonomy from the five raw routes, then pull the same window twice, a week apart, and diff the wallet-to-bucket assignments. Because the window is historical and fixed, any bucket change means the assignment logic saw different inputs on the second pull. A wallet that flips buckets because the order-book snapshot at labeling time came from a different pagination cursor is exactly that kind of bug. The book state must be queryable from the nearest checkpoint at or before the label was assigned, not approximated from a nearby fill.
Pull the record
curl "https://api.0xarchive.io/v1/hyperliquid/hip3/trades/xyz:TSLA?start=1782777600000&end=1782864000000" \
-H "X-API-Key: $OXARCHIVE_API_KEY"Pair that with /orders/{symbol}/history for wallet-attributed order state and /orderbook/{symbol}/l4 for book state from the nearest checkpoint at or before the label time. Use the same five routes on every rerun so the comparison remains comparable.
What native can't give a taxonomy
Hyperliquid's API answers what happened on one trade, not what the book looked like when a wallet's order sat in queue three weeks ago. The comparison tests that gap directly. A native-only taxonomy would have to reconstruct the book context for each run.
Pull /wallets/classify for the same date a week apart and compare the wallet metrics. If the numbers match and only request_id changes, the precomputed classification is stable without touching the raw routes. Create a free account to try it.