Skip to main content
This page explains the venue categories Polaris covers and the pipeline behind the data. Read it once, then discover real markets with Catalog.

​
What frontier venues are

Frontier venues publish market data over public WebSockets or onchain events rather than licensed feeds. They appear and disappear faster than legacy exchanges, and each has its own identifiers, timestamp conventions, and payload shapes. Examples include Hyperliquid and dYdX v4 (order-book DEXes), Deribit and Aevo (options DEXes), and onchain quoting protocols like FermiSwap. Polaris records these venues and normalizes their output into one query surface, so switching venues does not mean rewriting a parser. The venue-native payloads stay available through Raw data for replay and validation.

​
Venue categories

Browse the live source list on Market coverage.

​
How data is captured

  1. A Polaris recorder subscribes to each venue’s native channels and persists every raw message as a capture envelope.
  2. Captures are standardized into normalized event rows — trades, L2 updates, funding-rate observations, and more. Each keeps the source_capture_id of the raw message it was decoded from.
  3. Standardized history is published in snapshot files that the CLI, SDKs, and REST API share. SDKs resume from a recent snapshot instead of reading row by row from day one; this is snapshot-first replay.
Two consequences worth remembering:
  • collector_timestamp (when the recorder saw the message) is the reliable ordering timeline; exchange_timestamp is nullable venue provenance. See Data conventions.
  • Because raw captures are kept, anything standardized can be cross-checked against the original payload with Raw data.

​
Access states

Each Catalog market carries access.status and an optional public_cutoff_date: Limits and windows per endpoint are summarized in Access and rate limits.

​
Where to go next