Skip to main content
Use this workflow to turn raw Hyperliquid BTC events into participant-attributed post-trade analytics. You will identify buyers and sellers, classify aggressor and passive liquidity roles (taker and maker), measure execution cost, calculate forward midpoint markouts, and summarize activity by wallet and counterparty. Here, L4 means wallet-attributed executed trades. It does not mean a complete order lifecycle reconstruction because the public trade event does not contain every order-state transition.

Run the complete notebook

Open the executed notebook when you want the same workflow with rendered tables and charts.

Set up the notebook

Clone the example repository, install its uv environment, and start JupyterLab:
The example discovers a recent active interval from the open Catalog and does not require a Polaris API key. Start with the imports and helpers used throughout the analysis:
bounded_rows prevents the tutorial from silently materializing an unbounded event stream. fetch_events raises if the query crosses the 100,000-row cap so later summaries never describe a partial sample.

Find a recent active window

The analysis uses 5 seconds of pre-trade reference data and 65 seconds after the analysis window. This buffer lets every trade find an arrival midpoint and 5s, 30s, and 60s forward references within a 5-second tolerance.
Catalog coverage can extend beyond the most recent locally available event snapshot. Search backward in 15-minute chunks until you find both raw trades and midpoint updates, then anchor the analysis to the latest observed exchange timestamp:
The selected interval moves as Catalog coverage advances. Record the printed bounds with any saved result.

Inspect normalized and raw trades

Polaris keeps the normalized data projection beside the original venue message in raw. The normalized projection provides consistent price, quantity, and side fields. Hyperliquid’s venue-native WsTrade payload adds the buyer and seller wallets, transaction hash, and trade ID required for participant attribution.
Hyperliquid defines users as [buyer, seller] and side as the aggressing side. The workflow preserves full wallet addresses in its DataFrames and shortens them only for rendered summaries.

Flatten and deduplicate raw trades

One Hyperliquid WebSocket message can contain a batch of trades. Polaris emits one normalized event per trade while retaining the complete original batch on each projection. Flattening every raw.data array therefore repeats records. Use (time, coin, tid) as the composite trade identity. Do not deduplicate on transaction hash because a zero hash can be valid for TWAP fills.
Validate participant pairs and side values before calculating wallet roles:

Attach arrival and forward midpoints

Hyperliquid’s raw activeAssetCtx message contains midPx. Deduplicate repeated midpoint projections by exchange timestamp and price before joining them to trades. For arrival cost, match backward to the latest midpoint observed within the 5-second lookback. For each markout, match forward from the exact horizon target. Leave unmatched rows missing and report their coverage instead of inventing a reference price.
Calculate the forward midpoint and aggressor-signed markout at each horizon:
Positive arrival cost means the aggressor traded through the contemporaneous midpoint. Positive markout means the midpoint subsequently moved in the aggressor’s direction.

Summarize market-level activity

Weight execution cost and markouts by trade notional so a burst of small prints does not dominate the aggregate result:

Attribute roles and flow to wallets

Each trade becomes two participant observations: the buyer receives positive signed flow and the seller receives negative signed flow. The aggressing side determines which wallet demanded liquidity and which wallet supplied it.
Reconcile the participant expansion before aggregating it. Every trade must produce exactly two rows, participant notional must equal twice the market notional, and signed base flow must net to zero:
Aggregate wallet activity and rank buyer-seller counterparty pairs:

Plot executions and midpoint

Plot raw executions over Hyperliquid’s midpoint. Marker area scales with trade notional and is capped at the 95th percentile so a single large print does not hide the rest of the sample.

Plot wallet liquidity roles

Compare the aggressor and passive notional attributed to the largest wallets:

Plot the aggregate markout curve

Plot the notional-weighted markout for aggressors at each forward horizon:

Interpret the results carefully

  • Wallet addresses are public account identifiers, not verified trader identities. One entity can control many wallets, and one wallet can represent a vault or subaccount.
  • The raw trade stream supports participant attribution after execution, but it does not expose complete order lifecycles, client order IDs, fees, positions, or realized P&L.
  • Markouts describe short-horizon price movement around an execution. They are not portfolio returns and do not include fees, funding, inventory, hedges, or activity in other markets.
  • Zero transaction hashes can be valid for TWAP fills. Use (time, coin, tid), not hash, as the deduplication key.
  • Results cover a short, dynamically selected public interval. Treat them as a reproducible workflow example, not a persistent ranking of wallets.
  • Events for mixed normalized event queries and raw-event behavior
  • Event envelope for collector and exchange timestamps
  • Catalog for market identity, coverage, and access metadata
  • Perpetuals for funding, trade-flow, liquidity, and order-book workflows
  • Liquidity / Microstructure for cross-venue spread, slippage, and L2 depth analysis
  • Jupyter Notebook for notebook setup and the curated example index