Skip to main content
Market breadth reports the percent of eligible instruments trading above their current session VWAP. It is a cross-sectional read on a whole venue family, not a per-symbol series: one snapshot describes the venue at one minute. The measure is equal-weighted by instrument. A heavily traded builder market and a thin one each count once. Every snapshot ships the counts it was computed from, so the denominator is auditable rather than implied. Breadth is published separately for Hyperliquid core perps and HIP-3 builder markets. There is no Spot breadth route, and HIP-4 is deliberately excluded because outcome markets are probability-priced binaries, where a percent-above-VWAP number would not carry the same meaning.

How the number is computed

The session is the UTC calendar day and resets at 00:00 UTC. Each instrument’s VWAP is computed from candle quote volume divided by base volume for the session so far, not from a typical-price approximation. The comparison price is the close of the most recently completed one-minute candle. Snapshots are written every minute. value_pct is 100 * above / eligible, so eligibility determines the denominator: An instrument whose last close is exactly its VWAP is counted in at. It stays in the denominator and is not counted as above. Use the counts to check the denominator:

Routes

Get the latest snapshot

The /current route takes no parameters and returns a single object with meta.count of 1.
Requests use the standard X-API-Key header described on Authentication. Breadth is in the open catalog and available on all plans. Credits are row-based, so a full day of raw one-minute history is about 1,440 rows.

Request parameters

The /current route accepts no parameters. The history route accepts: History is returned in ascending time order. A limit above the maximum is clamped to 1000 silently rather than rejected, so read meta.count instead of assuming the request size was honored. An unsupported interval returns 400 and names the accepted values. The 24-hour default window is the parameter most likely to surprise. A request for interval=1d&limit=30 without a start returns only the buckets inside the last day, not thirty days. Set start explicitly for any multi-day pull. For a historical window, supply both start and end: setting an older end alone does not move the default start and can return an empty series.

Example response

These bounded requests return one snapshot from each family at the same minute. Responses were retrieved from the live API; request IDs vary by request.
Core perps return empty namespaces maps because they have no builder namespace. In HIP-3, the maps include only namespaces with a nonzero count; an absent namespace key means zero.

Response fields

Responses use the { success, data, meta } envelope. /current returns one object in data; history returns an array.

Read the number correctly

Four behaviors will produce wrong charts if breadth is treated as an ordinary numeric series. value_pct can be null, and null is not zero. When nothing is eligible there is no denominator, and the API says so. Rendering that as 0% asserts that eligible instruments existed and none was above VWAP, which is a different claim. Carry the null through to the chart as a gap. Never average value_pct across snapshots. Each snapshot has its own denominator, so the mean of percentages is not the percentage of the pooled set. To reduce resolution, use interval, which selects the last snapshot in each bucket server-side rather than averaging. A missing minute means a skipped write, not a zero. If a run fails or is skipped, there is no snapshot for that minute. /current returns the most recent stored snapshot with its original calculated_at. Compare calculated_at against your own clock before treating a /current read as fresh. coverage_ratio moves with the clock, not only with the market. Many HIP-3 products track underlying assets with fixed trading hours. Instruments leave the eligible set when their last completed candle is older than 5 minutes. Market hours can affect eligibility, but ingestion delays can also cause candles to become stale; the counts alone do not distinguish the cause. In the last snapshot of each UTC day from 2026-08-28 through 2026-09-07, eligible ranged from 62 to 115 against 225 to 231 candidates, and coverage_ratio ranged from 0.273 to 0.511. These are daily samples, not bounds on the minute series. At the 00:00 UTC session reset, no current-session candle has completed, so eligible is 0 and value_pct is null. Read coverage_ratio as a within-snapshot eligibility share rather than a quality score. The live writer uses a cumulative registry from recorded open interest plus session candles; recomputed core history uses a point-in-time registry. Changes to the registry can change the ratio without changing the eligible count. Compare counts.eligible and counts.candidates together, and do not assume either family has a fixed coverage ratio.

Available history

A start earlier than the first snapshot is accepted. A window ending before that snapshot returns an empty series; a window spanning it returns the available history.

Stream it live

There is no breadth WebSocket channel. Poll /current on a cadence matched to the one-minute write rather than treating it as a tick stream. See WebSocket channels for the families that do stream.

Use it from an agent

Connect through the MCP server, inspect the available tools, and specify core perps or HIP-3 explicitly when asking for breadth above session VWAP. Use the REST routes above when calling the API directly.

Export in bulk

There is no breadth export schema. Use the cursor-paginated history route for retained snapshots.

Next

Use Candles for the per-symbol price series breadth is derived from, Hyperliquid REST for core perps, HIP-3 REST for builder markets, or Data quality before a breadth series feeds alerts.
Last modified on September 8, 2026