> For the complete documentation index, see [llms.txt](https://mute-sh.gitbook.io/mute.sh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mute-sh.gitbook.io/mute.sh/api/getting-started/why-not-raw-data.md). # Why not raw data? HIP-4 lives on-chain, so its data is *public*. Public is not the same as *usable*. The chain hands you opaque numeric coin codes, a trade feed that silently mixes real bets with bookkeeping, prices with no units, and market results that live somewhere other than the trades — with no names attached, no guarantee the history survives, and no way to push any of it to a phone. Every one of those is a real, documented property of the raw feed, not a strawman. Here is exactly what you get, and exactly what you'd have to build to turn it into a product. ## What the chain actually hands you | What the raw chain gives you | What mute returns instead | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Bare coin codes — `#7380`, `#1541`. No name, no idea which market or side they are. | [`GET /v1/markets/coin-labels`](/mute.sh/api/api-reference/markets.md#get-v1marketscoin-labels): one cached call turns `#7380` into `World Cup Round of 16: Mexico vs England — Mexico · Yes` for the whole universe. | | Names, categories, sides, and resolution text aren't in the trade data — they come from a **separate** Hyperliquid `outcomeMeta` info call, keyed by numeric ids, in a non-obvious `{outcomes, questions}` shape (not the `{universe}` you'd assume). | [`/v1/outcomes/:id`](/mute.sh/api/api-reference/outcomes.md) and [`/v1/markets/meta/outcomes`](/mute.sh/api/api-reference/markets.md#get-v1marketsmetaoutcomes): titles, sides, AI categories, and resolution criteria, joined for you. | | HIP-4 markets are Hyperliquid **spot** assets (not perps — nobody expects that), addressed by pair index, and each market is *two* coins derived as `#(outcome_id × 10 + side_idx)`. You reverse that math and merge the pair yourself. | The mapping is done for you: pass **either** side of the pair to any `:coin` endpoint and get the whole market back. | | The fills feed carries **seven** `dir` values and only two are trades. `Buy`/`Sell` are real; `Negate`/`Split`/`Merge Outcome`, `Merge Question`, and `Settlement` are AMM inventory plumbing and payout sweeps. Count them as trades and your volume, trade counts, and "big confident bet" detectors are all silently wrong — a `Negate Outcome` at `px = 1.0` reads like a huge bet and isn't. | Every stat mute serves — `volume`, `trades`, holders, leaderboards — already excludes plumbing and settlement legs. [`/v1/fills`](/mute.sh/api/api-reference/fills-and-activity.md#the-dir-taxonomy) documents the full taxonomy and lets you filter `dir=Buy`. | | `px` is a bare probability in `(0, 1)` with nothing saying so; `sz` is in outcome **shares**, not dollars. The USD notional is `px · sz` — a convention you must know before any number means anything. And `px` snaps to `1`/`0` at settlement, so a naive "last price" reads a resolved market as certainty. | USD `notional` is precomputed on every fill and activity event; `volume` is USD. `impliedProb` is served apart from the final print and goes **`null`** after settlement, so you never mistake a resolved market for a 100% one. | | Resolution isn't in the trade stream. It's a **separate** on-chain settle action; the winning side comes from `settledOutcome` / `settle_fraction` data distinct from the trades — and that source can be *missing*. In the raw feed all you see is a burst of `px=1`/`px=0` sweep fills sharing **one action hash**, which you must join back to the separate result to know what happened. | [`/v1/settledOutcomes`](/mute.sh/api/api-reference/outcomes.md#get-v1settledoutcomes): winner, payout, per-side holders and PnL, joined to the market — and derived from the sweep fills when the canonical source is unavailable, so it's never blank. | | Query a market that resolved last week and it may simply be **gone** — Hyperliquid expires old markets out of its own API, metadata and all. | The full archive since HIP-4 launch (**2026-05-02**) is always there; settled data is served `immutable`. | | Zero sports context. No team, no score, no kickoff time, no fixture — just a coin code and a probability. Matching a market to the real-world game is entirely on you. | [`/v1/sports/*`](/mute.sh/api/api-reference/sports.md) (Enterprise) joins markets to live fixtures: team codes, flags, scores, kickoff status, match events, news, and highlights, with a confidence-scored fixture binding. | | No push. The chain never calls you — you poll it, or hold a stream open and hope. Nothing in the raw feed can wake a phone, and there is no notion of "alert me when **this wallet** fills." | Signed [webhooks](/mute.sh/api/api-reference/webhooks-telegram-and-account.md) (Scale + Enterprise) POST the event to your server the instant it lands — over HTTP or Telegram, with retries, delivery history, and replay on Enterprise. The push layer a mobile app can't live without. | | The public data exports arrive as **batched dumps** — raw rows, on a delay, with none of the context above attached. The only real-time alternative is running your own Hyperliquid node. | Served **real-time** over REST + SSE, already enriched — plus **sub-second** raw block headers over [gRPC](/mute.sh/api/api-reference/grpc-streaming.md) (Enterprise). No node to run, no batch lag. | ## What you'd have to build To get from the raw chain to something you can ship, the checklist is roughly: * [ ] A coin → name / metadata resolver, kept in sync as new markets list and Hyperliquid expires old ones — **plus your own archive**, so last week's resolved markets don't vanish. * [ ] The `outcome_id × 10 + side_idx` coin math in both directions, and pair-merging the two coins of every market into one view. * [ ] A `dir` classifier that strips `Negate`/`Split`/`Merge Outcome`, `Merge Question`, and `Settlement` legs **before any** volume, trade, or holder count. * [ ] USD conversion (`px · sz`) on every row, and probability handling that tells a live quote apart from a settled `1`/`0`. * [ ] A settlement reconciler: group sweep fills by their shared action hash, join them to the separate settle result, and cope when `settledOutcome` is missing. * [ ] Aggregations that pick the right fill set — settlement-scoped for win-rate and PnL, trade-scoped for volume — because mixing them quietly corrupts every leaderboard. * [ ] For sports: a fixture matcher (market → real-world game, with a confidence score) and a live score / kickoff feed. HIP-4 supplies none of it. * [ ] Your own delivery layer: SSE fan-out with reconnection and `tid` dedup, or — for mobile — a webhook → APNs/FCM push bridge you build, sign, retry, and operate. * [ ] Ingestion itself: poll the API on the right cadence, or run a Hyperliquid node and tail it, and absorb the lag on the public exports. Each of those is a subtle, load-bearing piece of infrastructure. Getting any one wrong ships wrong numbers to users who are betting real money. ## Skip all of it mute already did this. Start with the [60-second quickstart](/mute.sh/api/getting-started/readme.md#60-second-quickstart) — one `curl`, real names, USD notional already computed. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://mute-sh.gitbook.io/mute.sh/api/getting-started/why-not-raw-data.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.