One order can produce several fills
A fill records executed trading activity. It differs from an order request, an order update and a complete order-book state. Summing fills can measure executed notional, but it does not reconstruct every resting order or establish the price available before a trade.
A bounded Supanode SQL example
SELECT coin, count() AS fills, sum(price * size) AS notional
FROM hyperliquid.raw_node_fills_by_block
PREWHERE utc_fill_dt = toDate('2026-10-01')
GROUP BY coin
ORDER BY notional DESC
LIMIT 20The table and partition column follow Supanode's Hyperliquid Indexer Docs. Use provisioned credentials from environment variables and confirm the requested date is inside current coverage. The example performs no account action.
Define the unit of analysis
- Choose fill-level or order-level analysis before joining tables.
- Keep market identifiers, side and maker/taker interpretation consistent.
- Use the documented timestamps and within-block ordering fields when event order matters.
- Inspect liquidation, TWAP and builder-related columns only over periods where those fields are populated.
Know what a fill table cannot answer
A fill dataset does not automatically contain a funding-rate time series or an order-level book at each moment. Supanode documents its fill database and separately provisioned book archive as distinct components. Use the appropriate source for each hypothesis, and compare sample counts against a second official source where its retention permits.