> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hypedexer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> Recent updates and improvements to the Hypedexer API

<Update label="2026-10-01" description="5-second and 30-second candles">
  ## Candles: `5s` and `30s` intervals

  * **`candleSnapshot`** (`POST /info`) and the **`candle`** / **`allCandles`** WebSocket channels accept two new intervals, `5s` and `30s`, on top of Hyperliquid's. Same candle shape; `5s` and `30s` WebSocket buckets are final at their `closed` frame (`reconciled: false`).
  * Open and close now follow the exact execution order of trades inside a block, as on Hyperliquid, for candles from 1 October 2026 onwards.
</Update>

<Update label="2026-09-30" description="Order history: trigger metadata of stops and take-profits">
  ## `historicalOrders`: open and triggered states of trigger orders

  * Stops and take-profits now come with their **`open`** and **`triggered`** states next to their final state, as in Hyperliquid's response. These states carry `triggerPx`, `triggerCondition` and the creation `timestamp`, which the final `filled` state of an executed stop resets (`triggerPx: "0.0"`, execution timestamp). A trigger order spans several rows; `limit` counts orders.
  * In window mode, an order is returned when any of its states falls in the window, so a window around a stop's placement now returns its `open` state.
</Update>

<Update label="2026-09-28" description="TWAP membership on fills, complete order history by window, data coverage">
  ## Fills: TWAP parent and builder fee everywhere

  * **`fills`** and **`recentFills`** (`POST /info`, compact shape) now return `twapId` on every row (`null` = ordinary fill), plus `builderFee` and `builder`. Fills of a TWAP carry their parent as soon as they are indexed.
  * **`userTwapSliceFills`** is served from the indexed fills again: it had been reading a table that stopped being fed on 2025-10-11 and returned nothing for recent TWAPs. New optional `twapId` parameter to get the slices of one parent; `startTime` / `endTime` are inclusive bounds on the fill time.

  ## Orders: complete traversal of a time window

  * **`historicalOrders`**: new `startTime` / `endTime` (inclusive, on the status timestamp) and `cursor`. In this window mode the result is sorted by `oid` descending and paged with the `X-Has-More` / `X-Next-Cursor` response headers, so a wallet with more than `limit` orders in the window can be read completely. The status returned is the latest one within the window. Without these parameters the behaviour is unchanged.

  ## Pagination headers on `POST /info`

  * When an indexed type is paginated, the response now carries **`X-Has-More`**, **`X-Next-Cursor`** and, where available, **`X-Total-Count`** headers. The body keeps its shape. Applies to `fills`, `recentFills` and `historicalOrders` in window mode.

  ## Leaderboard across every address

  * **`GET /users/leaderboard`**: new `window=7d|30d|all` mode. The ranking is pre-computed over **every address** that traded in the window and paginated with `page` / `limit` (up to 500 per page, `total_count` and `has_more` in the envelope). New metrics `win_rate`, `pnl_pct` (net PnL / traded volume) and `unrealized_pnl`, next to `volume`, `pnl` and `trades`; each row also carries fills, realized PnL, fees, wins, losses, account value and `refreshed_at`. `7d` and `30d` are refreshed every 5 minutes, `all` every hour. `min_trades` (default 10) keeps one-trade wallets out of the `win_rate` / `pnl_pct` rankings. Without `window` the endpoint behaves as before (live top 100 over the last `hours` hours).

  ## New: `dataCoverage`

  * **`dataCoverage`** (`POST /info`) returns, per dataset, the start of complete coverage and the latest event timestamp present in the region answering, with the delay in seconds: the way to tell an empty answer from a window that is not covered.
</Update>

