Skip to main content
​
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.

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