How to monitor Hyperliquid HIP-4 outcome markets

A dropped connection can leave your Hyperliquid HIP-4 dashboard missing trades even after live prices resume. Recovering those trades and tracking settlement require more than an order-book subscription.

A monitor needs to discover outcome markets and map their coin identifiers before it can track activity. It must combine live updates with historical fills and settlement data. The examples below show how to build that workflow within the API limits.

For contract mechanics, read the Hyperliquid HIP-4 mechanism guide. If you already use the Polymarket API, the comparison below explains how discovery and settlement queries differ.

Discover outcomes before encoding coins

Start with outcomeMeta on Hyperliquid's Info API:

curl -sS https://api.hyperliquid.xyz/info \
  -H 'Content-Type: application/json' \
  -d '{"type":"outcomeMeta"}'

Read each entry's outcome, sideSpecs, quoteToken, and description. Preserve question associations when present. Use the side index for encoding and the metadata label for display.

A read-only check on September 14, 2026 returned 222 outcomes and 31 questions. All returned outcomes used USDC as quoteToken. Earlier launch descriptions referenced USDH, so hardcoded collateral would give the wrong result.

The active set included recurring BTC, ETH, SOL, and HYPE binaries, plus question-linked outcomes. Discover the current set instead of assuming one daily BTC market.

The asset-ID specification defines the encodings:

encoding = 10 * outcomeId + side
trade coin = #encoding
balance token = +encoding
asset ID = 100000000 + encoding

Here, outcomeId is the ID read from the discovery entry's outcome field. Dwellir's Index uses the parameter name outcomeId.

Outcome 3 is an arithmetic example, not a claim that the market remains active. Side 1 gives #31, +31, and 100000031.

The following function derives all representations without assuming the side labels:

def outcome_identifiers(outcome_id: int, side: int) -> dict:
    if side not in (0, 1):
        raise ValueError("Outcome side must be 0 or 1")
    encoding = 10 * outcome_id + side
    return {
        "coin": f"#{encoding}",
        "balance_token": f"+{encoding}",
        "asset_id": 100_000_000 + encoding,
    }

Using +N for an order-book request can return no book. Keep trade and balance representations in separate fields.

The HIP-4 specification describes merged books. Buying one side at price p shares liquidity with selling the other at 1 - p. Historical order responses can expose primary and dual orders separately. Preserve their relationship when processing those records.

Compare the monitoring workflows

Polymarket combines Gamma market discovery, a central limit order book, or CLOB, and Polygon contracts. Hyperliquid HIP-4 uses HyperCore outcome coins, so your monitor needs different identifiers and queries.

HyperEVM JSON-RPC queries read a different execution environment. They do not return HyperCore outcome books. Similarly, Polygon eth_getLogs cannot retrieve a HIP-4 fill or settlement.

A market fill establishes that a trade executed. Outcome settlement determines the payout after the contract resolves. Store these as separate events.

Subscribe to the current trade coin

Take the #N coin derived from current metadata. A book snapshot uses this request body:

{"type":"l2Book","coin":"#30610"}

#30610 was the side-0 coin for BTC outcome 3061 during the September 14 check. Replace it with a currently discovered coin before running a monitor.

Send the following message to wss://api.hyperliquid.xyz/ws for public trade updates:

{"method":"subscribe","subscription":{"type":"trades","coin":"#30610"}}

Subscribe separately to each coin you need. userFills subscriptions are user-specific; filter their returned fills by coin. A market-wide trades feed avoids subscribing to every participant just to observe executions.

Dwellir's Order Book Server and gRPC service provide other streaming options. Check their filters and event schemas before choosing one. A live stream still needs a recovery source for missed intervals.

If an SDK builds asset mappings only from perpetual and spot metadata, verify outcome support before submitting orders. Missing name or asset mappings can cause lookup failures. The Python SDK source shows how these maps are constructed.

Count each public limit separately

Hyperliquid's public limits apply different counters to REST and WebSocket traffic:

Incoming market updates do not consume the client-sent message allowance. REST weight also does not measure the number of streamed trades.

One metadata request and two book snapshots each minute cost 24 weight, or 2% of the REST allowance. A public endpoint can support that workload. Streaming capacity depends on the separate subscription limits and your application's processing capacity.

Query historical fills and settlement on the Index

Dwellir's outcome-market Index methods use a separate host:

https://api-hyperliquid-index.n.dwellir.com/YOUR_API_KEY/info

settledOutcomes is an Index method. Sending that method to the public Hyperliquid Info API does not query Dwellir's settlement records.

Use either a coin filter or an outcomeId and optional side filter. Do not combine coin with those fields. The fill reference documents the request format.

The response is an array of fills. Build the next cursor as ${lastFill.time}_${lastFill.txIndex} from the last returned fill. Keep the filters and endTime unchanged until pagination finishes. Store them with the cursor so a restart resumes the same query.

The settlement reference exposes settleFraction. Side 0 pays that fraction of the quote token; side 1 pays 1 - settleFraction. Binary results use 1 or 0. Read the actual fraction instead of inferring payout from the final trade price.

Keep the expired outcome's identity and collateral with its positions. A recycled builder slot can host a new contract with a new outcome ID. Never transfer the old position to the replacement contract merely because its label looks similar.

For bulk history, use the documented historical-data sources or Index queries. Live WebSocket and gRPC connections cannot replay data they never received.

Check the indexer before release

• Refresh metadata and retain question relationships, side labels, and collateral.
• Keep trade coins, balance tokens, and asset IDs distinct.
• Store trade execution and outcome settlement as separate events.
• Budget REST weight, subscriptions, and user limits independently.
• Test a disconnect, a paginated recovery, and an outcome rollover.
• Reconcile the final payout with the settlement record and quote token.

The Hyperliquid network page lists endpoint options. For workload planning, contact the Dwellir team with your markets, user count, and history requirements.