<Update label="2026-09-26" description="Funding and ledger rebuilt from the node archive, new account WebSocket channels">
  ## Per-user funding, rebuilt

  * **`userFunding`** / **`accountFunding`** (`POST /info`) and **`GET /funding/userFunding`**: every payment now comes from Hyperliquid's official node event archive. `time` is the exact settlement timestamp in milliseconds; `delta` gains `coin`, `fundingRate` and `nSamples` (always `null`); `hash` is the zero hash, as on Hyperliquid. Top-level `coin`, `usdc` and `szi` are unchanged. Coverage starts **2025-09-27 10:00 UTC**; an earlier window returns `[]`. Before this update, payments earlier than 3 September 2026 could carry an inverted sign, a position size taken at the wrong moment, or blank rows.

  ## Native ledger

  * **`userNonFundingLedgerUpdates`** (`POST /info`) now serves the core Hyperliquid ledger in the native `{time, hash, delta}` shape: deposits, withdrawals, sends, spot, internal, sub-account and perp/spot class transfers, vault create/deposit/withdraw/distribution/commission, liquidations, borrow/lend, staking transfers, rewards and gas auctions. One entry per event and per address involved. Coverage starts **2025-09-27 09:29 UTC**. EVM-side transfers stay on `/evm/ledger/*`.

  ## New WebSocket channels

  * **`userFundings`**: snapshot of the 100 most recent payments, then one frame per hourly settlement, about 30 s after the hour.
  * **`userNonFundingLedgerUpdates`**: snapshot of the 100 most recent ledger entries, then new entries within seconds.
  * **`userEvents`** now also carries funding settlements (`{"funding": {...}}`), one frame per payment.
  * **`userFills`**: when the account has no recent live fill, the snapshot is served from storage instead of being empty.
  * **`candle`** / **`allCandles`**: new `30m` interval.

  ## Fills

  * `crossed` is correct on every fill stored since 2026-09-24 15:53 UTC (earlier stored fills read `false`; a historical correction is scheduled).
  * `twapId` is always present in Hyperliquid-shaped fills, `null` outside a TWAP. `cloid` is never `"<nil>"`: omitted, or `null` in the compact shape.
  * `time` is the exact millisecond on every fills endpoint, with a stable ISO 8601 format on repeated queries.
  * Compact `fills` / `recentFills` rows gain `crossed` (0/1) and `cloid`.

  ## Orders

  * **`historicalOrders`**: `lookbackDays` is optional (1–365). Without it, the `limit` most recent orders are returned whatever their age (default 2000, max 5000), as on Hyperliquid. Numbers use Hyperliquid's format (`"93604.0"`); `cloid` and `tif` are always present, `null` when absent.
</Update>

<Update label="2026-09-23" description="Market history and borrow/lend reserve history">
  ## Market history

  * Seven new endpoints under **`/market`**: `coins`, `bbo/{coin}`, `spread/{coin}`, `depth/{coin}`, `slippage/{coin}`, `book/{coin}`, `liquidity-report/{coin}`. Coverage April 2024 to February 2026 from the market data archive, and continuously since 23 September 2026 from the full order book of our own node for the book endpoints. See the Indexed Data REST reference.

  ## Borrow/lend reserve history

  * **`borrowLendReserveHistory`** (`POST /info`): borrow and supply rates, balance, utilisation, oracle price, LTV, total supplied and borrowed per reserve, one sample per minute since 23 September 2026. Filter by `token`, resample with `interval` (`1m` to `1d`, last sample of each bucket), window with `startTime` / `endTime`, up to 10,000 rows.
</Update>

<Update label="2026-09-22" description="Liquidations stream: follow a list of addresses">
  * **`liquidations`** WebSocket: new `users` parameter, up to 50 addresses, matching the liquidated user or a liquidator. Combines with `user`, `amount_dollars` and `builder`.
</Update>

<Update label="2026-09-15" description="Social Trading: batch performance for many wallets">
  ## New endpoint

  * **`POST /users/batch/performance`**: Same stats as `GET /users/{user}/performance` for **up to 500 wallets in one call**: one entry per submitted address, in submission order, computed in a single query (\~300 ms for 500 wallets). `window` = `7d`, `30d`, `90d`, `all`. `include_drawdown: true` adds the realized-PnL `max_drawdown` per wallet (heavier). The equity-based drawdown stays on the per-wallet endpoint. Billed **3 credits per wallet** submitted, the same as one per-wallet call per address (also applies to `POST /builders/{builder_address}/external-activity`). See the [Social Trading guide](/guides/social-trading).
</Update>

<Update label="2026-09-14" description="Live candles: explicit final frame, reconciled against stored trades">
  ## WebSocket `candle` / `allCandles`: final frame per bucket

  * Every bucket now ends with one explicit final update carrying **`closed: true`**, sent \~2 s after `T`, whose `o/h/l/c/v/n` are **recomputed from the stored trades** (`reconciled: true`). A bucket is final when you receive that frame: see [candle](/live-data/ws-candle) and [allCandles](/live-data/ws-all-candles).
  * Late or out-of-order trades are now applied to their own bucket instead of resetting the current one, and a batch of trades spanning two buckets emits an update for both. This fixes closed bars that could end short of the true trade count without any signal.
  * `reconciled: false` on a final frame means storage was temporarily unavailable and the frame reflects the live state only; a later `closed` frame for the same `t` supersedes it.
