> 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/api-reference/analytics-and-digests.md).

# Analytics, DefiLlama & Digests

The research layer: market-wide calibration and resolution statistics, aggregated leaderboards, per-outcome belief curves, DefiLlama-adapter feeds, and periodic recap digests.

## GET /v1/analytics/calibration

Is the market as a whole well-calibrated? For every settled outcome, the last pre-settlement Yes-side price is treated as the market's prediction and compared to the realized result — bucketed into a reliability curve with an overall Brier score.

| Query param | Type | Default | Description                                     |
| ----------- | ---- | ------- | ----------------------------------------------- |
| `buckets`   | int  | `10`    | 2–50; changes bucket width only, not the sample |

```bash
curl -H "X-API-Key: $MUTE_KEY" "https://api.mute.sh/v1/analytics/calibration"
```

```json
{
  "buckets": 10,
  "sample_size": 732,
  "brier": 0.084163,
  "curve": [
    { "bucket": 1, "p_low": 0, "p_high": 0.1, "n": 216, "mean_predicted": 0.009, "observed_rate": 0.00463 },
    { "bucket": 6, "p_low": 0.5, "p_high": 0.6, "n": 178, "mean_predicted": 0.54, "observed_rate": 0.286517 }
  ],
  "method": "…"
}
```

Read it like any reliability diagram: a calibrated market has `observed_rate ≈ mean_predicted` per bucket. The live curve shows real structure — extreme-probability buckets are sharp, mid-range buckets (things priced \~50–60%) currently resolve Yes far less often than priced. `brier` is the overall mean squared error (0.25 = uninformative baseline; 0.084 is strong). Sparse buckets return `null` rates rather than fake zeros. Cached 1 h.

## GET /v1/analytics/resolution-summary

Settlement totals, optionally grouped.

| Query param | Description                                                                      |
| ----------- | -------------------------------------------------------------------------------- |
| `group_by`  | `category` or `underlying`; anything else = one ungrouped row (`group_by: null`) |

```json
{
  "group_by": "category",
  "data": [
    { "group": "crypto", "total_settled": 366, "total_payout": 29148955, "winners": 33654, "losers": 18121, "avg_time_to_resolution_sec": 85565.59 },
    { "group": "sports", "total_settled": 272, "total_payout": 24689378, "winners": 25013, "losers": 18738, "avg_time_to_resolution_sec": 578332.29 }
  ]
}
```

`total_settled` counts **outcomes**; `winners`/`losers` count **settlement fill legs** (many holders per outcome) — that's why they're \~100× larger; don't ratio them against `total_settled`. `avg_time_to_resolution_sec` is listing→settlement: crypto dailies \~1 day, sports \~1 week, macro \~2.5 weeks. Cached 1 h.

## GET /v1/analytics/outcomes/:id/belief-curve

The probability-over-time series for one outcome, creation → settlement — chart-ready with the resolution marker.

| Query param | Type | Default | Description                                                                   |
| ----------- | ---- | ------- | ----------------------------------------------------------------------------- |
| `points`    | int  | `200`   | 2–1000; stride-downsampled from real fills, first and last points always kept |

```json
{
  "outcome_id": 760,
  "is_settled": true,
  "settlement_prob": 0,
  "settled_at": "2026-07-06 06:00:18.129",
  "source": "fills.px (Yes-side per-fill price; no implied-prob time-series table exists)",
  "data": [
    { "t": "2026-07-05 06:10:00.877", "prob": 0.10722 },
    { "t": "2026-07-06 04:48:19.027", "prob": 0.5 }
  ]
}
```

Points are actual Yes-side trade prices (a sampled subset, not time-bucket averages — the `source` string says so explicitly). `settlement_prob` is `1`/`0` for how it resolved, `null` while open. Both bad and unknown ids return `404` — distinguish by the message (`Invalid outcome id` vs `Outcome N not found`). Cached 30 s.

## GET /v1/analytics/incoherence

Cross-outcome arbitrage signal: for each multi-outcome question, the sum of its named outcomes' Yes prices minus 1 — a coherent book sums to ≈1, so `incoherence` far from 0 flags mispricing. Rows: `{question_id, question, sum_named_yes, incoherence}`, sorted by `|incoherence|`, `limit` up to 500. Only outcomes with live price marks participate in the sum; questions come and go from this list as books quiet down. Cached 30 s.

## GET /v1/analytics/leaderboard/builders · /traders

Rollup-backed leaderboards, cheaper and 1 h-cached versions of the live leaderboards:

