Hyperliquid indexer
Every Hyperliquid perpetual fill in ClickHouse — 2.9 billion rows with nanosecond block timing, liquidation and TWAP context, builder codes, plus an order-level book archive for exact-moment reconstruction.
// updated 2026-08-22
Every Hyperliquid perpetual fill, queryable with plain SQL. 2.9 billion rows carrying nanosecond block timing, liquidation and TWAP context, builder codes, fees and position deltas.
Database name is hyperliquid. Connection details are provisioned per customer over Telegram - see Connection.
What's indexed
| Table | What it holds |
|---|---|
raw_node_fills_by_block | One row per fill as read from the node: price, size, side, position before, realized PnL, fee, builder, TWAP and liquidation context, nanosecond block time |
agg_fulfilled_order | The same activity rolled up per order, on a 90-day window |
view_perpetual_wallet | Per-wallet aggregate: PnL, volume, win count, ROI quantiles, active days |
view_wallet_position | Latest position per wallet and market |
Scale as of 1 September 2026: 3,131,968,443 fills, 225.58 GB, covering 27 July 2025 to the present across all perpetual markets, updated in real time. Full column lists are in the Table reference.
No funding-rate table. Funding is not part of this dataset. The Indexer covers fills and everything hanging off a fill - liquidations, TWAP membership, builder codes, fees, priority gas, position deltas. For live funding, use the Hyperliquid API alongside it.
What you get that a public API will not give you
Nanosecond block timing
utc_block_dttm is DateTime64(9) - nanosecond resolution on the block, alongside block_id and block_tx_idx for exact ordering inside it. That is what latency analysis, cross-venue arbitrage timing, and order-flow pattern detection need; millisecond fill time is not enough.
Full position context
Each fill carries start_position (size before the fill), closed_pnl, order_crossed_spread_flg for the maker/taker split, and the liquidation triple - liquidation_user, liquidation_mark_px, liquidation_method.
Attribution
builder and builder_fee show which front-end or API routed the order and what it earned. client_order_id, twap_id and priority_gas complete the picture of how the order was constructed.
Order-book archive
Fills tell you what traded. They do not tell you what the book looked like at the moment it traded. For that we keep an order-level archive of the Hyperliquid book, provisioned separately from the ClickHouse database.
| Component | Format |
|---|---|
| Book checkpoints | MessagePack ABCI snapshots, order-level |
| Book diffs | hourly zstd-compressed streams |
| Order statuses | hourly zstd-compressed streams |
| Fills | hourly zstd-compressed streams |
Why order-level rather than price-level
Aggregated price-level data cannot be replayed correctly. If three orders rest at the same price and one is cancelled or partially filled, a price-level feed only shows the level shrinking - it cannot tell you which order moved. Replaying by order ID keeps that correct.
Each diff record does one of three things:
- 1Insert
A new order appears, with its order ID, side, price and size.
- 2Amend
An existing order's remaining size changes.
- 3Remove
The order ID leaves the book.
Only after the replay are live orders aggregated into price levels. From there you can read best bid, best ask, spread, live order count, and depth within a chosen basis-point band around the midpoint - at any second inside the window, not just at candle boundaries.
Reconstructing a moment
- 1Pick the checkpoint
Take the newest checkpoint at or before your target time. It carries the order-level state of the book plus the metadata you need - the historical numeric asset encoding and the size precision for that market.
- 2Load the hourly diffs
Pull every hourly diff file covering the span between the checkpoint and your target time.
- 3Replay by order ID
Skip diff blocks already represented in the checkpoint, then apply the rest in order. Aggregate into price levels only at the end.
- 4Sample
Walk the reconstructed book across your window and read bid, ask, midpoint, spread and depth at whatever interval your study needs.
This is how you do cross-venue work properly. Replay the Hyperliquid book second by second across the exact window of an event on another venue, and you are comparing real books rather than coarse candles. Archive access is arranged per customer - message @supanode_tgs with the markets and date range you need.
Connection
The Indexer is exposed over ClickHouse. Connect with standard tooling and run your own SQL.
Host, port and credentials are provisioned per customer via Telegram @supanode_tgs. The database name is hyperliquid. Keep credentials in environment variables or a local .env, never in source.
Python
import os
import clickhouse_connect
client = clickhouse_connect.get_client(
host=os.environ['CH_HOST'],
port=int(os.environ['CH_PORT']),
username=os.environ['CH_USER'],
password=os.environ['CH_PASSWORD'],
database='hyperliquid',
secure=True,
)
df = client.query_df("""
SELECT utc_fill_dttm, wallet_address, coin, side, price, size,
price * size AS notional, closed_pnl, fee
FROM raw_node_fills_by_block
PREWHERE utc_fill_dt = today()
ORDER BY notional DESC
LIMIT 100
""")
print(df.head())
DBeaver
- 1New connection
Create a New Connection and select the ClickHouse driver.
- 2Host and port
Enter the host and port we provisioned for you.
- 3Database
Set the database to
hyperliquid. - 4Credentials
Enter your username and password, then test the connection.
First query
SELECT
coin,
count() AS fills,
sum(price * size) AS notional_volume,
uniq(wallet_address) AS traders
FROM hyperliquid.raw_node_fills_by_block
PREWHERE utc_fill_dt = today()
GROUP BY coin
ORDER BY notional_volume DESC
LIMIT 20
Always filter on utc_fill_dt in PREWHERE. It is the partition key. Without it a query scans all 225 GB.
Next steps
Every column, type, and partition key.
Leaderboards, liquidations, TWAP scoring, block timing.
Tiers and what is included.
Provision access or start a trial: @supanode_tgs.