Data Methodology

Ironflow’s feed comes directly from the venue — the same events validators process. We do as little as possible to the data before it reaches your query window, and we’re explicit about every normalization choice so you can rebuild any view you need from raw fills. This page documents the per-event-type choices. Continuous cross-checks against external sources are documented in Reliability.

Schema at a glance

Each market is keyed by a stable identity, not a display string:

Field	Meaning
`venue`	Exchange — always `hyperliquid`
`market_class`	`perp`, `spot`, `prediction`, `option`
`market_id`	Venue-native asset id; survives renames and re-listings
`issuer`	HIP-3 builder code (`flx`, `xyz`, …) — empty for native HL
`base_asset` / `quote_asset`	`BTC` / `USDC`, etc.
`display_symbol`	Human-readable form: `BTC-PERP`, `flx:GAS-PERP`, `HYPE/USDC`
`ts`	Block time, microsecond precision

The display_symbol is what API responses expose as market. Cross-issuer queries use base_market (the suffix-only form, e.g. GAS-PERP) and issuer independently — see Sources & Markets.

Candles / OHLCV

What we store. Every fill — including liquidation fills and internal/cross-book trades — contributes to the candle. We don’t pre-filter the tape. Why. Filtering for display is a one-line WHERE clause; recovering filtered data after the fact is impossible. We default to the more literal capture.

-- Full tape (default Ironflow view)
SELECT toStartOfMinute(ts)  AS bucket,
       count()              AS trades,
       sum(size)             AS volume
FROM fills
WHERE display_symbol = 'BTC-PERP'
  AND ts >= now() - INTERVAL 1 HOUR
GROUP BY bucket
ORDER BY bucket;

-- Excluding liquidation fills (display-style view)
SELECT toStartOfMinute(ts)  AS bucket,
       count()              AS trades,
       sum(size)             AS volume
FROM fills
WHERE display_symbol = 'BTC-PERP'
  AND ts >= now() - INTERVAL 1 HOUR
  AND liquidation = false
GROUP BY bucket
ORDER BY bucket;

Funding rates

What we store. Every funding-rate emission from the venue, written by a single dedicated process to keep the table free of write conflicts. Cadence. Hourly on Hyperliquid; some HIP-3 builder markets emit on different schedules. Continuity is monitored per market.

SELECT toStartOfHour(ts) AS hour,
       avg(rate)         AS hourly_rate,
       sum(rate)         AS cumulative
FROM funding_rates
WHERE venue = 'hyperliquid'
  AND display_symbol = 'BTC-PERP'
  AND ts >= now() - INTERVAL 48 HOUR
GROUP BY hour
ORDER BY hour;

HIP-3 builder markets

HIP-3 markets are namespaced as <issuer>:<base>-PERP (e.g. flx:GAS-PERP). Three filter modes work identically across every endpoint:

-- Single builder's market
WHERE display_symbol = 'flx:GAS-PERP'

-- All builders' GOLD-PERP across issuers
WHERE issuer != '' AND base_asset = 'GOLD'

-- Native HL only (no HIP-3)
WHERE issuer = ''

See Sources & Markets for the full filter scheme.

Spot pairs

HL spot is queryable by either form:

-- Human pair
WHERE display_symbol = 'HYPE/USDC'

-- Numeric coin alias (HL-internal form)
WHERE display_symbol = '@285'

Spot has no funding, no liquidations, and no market_class='perp'. Filter by market_class = 'spot' to scope queries.

At-least-once delivery

The pipeline is at-least-once end-to-end: every event is delivered to ClickHouse at least once, and duplicates are collapsed in the storage layer. A retried recovery on the same window is a no-op — you can’t double-count, and you can’t accidentally miss a row. See Reliability for how the gap detection, recovery, and audit layers fit together.

Getting Started

Concepts

Guides

Terminal

SDKs

Schema at a glance

Candles / OHLCV

Funding rates

HIP-3 builder markets

Spot pairs

At-least-once delivery

​Schema at a glance

​Candles / OHLCV

​Funding rates

​HIP-3 builder markets

​Spot pairs

​At-least-once delivery

Schema at a glance

Candles / OHLCV

Funding rates

HIP-3 builder markets

Spot pairs

At-least-once delivery