* **`/builders`** — `{builder, builder_name, total_fees_usdc, fills}` sorted by fee revenue (`fills` counts fee-bearing fills only). `limit` up to 500.
* **`/traders`** — `{user, total_volume, total_trades, total_pnl}`; `sort` accepts `pnl`, `trades`, or `volume` (`limit` up to 200). These are lifetime rollup totals — for windowed or filtered rankings use [`GET /v1/leaderboard`](/mute.sh/api/api-reference/builders.md#get-v1leaderboard).

***

## DefiLlama feeds: GET /v1/defillama/\*

Purpose-built series for DefiLlama dimension adapters (and anyone wanting daily protocol totals in one call). No parameters — each returns the full daily history since HIP-4 launch (2026-05-02), oldest first.

### /volume

```json
{
  "totalVolume": 313148103.36,
  "dailyVolume": [
    { "date": "2026-05-02", "daily_volume": 2351355.36, "trades": 35781, "unique_users": 1860 }
  ]
}
```

### /fees

```json
{
  "totalFees": 5459.01,
  "dailyFees": [
    { "date": "2026-05-02", "daily_fees": 9.24, "fee_trades": 412, "unique_users": 23 }
  ]
}
```

`daily_fees` is builder-fee revenue (fills carrying a builder attribution). Adapter note: the rows are `{date, value}` objects, not DefiLlama's native `[timestamp, value]` tuples — map them in your adapter. Volume counts all non-settlement fills (including AMM share-conversion legs), so it reads slightly higher than a strict Buy/Sell-only definition.

### /summary

One protocol snapshot (`protocol`, `chain`, volume/trades/users totals, fee totals, market counts). Prefer `/volume` + `/fees` as your adapter dependencies — they're lighter and independently cached; `/summary` bundles a heavier metadata query and returns `503` + `Retry-After` when that query can't complete in time.

***

## Digests: GET /v1/digest/\*

Pre-computed recap reports for a trailing window — the "weekly wrap-up" data source for newsletters, bots, and dashboards. All three share:

* `period` query param: `1d` | `7d` | `30d` (default `7d`; unrecognized values **silently become `7d`** — check the echoed `period`)
* **Delta objects**: windowed metrics come as `{current, prior, change, pct}` — this window vs the previous one, `pct: null` when the prior window was zero
* a `degraded: []` array that honestly lists sections omitted for data-availability reasons
* 1 h caching; the heavy network-wide views can return `503` + `Retry-After: 30` under load — back off and retry rather than hammering

### /global

Network-wide: `totals` (volume/trades/active-traders deltas), `trending_markets` (top 10 by window volume), `new_markets` (up to 25 listed in-window), `biggest_settlements` (top 10 by payout), `top_traders`, `biggest_whales` (top 10 single fills by notional), `degraded`.

### /builder/:address

The builder report card: `summary` with `volume_routed`/`trades`/`unique_traders` deltas, `new_traders` (first-ever touch of **this builder** in-window — not new-to-network), `fees` (`period` delta + `cumulative` all-time — the cumulative figure ignores `period` by design), `market_share_pct`, plus `top_markets`, `biggest_whale`, and `settlements` on routed markets.

### /trader/:address

The wallet journal — live example:

```json
{
  "period": "7d",
  "trader": "0xaddc…ff54",
  "generated_at": "2026-07-06T08:48:14.163Z",
  "pnl": {
    "realized": { "current": 68267.02, "prior": 34352.83, "change": 33914.19, "pct": 98.72 },
    "cumulative": 264847.33,
    "roi_pct": 21.14,
    "win_rate_pct": 81.82,
    "wins": 9,
    "losses": 2
  },
  "positions": { "opened": 0, "closed": 0, "still_open": 213, "markets_traded": 18 },
  "settlements": { "won": 9, "lost": 2, "total_payout": 247380, "settled_pnl": 67363.85, "biggest_win": 18942.95, "biggest_loss": -7622.8 },
  "closing_soon": [
    { "coin": "#7420", "outcome_id": 742, "net_size": 34094, "title": "Recurring", "underlying": "BTC", "expiry": "2026-07-05 06:00:00.000", "implied_prob": 0, "mark_to_market_usd": 0 }
  ],
  "degraded": [
    "holdings_that_moved omitted — no implied-prob history table",
    "rank_change omitted — no prior-window leaderboard snapshot stored"
  ]
}
```

Reading notes:

* `pnl.realized` / `settlements` / `positions.opened|closed` respect the window; `pnl.cumulative` and `positions.still_open` are all-time.
* `closing_soon` lists open positions on unsettled markets ordered by expiry — it is **not** window-filtered (same list for any `period`). Its `mark_to_market_usd` depends on a live price mark being available for the position's coin; when none exists it reads `0`, not `null` — treat `implied_prob: 0` there as "no live mark", not "worthless".
* Malformed address → `400 Invalid address`.


---

# 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/api-reference/analytics-and-digests.md?ask=<question>&goal=<endgoal>
```

`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.