Hyperliquid Oracle Prices and the Builder Auction: Reading Market State

Direct Answer: How to Read Hyperliquid's Market State

If you need an audit-ready price on Hyperliquid, do not improvise from the top of an order book. The canonical reference is the oracle (mark) price that the validator set computes and commits on-chain with each block. You read it through the info API (for example metaAndAssetCtxs or allMids), and each response includes a timestamp that tells you when that oracle was computed. Separately, the builder/data-availability auction (HIP-3/4) determines who gets to propose blocks and how priority fees are distributed; you can observe current auction state through the exchange/auction info endpoint. This guide walks through the mechanism and gives you runnable commands to verify what you are seeing.

The key practical rule: always compare the oracle timestamp in the API response against your own system clock before using the price for funding, liquidation, or any financial decision. If the timestamp is older than a few seconds (the documented cadence is near a block time, but exact values vary), treat the price as stale and re-poll. The same discipline applies to auction data, which updates only when a new round starts.

How Hyperliquid Produces Oracle Prices

Hyperliquid runs its own L1: a delegated proof-of-stake chain with 24 validators, a non-EVM Rust binary, and a block time that the protocol targets but which can vary with validator latency. The validator set is responsible for maintaining the canonical market data, including the oracle price for every asset. According to the Hyperliquid docs on oracle prices, the oracle price is an on-chain median of multiple exchange prices, computed by the validators. It is updated with each network block, and that update is what you see in the info API.

The oracle price serves as the mark price for funding payments and liquidations. It is deliberately not the top-of-book price, because the top of a single order book can be manipulated or thin. By using a median across exchanges, Hyperliquid makes the reference price more robust. When you call metaAndAssetCtxs, the markPx field in each asset context is that oracle price, and the oraclePx field (when present) is the raw oracle before any funding adjustment. The time field in the response is the Unix timestamp (in milliseconds) of the block in which that oracle was computed.

For a deeper look at the mechanics, the Hyperliquid docs on the Info endpoint list all the request types. The metaAndAssetCtxs request returns both the asset metadata and the current context (including mark price, oracle price, funding, and open interest) for all assets. The allMids request is a lighter-weight variant that returns only the mid price (which is derived from the order book, not the oracle) and is often used for quick polling. Do not confuse allMids with the oracle price: allMids is the mid of the L2 book, while metaAndAssetCtxs gives you the oracle.

The Builder and Data-Availability Auction (HIP-3/4)

Hyperliquid's block production is not free-for-all. In the base protocol, validators produce blocks in a deterministic order, but an auction determines who gets to submit the next block's transactions. This is the builder auction: block producers (builders) bid to win the right to propose a block, and the winning bid is paid in priority fees that users attach to their transactions. The Hyperliquid docs on exchange/auction describe the current auction format and the fields returned by the exchange/auction info endpoint.

HIP-3 (builder-deployed perpetuals) extends this idea: it allows builders to deploy their own perpetual markets, and those markets can have private auctions where only the deploying builder can submit blocks for that market. This is documented in the HIP-3 proposal. HIP-4 (perps to predictions) is a broader proposal that includes a data-availability auction for payload data, but as of this writing it is a proposal, not a live mechanism. The docs describe it as a design for how data availability is priced and auctioned, but you should verify the current status at read time.

For a reader, the important thing is that the auction state is observable. The exchange/auction info endpoint returns the current auction round, the asset (or 'HL' for the main chain), the bid, and the time the auction ends. You can poll this to see who is winning and when the next round starts. However, note that the auction feed is only available through certain subscriptions—the WebSocket auction subscription gives you real-time updates, while the REST info endpoint gives you a snapshot. See the Hyperliquid WebSocket subscriptions guide for details on which subscriptions exist.

Which Info Endpoint Should You Poll?

Different use cases call for different data sources. The table below summarizes the decision.

For a price that is safe to use in financial logic, always prefer metaAndAssetCtxs over allMids or l2Book. The latter two reflect only the local order book, which can be stale or manipulated. The oracle price is the one that the protocol itself uses for liquidations and funding, so it is the most defensible reference.

Runnable Example: Reading Oracle Price and Auction State

Expected output (abbreviated) for metaAndAssetCtxs looks like this:

The time field is in milliseconds. Compare it to your system time (also in ms) to compute staleness. The exchange/auction response is a list of auction objects, each with fields like type, asset, bid, time, and endTime (again in ms).

