Skip to main content
Live in production, still flag-gated. Perpetuals are gated by PERPETUALS_PUBLIC_API_ENABLED, enabled in production and staging today; a deployment with the flag off returns 404 for every perpetual route. Read Overview before writing code.
Every place Hyperliquid, Polymarket Perps, and Kalshi Margin differ, collected in one set of tables: venue slugs per surface, quantity units, side spellings, notional rules, and what each venue does not publish. Kairos standardizes common economic facts and preserves native differences. The goal is one query surface without a “lowest common denominator” that loses the information required for trading, audit, or research.
Beta: The public identity, asset-role, quantity-unit, and book normalization rules on this page are live. Venue capabilities can still change before general availability.

​
One venue, four namespaces

A venue has a different spelling on each surface. These are deliberate namespaces, not aliases to guess at runtime.
Only Hyperliquid diverges — and it is the one you will get wrong. It diverges because hyperliquid already means the HIP-4 outcome markets on the WebSocket.

​
Common output

All supported venues map to the same core concepts where semantics agree:
  • stable instrument and source identity
  • exact prices, quantities, rates, and timestamps
  • direct bid and ask books
  • public trades and trade candles
  • typed mark, index, oracle, mid, and related market state
  • funding observations with interval, phase, and sign convention
  • trading accounts, orders, fills, balances, positions, and ledger entries
  • risk schedules and liquidation events
The first six are live; the last two are design targets. The canonical schema has no account, order, fill, balance, position, or ledger message, and its one liquidation message, kairos.v2.PublicLiquidation, is defined but never published.

​
Venue differences

This table is directional. A field is emitted only when the specific upstream contract and listing prove its meaning.

​
Hyperliquid: standard main-dex only

HIP-3 dex:coin identifiers are rejected, not approximated. The REST snapshot supports Hyperliquid’s standard main-dex perpetual universe only, in every environment. HIP-3 identity, metadata, collateral, and funding semantics remain design work, and the endpoint refuses those identifiers rather than applying standard-perp assumptions.
For the supported standard main-dex universe, Hyperliquid prices are quoted in USDT except for the HYPE and PURR contracts, which are quoted in USDC. Margin collateral and settlement are USDC in both cases. The snapshot keeps those roles separate in the id itself:

​
Native facts that remain visible

Normalization does not discard:
  • venue instrument, account, order, fill, trade, and liquidation IDs
  • native quantity and unit
  • raw margin or order-mode code
  • source sequence and its scope
  • price grouping and requested book depth
  • venue funding interval and sign
  • venue-specific status or risk extensions
Some of those native facts are re-spelled rather than passed through, and the mapping is fixed:
All three sides normalize to lowercase buy / sell, and a value outside the listed set is an error, not a default. Note the two rows that are easy to miss: Polymarket Perps uses contracts for trades and books but base_asset for candle volume, and it is the only venue whose notional_formula is unavailable_contract_multiplier — meaning Kairos cannot prove a notional conversion for it and you must not invent one.

​
Never inferred

Kairos does not:
  • apply prediction-market complement pricing to a perp book
  • assume every quantity is base-asset size
  • infer a contract multiplier from observed notional
  • label an unmarked trade as a liquidation
  • infer aggressor side from position direction
  • replace an absent mark with mid or last trade
  • assume every positive funding rate has the same payer
  • merge accounts across credentials, subaccounts, or environments

​
Decoder isolation

Prediction-market and perps payloads may share a provider brand while using different APIs and semantics. They use separate venue decoders and then map into shared canonical shapes only after validation.

​
Hyperliquid is two products on one venue

Hyperliquid carries both HIP-4 outcome markets (prediction markets) and perpetuals. They share a venue and nothing else: For an outcome market with numeric id N, the Yes-side coin is #{10N} and the No-side coin is #{10N+1}; those are the snapshot’s index-0 and index-1 token_ids. Every other coin on the venue is a perpetual — the # prefix is the single test that decides which pipeline a venue event belongs to, both for books and for on-chain fills. The two products use separate adapters, separate provider slugs, and separate fact tables. Do not route one through the other’s decoder.

​
Upstream references

The design is checked against the venues’ current primary documentation: Upstream documentation remains authoritative for venue behavior. Next: Availability and guarantees.