Hyperliquid Historical Data: The S3 Archive, Explained

The single most common wrong turn in a new Hyperliquid integration is looking for historical data in the API. It isn't there. The /info endpoint serves live and recent state, and candleSnapshot returns a bounded window — useful, but not the years of history a serious backtest needs. Deep history lives in public S3 buckets, in a different format, with a different cost model and different guarantees. This post is the map of that archive: what's published, how it's organised, what it costs, and where it will disappoint you.

This is the deep-dive companion to Hyperliquid Market Data & API, which covers the live feed and the low-latency path alongside this one. Published July 26, 2026.

The two buckets

Hyperliquid publishes history across two S3 buckets, and knowing which one you want saves a lot of wasted transfer. The market-data bucket, s3://hyperliquid-archive, holds L2 order book snapshots and asset contexts — the market state view. Objects are laid out by date, hour, datatype and coin, following the pattern market_data/[date]/[hour]/[datatype]/[coin].lz4, so you can fetch exactly the slice you need rather than pulling a day to read an hour.

The node-data bucket, s3://hl-mainnet-node-data, holds output produced by the L1 node itself, which is a different kind of thing: it is the chain's own record rather than a market snapshot. The paths that matter most are node_fills_by_block for trade fills batched by block, explorer_blocks for block data, replica_cmds for the raw L1 transaction stream, and misc_events_by_block for the events that aren't trades — transfers, staking actions, funding. If you are reconstructing what actually happened on the exchange, this is the bucket.

Three properties to design around

First, everything is LZ4-compressed. Budget a decompression step in your ingestion, and be aware that LZ4 frame handling differs between libraries — test round-tripping a known object before you build a pipeline on top of it.

Second, it is requester-pays. You cover the S3 transfer cost, not Hyperliquid. That is entirely reasonable for a public good, but it means an unplanned full-history pull is a real bill rather than a free download, and it means your AWS credentials need to be configured to acknowledge requester-pays or the request simply fails. Pull the slices you need, and cache what you pull.

Third — and this is the one that catches people — uploads are periodic rather than continuous, and completeness is not guaranteed. Treat the archive as a bulk backfill source, not a feed. The correct architecture is almost always: seed history from S3 once, then maintain your own continuous collection from the live API going forward, and reconcile the two where they overlap. If you need a gap-free series and you rely on the archive alone to stay current, you will eventually find a hole.

Historical fills specifically

Exchange-wide historical fills are one of the most-requested datasets and one of the most misunderstood. The /info endpoint's userFills gives you fills for a given account — that is an account-scoped query, not an exchange-wide tape. For the full historical record across all accounts, you want node_fills_by_block in the node-data bucket. Older layouts named node_fills and node_trades still exist for compatibility; node_fills_by_block is the current format and the one to build against.

Because these come from node output, the cleanest way to hold a complete and ongoing fills dataset is to run a node with fill output enabled and stream it yourself, using the archive to backfill everything before you started collecting. That is covered in Hyperliquid Low-Latency Data. For most analytics work you do not need to go that far — the archive plus your own live collection is enough.

What the archive does not give you

Two absences are worth planning around before you commit to a design. There is no deep historical open-interest series. You can read current OI from the asset context on any live call, but reconstructing a long OI history means polling and storing it yourself from today forward — you cannot backfill it. The same caution applies to funding-rate history if your model depends on a long, clean series: verify what you can actually retrieve before you assume it exists.

And for HIP-3 builder markets, history only reaches back to that dex's own launch date. A market deployed in late 2025 has no 2024 candles anywhere, in any bucket, at any price. If you are backtesting builder markets, days-since-launch is a hard input to your design rather than a footnote — see Hyperliquid HIP-3 API for how to read those markets and what else differs about them.

Backtesting on it without fooling yourself

Once you can pull history, the temptation is to immediately fit a strategy to it, and that is where most of the value gets destroyed rather than realised. Archive data has all the usual traps plus one specific to this venue: the periodic, best-effort upload cadence means a naive loader can silently skip a window and produce a backtest over data that has a hole in exactly the volatile hour that mattered. Assert on continuity before you trust a result.

The signal engine we use for this is open source — perpsignal, Apache-2.0, at github.com/mokshyaprotocol/signalview — a signal DSL plus a backtester that models fees, funding, stops and leverage. It has no wallet, key or trading code, so it is safe to run anywhere against your own archive pull. Backtesting Trading Strategies covers the methodology side: the metrics that matter and the biases that make backtests lie.

Or skip the pipeline entirely

If the reason you want history is to find and trade an edge — rather than to operate a data platform — there is a shorter path. Signalview already runs this ingestion and turns it into scored, backtested strategies. You can browse scored Hyperliquid signals to see current setups, deploy an AI trading agent that executes one 24/7 with a scoped, non-custodial key that can only place perp orders, or publish your own strategy as a signal and earn when others trade it. Free to run; you pay only Hyperliquid's normal fees and your funds never leave your wallet.

Risk note: Hyperliquid perps are leveraged, high-risk instruments and you can lose your entire margin. Access to better data does not reduce market risk. Nothing here is investment advice, and every path, bucket name and format detail above should be confirmed against Hyperliquid's official documentation, which is the source of truth and changes over time.

Frequently asked questions

Where is Hyperliquid historical data stored?

In two public S3 buckets, not the API. s3://hyperliquid-archive holds market data — L2 book snapshots and asset contexts — under market_data/[date]/[hour]/[datatype]/[coin].lz4. s3://hl-mainnet-node-data holds L1 node output, including node_fills_by_block for historical trade fills, explorer_blocks, replica_cmds and misc_events_by_block.

Is the Hyperliquid S3 archive free?

The data is public but the buckets are requester-pays, so you cover the S3 transfer cost rather than Hyperliquid. Your AWS client also has to be configured to acknowledge requester-pays or the request fails. Pull only the slices you need and cache them — an unplanned full-history download is a real bill.

How far back does Hyperliquid data go?

For core perps, back through the archive's coverage of the exchange's own history. For HIP-3 builder markets, only to that dex's launch date — a market deployed in late 2025 has no 2024 history anywhere, however you query. Deep historical open interest is not published at all: you can read current OI live, but a long OI series has to be collected going forward.

Can I use the S3 archive as a live feed?

No. Uploads are periodic and completeness is not guaranteed, so it is a bulk backfill source. The reliable pattern is to seed history from S3 once, maintain your own continuous collection from the live API or a node from then on, and reconcile the overlap.