# Fetch metaAndAssetCtxs (oracle prices)
curl -s https://api.hyperliquid.xyz/info -X POST -H 'Content-Type: application/json' \
  -d '{"type":"metaAndAssetCtxs"}'

# Fetch exchange/auction (current auction)
curl -s https://api.hyperliquid.xyz/info -X POST -H 'Content-Type: application/json' \
  -d '{"type":"exchange/auction"}'

# Fetch allMids (mid prices, not oracle)
curl -s https://api.hyperliquid.xyz/info -X POST -H 'Content-Type: application/json' \
  -d '{"type":"allMids"}'

# Expected output (abbreviated)
{
  "meta": { ... },
  "assetCtxs": [
    {
      "dayNtlVlm": "123456789.0",
      "funding": "0.00001234",
      "markPx": "65432.1",
      "midPx": "65430.0",
      "openInterest": "1234.5",
      "oraclePx": "65431.0",
      "premium": "0.00002",
      "time": 1720000000000
    }
  ]
}

Fill-in Results Table: Oracle Timestamp vs System Time

To verify that you are not acting on a stale price, run the curl command above and fill in the table below. Use a tool like date +%s%3N on Linux or Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff' on Windows to get your system time in ms.

If the delta is consistently above a few seconds, the API endpoint you are using may be behind, or the network itself may be experiencing latency. The Hyperliquid docs state that the oracle updates with each block, but the exact block time is not fixed; it depends on validator performance. For a production system, set a threshold that matches your risk tolerance (e.g., 5 seconds) and re-poll if exceeded.

Troubleshooting and Verification Checklist

When reading Hyperliquid market state, you may hit several common pitfalls. Use this checklist to diagnose them.

• Timestamp units: The time field in info responses is in milliseconds. If you compare it to a Unix timestamp in seconds, you will think the price is 1000x older than it is. Always convert to the same unit.
• Wrong interval lookup key: When querying candles, the interval field must be one of the documented values (e.g., 1m, 5m, 15m, 1h, 4h, 1d). Using an unsupported value returns an error or empty data.
• Conflating mark vs index vs last price: markPx is the oracle price used for funding/liquidations. oraclePx is the raw oracle before any funding adjustment. midPx is the mid of the order book. last (in trades) is the last traded price. Do not use midPx when you need the oracle.
• Auction feed visibility: The exchange/auction REST endpoint returns the current auction, but real-time updates require the WebSocket auction subscription. If you are not receiving updates, check that you subscribed correctly.
• Cadence variation: The oracle update cadence is tied to block production, which can vary with validator latency. The docs describe a target block time, but do not guarantee a fixed interval. Always verify the current cadence from the docs at read time.
• Rate limits: The info API has rate limits. If you poll too frequently, you may get 429 responses. See the Hyperliquid RPC rate limits guide for details.

Limitations and Tradeoffs

The mechanisms described here are documented protocol ideas, but the exact parameters (block time, auction duration, fee splits) are subject to change and may vary by network conditions. The Hyperliquid docs are the authoritative source; always check them at read time for the latest values. For example, the Hyperliquid docs on exchange/auction specify the auction fields, but the duration of each round is not hard-coded in the docs—it is determined by the protocol's internal logic.

Additionally, the builder/data-availability auction is an evolving area. HIP-3 and HIP-4 are proposals that may be implemented differently than described here. As of this writing, HIP-3 is live for builder-deployed markets, but HIP-4 is still a proposal. Do not assume that all features described in HIP-4 are active on mainnet.

Finally, the info API gives you a snapshot of the state at a particular block. If you need a historical record, you must use the candles or trades endpoints, which have their own limitations (e.g., they may not include every oracle update). For a complete audit trail, consider running your own indexer or using a data service.

Next Steps and Further Reading

Now that you understand how to read Hyperliquid's oracle prices and auction state, you can build more reliable trading or monitoring tools. To go deeper, explore the following resources:

• Hyperliquid network overview – understand the chain architecture and endpoints.
• Hyperliquid RPC endpoints (RPC Assistant) – find the right endpoint for your use case.
• Reading Hyperliquid historical market data – learn how to fetch candles and trades for backtesting.
• Handling Hyperliquid order rejections and API errors – troubleshoot common API issues.
• Hyperliquid WebSocket subscriptions – get real-time updates for prices and auctions.
• Hyperliquid RPC latency and performance – measure and optimize your connection.
• OnFinality Learn hub – more guides on network protocols.
• RPC pricing – see how OnFinality can provide reliable RPC access.
• API service – learn about OnFinality's managed API services.