Documentation

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.

NOTE

Database name is hyperliquid. Connection details are provisioned per customer over Telegram - see Connection.

What's indexed

TableWhat it holds
raw_node_fills_by_blockOne 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_orderThe same activity rolled up per order, on a 90-day window
view_perpetual_walletPer-wallet aggregate: PnL, volume, win count, ROI quantiles, active days
view_wallet_positionLatest 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.

WARNING

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.

ComponentFormat
Book checkpointsMessagePack ABCI snapshots, order-level
Book diffshourly zstd-compressed streams
Order statuseshourly zstd-compressed streams
Fillshourly 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:

  1. 1
    Insert

    A new order appears, with its order ID, side, price and size.

  2. 2
    Amend

    An existing order's remaining size changes.

  3. 3
    Remove

    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

  1. 1
    Pick 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.

  2. 2
    Load the hourly diffs

    Pull every hourly diff file covering the span between the checkpoint and your target time.

  3. 3
    Replay 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.

  4. 4
    Sample

    Walk the reconstructed book across your window and read bid, ask, midpoint, spread and depth at whatever interval your study needs.

TIP

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.

NOTE

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

  1. 1
    New connection

    Create a New Connection and select the ClickHouse driver.

  2. 2
    Host and port

    Enter the host and port we provisioned for you.

  3. 3
    Database

    Set the database to hyperliquid.

  4. 4
    Credentials

    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
WARNING

Always filter on utc_fill_dt in PREWHERE. It is the partition key. Without it a query scans all 225 GB.

Next steps

Table reference

Every column, type, and partition key.

Query examples

Leaderboards, liquidations, TWAP scoring, block timing.

Pricing

Tiers and what is included.

Provision access or start a trial: @supanode_tgs.