</Update>

<Update label="2026-09-08" description="Builders: detect users trading outside your app">
  ## Builders: external activity

  * **`POST /builders/{builder_address}/external-activity`**, Send your builder address and up to 500 wallet addresses; for each wallet you get the fills attributed to **other builder codes** (`externalBuilders[]`, with fill count, notional, coins, first and last fill) and, unless `includeNoBuilder=false`, the fills carrying **no builder code** at all (`noBuilder`), the official Hyperliquid UI, bots, any tool outside the builder program. `own` reports the wallet's activity under your code for context, and `flagged` users come first, sorted by external volume. `summary` counts the wallets in each situation. `timeframe` = `1h`, `24h`, `7d` (default), `30d`. Builder attribution starts **2025-10-10**. See the [Builders reference](/builders/index).
</Update>

<Update label="2026-09-07" description="Social Trading: equity curve, PnL calendar, account leverage and top trades">
  ## Social Trading endpoints

  Five endpoints covering a full trader profile for **any Hyperliquid address**: see the [Social Trading guide](/guides/social-trading). Equity, positions and leverage are derived from the on-chain clearinghouse state, read hourly from our own full nodes; `account_value` matches Hyperliquid's `clearinghouseState.marginSummary.accountValue` exactly.

  ### New endpoints

  * **`GET /users/{user}/equity-history`**: Account value over time, one point per hourly snapshot (`interval=1h`) or per day (`interval=1d`). Each point carries `account_value`, `cash`, `position_value`, `unrealized_pnl`, `account_leverage` and `n_positions`; `summary` adds the change over the window and its max drawdown. `window` = `7d` (default), `30d`, `90d`, `all`.
  * **`GET /users/{user}/pnl-calendar`**: One row per trading day: `realized_pnl` (from fills), `fees`, `funding`, `net_pnl = realized − fees + funding`, `cumulative_net_pnl`, `fills`, `volume` and `equity_close`. `totals` counts profitable and losing days. Funding follows the Hyperliquid sign convention (positive = received). `window` = `7d`, `30d` (default), `90d`, `all`.
  * **`GET /users/{user}/account`**: Latest known state: `account_value`, `cash`, `position_value`, `unrealized_pnl`, `account_leverage` (open notional ÷ account value) and every open position with `leverage`, `leverage_type`, `entry_px`, `mark_px`, `unrealized_pnl`, `roe` and accrued funding. `as_of` is the snapshot time.
  * **`GET /users/{user}/top-trades`**: Best round-trip trades with `coin`, `direction`, `leverage`, `pnl`, `notional`, entry/exit price and `closed_at`. Open positions are ranked alongside by unrealized PnL (`status: "open"`, no `closed_at`) unless `include_open=false`. `sort` = `pnl` (default), `pnl_abs`, `notional`, `loss`; `limit` 1–50 (default 5).

  ### Updated endpoint

  * **`GET /users/{user}/performance`**: New `window` parameter (`7d` default, `30d`, `90d`, `all`); `start_time` / `end_time` still take precedence when supplied. Response gains `volume`, `longs` / `shorts` / `long_short_ratio` / `long_pct`, `total_fees`, `total_funding`, `best_trade_pnl` / `worst_trade_pnl`, and a second drawdown measured on real account value (`equity_max_drawdown_usd`, `equity_max_drawdown_pct`, `equity_snapshots`) alongside the existing `max_drawdown` on the realized-PnL curve. Existing fields are unchanged. An invalid address now returns `400` instead of `500`.

  ### Coverage

  * Round-trip trades (`/performance`, `/top-trades`): from **2025-09-10**.
  * Account snapshots (`/equity-history`, `/account`, `equity_close`, per-trade leverage): from **2026-09-05**, hourly, accumulating from there. Leverage on trades closed before **2026-09-06** is `null`.
  * `account_value` covers the **perp** account only: spot balances and HIP-3 builder-dex positions are not included yet. A trader with no position and no perp balance returns `account_value: 0` with `perp_account_empty: true`, which is a real zero rather than missing data.
</Update>

