Hyperliquid funding rates for RPC and index consumers

A live Hyperliquid funding estimate is not the payment your wallet received. Use it as settled history, and your profit-and-loss report can disagree with the exchange even when every request succeeds.

A reliable feed separates current estimates, settled rates, and account payments. This guide covers the Info API requests for each, polling budgets, and reconciliation with fills. For the funding formula and introductory Python examples, use the funding rates guide.

Separate estimates from settlement records

Hyperliquid settles funding hourly, but the inputs change within the hour. It samples the premium every 5 seconds and averages those samples. The settlement calculation uses the oracle price. See the funding specification.

Choose a data source by the question you need to answer:

Do not overwrite settled history with a live estimate sampled near the hour boundary. Fetch the completed settlement record instead.

Fetch each perpetual market's context

metaAndAssetCtxs returns metadata and asset contexts in matching order. Join each universe entry to the context at the same index. Preserve the market identifier alongside funding, markPx, and oraclePx.

The default request covers the native perpetual DEX. For HIP-3 markets, enumerate perpDexs and query each required DEX with its dex parameter. See the perpetuals Info reference.

Keep DEX-qualified market names in storage. Short display symbols alone can collide across markets.

Store rates in their native units with a field identifying the interval. Avoid binary floating-point rounding in accounting calculations. Annualized display values belong in separate fields and must not replace the source rate.

predictedFundings covers only Hyperliquid's first, native perpetual DEX. It does not provide predictions for HIP-3 markets.

For predictedFundings, retain fundingIntervalHours and nextFundingTime. Normalize intervals before comparing venues; equal numeric rates can describe different payment periods.

The tested public API returned an HlPerp prediction whose nextFundingTime had already passed. Treat an elapsed prediction timestamp as expired, even when the request succeeds.

Budget polling by request weight

The public Info API uses a shared per-IP REST budget of 1,200 weight per minute. Most documented Info requests have base weight 20. History methods can add weight based on returned rows. Check the rate-limit reference before sizing a feed.

For example, polling a base-weight-20 request every 30 seconds consumes 40 weight per minute. Polling it every second consumes the full 1,200 budget before any other requests. Multiply by the DEX count and include other services sharing the same IP.

These intervals are starting points for a dashboard, not exchange requirements:

A live risk system may need faster data than this dashboard example. Measure its freshness requirement separately. Hourly settlement does not mean the current estimate changes only once an hour.

Scale account monitoring with Dwellir portfolio batches

Fetch metaAndAssetCtxs, predictedFundings, fundingHistory, and userFunding from https://api.hyperliquid.xyz/info. Pair those funding records with current account data from Dwellir.

A dashboard that tracks many accounts needs perpetual positions, spot balances, and account mode alongside funding payments. Dwellir's portfolio methods combine those reads. Your application sends the account list and receives results keyed by wallet, while Dwellir handles the underlying requests.

For example, fetching each of the three account components separately for 100 accounts requires 300 HTTP requests. With batchPortfolioState and batches of 10 accounts, your worker sends 10 requests per refresh. This is a request-count example, not a latency benchmark. Choose the narrower batch methods when you only need perpetual or spot state.

This request loads combined account data for two wallets:

curl -sS 'https://api-hyperliquid-mainnet-info.n.dwellir.com/YOUR_API_KEY/info' \
  -H 'content-type: application/json' \
  -d '{
    "type": "batchPortfolioState",
    "users": [
      "0x63E8c7C149556D5f34F833419A287bb9Ef81487f",
      "0xdfc24b077bc1425ad1dea75bcb6f8158e10df303"
    ]
  }'

Each entry in successful_states is an [address, portfolio] pair. The portfolio contains clearinghouseState, spotClearinghouseState, and userAbstraction. Store results by returned address. Retry accounts listed in failed_wallets with bounded backoff, and retain their last successful snapshot with its observation time.

Omit dex for the native perpetual DEX. For HIP-3, pass a DEX name from perpDexs, or use dex: "ALL_DEXES" with portfolio and perpetual-state methods. The all-DEX portfolio response groups perpetual state by DEX under clearinghouseState, including native. Spot balances and account mode remain at the top level. Check that the returned DEX keys cover the markets you monitor. Spot-only batches have no dex parameter.

Batching reduces the HTTP requests your application coordinates. A native-DEX batchPortfolioState query uses 3 API credits per account. Its ALL_DEXES mode also charges for DEX discovery and additional DEX responses. See portfolio batch billing when sizing the refresh cadence.

Refresh account snapshots separately from hourly funding-history ingestion. Join both by account and market, and use historical fills to track intervening position changes. Current positions cannot establish a position's size at an earlier settlement. Keep request budgets separate for Dwellir and the public endpoint.

Persist history without skipping page boundaries

Use fundingHistory for settled market rates and userFunding for wallet payments. Time-range endpoints paginate, so a successful response does not necessarily cover the full requested period. Follow the Info API pagination rules.

Persist the returned timestamp and full market identifier. Resume from the last returned timestamp as documented, deduplicate the overlap, and detect pages that make no progress.

Choose keys from the actual response schema. A market-history key can combine DEX, coin, and settlement time. For account events, retain the account, returned event fields, and hash where present. userFunding events can carry a zero hash, so a hash alone cannot identify a payment. Verify uniqueness against real responses before relying on a database constraint.

Keep request time and source event time separate. A response received now can contain old data.

Reconcile funding with fills

Use wallet funding events as the record of what the venue paid or charged. Fills explain position changes, but fills alone do not contain funding payments.

For a reconstruction, establish the position immediately before each settlement. Then apply the settled rate and settlement oracle price. With long size positive, a positive size × oracle × rate is a payment out of the account. It reduces profit and loss.

Do not substitute mark-price candles for the settlement oracle. A live context captured later is also insufficient for an exact historical reconstruction. If you lack the settlement inputs, label the result as an estimate.

Join fills using the complete market identifier and consistent millisecond timestamps. Keep fees and liquidation effects separate from funding. The Hyperliquid Index fills reference describes the fill data available through Dwellir.

Detect stale data without flagging valid rates

A zero or unchanged rate can be valid. Alert on missing expected settlement records, failed requests, or observations older than your freshness limit. Do not treat a constant rate as evidence that the feed stopped.

Monitor the latest completed settlement per market. Compare account funding coverage with the reconciliation window, and retry missing periods before closing that window.

For live contexts without a source timestamp, record when you fetched them and describe that limitation. A successful request establishes observation time, not proof of the upstream data's age.

Start with one native market and one HIP-3 market, if your product uses both. Verify pagination, replay deduplication, and wallet reconciliation before expanding coverage.

Connect your account monitor to Dwellir's portfolio batches to refresh positions, spot balances, and account mode together. Add historical fills from Hyperliquid Index when you need to reconstruct position changes alongside funding payments.