<Update label="2026-08-29" description="HIP-4 permissionless support & order type on fills">
  ## HIP-4 permissionless support

  Shipped alongside the Hyperliquid permissionless-HIP4 network upgrade (2026-08-29). HIP-4 prediction markets can now be deployed by third-party **providers**, a deployer address operating a named **venue**, not only by the Hyperliquid oracle. The API attributes every market, question and fill to its provider. Markets with no on-chain venue (pre-upgrade markets, and markets still emitted by the HL oracle pipeline) are reported under the reserved provider name **`oracle`** so aggregates are complete, see [Permissionless providers and the oracle convention](/hip-4/overview#permissionless-providers-and-the-oracle-convention).

  ### New endpoints

  * **`GET /hip4/providers`**: Per-provider trading statistics aggregated from fills (`markets_traded`, `fills`, `volume_usdc`, `unique_users`, `fees`, `last_trade`), sorted by `volume_usdc` descending. Filters: `venue` (a venue name, or `oracle`), `start` / `end` (ISO datetime, inclusive), `limit` / `offset`. Settlement rows are excluded from all aggregates; a new permissionless venue appears automatically after its first fill.
  * **`GET /hip4/deployers`**: The permissionless deployer registry, refreshed from chain metadata every \~10 s: `deployer`, `venue`, `fee_scale`, `sub_deployers` (a JSON string to parse: `[action, [addresses]]` pairs of delegated permissions per venue), `updated_at`.

  ### Updated endpoints

  * **`GET /hip4/markets`** (alias `/hip4/outcomes`): Three new fields on every market row: `venue` (`""` for oracle-emitted markets), `deployer` (`""` when `venue` is empty), `deployer_fee_scale` (`0` when not applicable). Everything else unchanged.
  * **`GET /hip4/fills`**: Two new fields on every fill row: `venue` and `deployer`, joined from the market of the fill's outcome. The existing `market_name` / `market_description` fields are unchanged.
  * **`GET /hip4/questions`**: Two new fields on every question row: `venue` and `deployer`, derived from the question's outcomes (resolved via the fallback outcome's market). Legacy questions report `venue="oracle"`, `deployer=""`.

  ## Order type on fills (2026-08-28)

  New opt-in query parameter **`include_order_type`** (boolean, default `false`) on **`GET /fills/`**, **`GET /fills/recent`** and **`GET /fills/user/{user_address}`**. When `true`, each fill row gains one field:

  * **`orderType`** (string or null): the originating order's type, resolved server-side from the order status by (user, oid). Observed values include `Limit`, `Market`, `Stop Market`, `Take Profit Limit` (an open set, not an enum).
  * With the default `false`, the response is byte-identical to before, the key is absent, not null, so existing integrations are unaffected.
  * `orderType` is `null` when the originating order status is unknown: orders placed before 2026-06-27 (start of order-status coverage), plus a small share of gaps in that dataset.
  * Cost: roughly tens of milliseconds per page of 1000 fills.
</Update>

<Update label="2026-04-25" description="HIP-3 upgrade support">
  The indexer now tracks two new L1 actions tied to the HIP-3 upgrade:

  * **`agentSendAsset`**: agent transfers between dexes for the same user.
  * **`hip3LiquidatorTransfer`**: deposit/withdraw of principal on the backstop of a HIP-3 dex.

  ### New endpoints

  All grouped under **`/evm/hip3/backstop/*`**. The backstop address for a dex is `0x4000…00 + dex_index`.

  **Principal flows**: built from local `hip3LiquidatorTransfer` rows:

  * **`GET /evm/hip3/backstop/transfers`**: Filterable list of backstop principal transfers (filters: `dex`, `signer`, `is_deposit`, time range).
  * **`GET /evm/hip3/backstop/transfers-summary`**: Per-dex aggregate: `total_deposited_usdc`, `total_withdrawn_usdc`, `net_principal_usdc`, `unique_signers`.

  **On-chain activity**: combine principal flows with fills observed at the backstop address:

  * **`GET /evm/hip3/backstop/health`**: Health overview of every observed HIP-3 backstop. Returns one row per dex (combined principal + fill counters, last/first fill, fees paid, active coins).
  * **`GET /evm/hip3/backstop/{dex}/health`**: Same payload for a single dex. Returns `404` if no backstop activity has ever been observed for that dex.
  * **`GET /evm/hip3/backstop/{dex}/fills`**: Paginated stream of raw fills absorbed by the backstop. Filters: `coin`, `side`, time range.

  ### Updated endpoints

  * **`GET /evm/ledger/transfers`**: Response extended with `source_dex` and `destination_dex` (populated for `agentSendAsset`). `action_type=agentSendAsset` is now a supported filter value.
  * **`GET /evm/user/{address}/ledger-events`**: New `agent_send` event type, exposing `source_dex` and `destination_dex`.
</Update>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.