How the hourly Hyperliquid funding rate is calculated

Why payments land every hour

Hyperliquid uses two time scales at once. The formula is defined as an 8-hour rate for consistency with centralized perpetual markets, but the protocol settles one eighth of the computed value every hour.

That distinction is the funding interval you need to keep straight in code. An 8-hour-equivalent rate of 0.01% corresponds to 0.00125% for one hourly settlement. These hourly funding payments are added to or subtracted from the account balance automatically; Hyperliquid describes funding as a peer-to-peer transfer and does not collect a fee from it.

The sign determines who pays. A positive rate means longs pay shorts; a negative rate means shorts pay longs. The payment frequency changes when the cash flow reaches the account, not which side owes it.

Funding is charged against position notional, not the collateral you posted. Hyperliquid documents the payment as:

payment = position_size × oracle_price × hourly_funding_rate

So leverage changes how large the payment feels relative to your margin, but it does not multiply the rate applied to the position itself. Hyperliquid also uses the oracle price, not the mark price, to convert position size into notional.

The funding rate formula uses impact prices, not the mark price

The funding rate formula is:

F = P + clamp(I - P, -0.0005, 0.0005)

I is the fixed 8-hour interest term: 0.0001, or 0.01%. P is the average premium. The important detail is how that premium is obtained: Hyperliquid does not simply subtract the oracle price from the mark price.

The premium index starts from impact execution prices:

impact_price_difference =
    max(impact_bid_px - oracle_px, 0)
  - max(oracle_px - impact_ask_px, 0)

premium = impact_price_difference / oracle_price

impact_bid_px and impact_ask_px are the average execution prices for a defined impact notional. Current contract specifications set that notional to 20,000 USDC for BTC and ETH and 6,000 USDC for other standard perpetuals. Premium samples are taken every five seconds and averaged over the hour.

That changes the funding rate calculation in an important way. A thin order book can create a meaningful impact premium even when the displayed mark price is close to the oracle. Conversely, a brief dislocation contributes only part of the hourly average rather than becoming the whole input.

The clamp creates a useful flat region around the fixed interest term. If the average premium P stays between -0.0004 and +0.0006 — from -0.04% to +0.06% — the clamp offsets it completely and the 8-hour-equivalent result remains 0.01%.

Suppose the average premium is +0.08%:

P = 0.0008
I = 0.0001
I - P = -0.0007
clamp(I - P) = -0.0005

F = 0.0008 - 0.0005
  = 0.0003
  = 0.03% per 8-hour equivalent

hourly settlement = 0.03% / 8
                  = 0.00375%

On 100,000 USDC of oracle-price notional, that works out to 3.75 USDC for that hourly settlement if the computed rate remains at that value. This is a mechanical example, not a forecast.

Hyperliquid separately caps funding at 4% per hour. The documentation states that the cap and hourly settlement interval do not depend on the asset.

What the interest rate component actually adds

The interest rate component is fixed at 0.01% per 8 hours, or 0.00125% per hour before the premium moves the combined rate away from that baseline. Hyperliquid describes it as representing the borrowing-cost difference between USD and the spot crypto asset.

Inside the clamp region, the premium disappears from the final result:

P + (I - P) = I

Once the average premium moves outside that range, only 0.05% of the difference can be offset by the clamp. The remainder passes through into the computed rate.

With a positive rate, this is funding paid to shorts by longs. With a negative rate, the direction reverses. That sign is more useful than simply looking at whether the fixed interest term is positive, because a persistent perp discount can push the whole result below zero.

Reading rates through the Info API

There is no single funding rate endpoint that answers every funding question. Hyperliquid separates current market state, predicted rates, historical rates, and realized wallet payments into different POST https://api.hyperliquid.xyz/info request types.

The predictedFundings response format is a nested list rather than an object keyed directly by market:

[
  [
    "AVAX",
    [
      [
        "BinPerp",
        {
          "fundingRate": "0.0001",
          "nextFundingTime": 1733961600000
        }
      ],
      [
        "HlPerp",
        {
          "fundingRate": "0.0000125",
          "nextFundingTime": 1733958000000
        }
      ],
      [
        "BybitPerp",
        {
          "fundingRate": "0.0001",
          "nextFundingTime": 1733961600000
        }
      ]
    ]
  ]
]

Do not compare those venue numbers blindly. Different venues can settle on different schedules, so normalize the rates to the same hourly or 8-hour period before calculating a spread.

The funding history endpoint requires coin and startTime in milliseconds. endTime is optional and inclusive. Hyperliquid's general Info API pagination rule limits time-range responses to 500 elements, so a long backfill should advance from the last returned timestamp instead of assuming that one call covers the requested range.

There is also a current HIP-3 boundary worth handling explicitly. metaAndAssetCtxs can query a specific perp DEX, and historical data is available for builder-deployed markets using their DEX-qualified coin names. predictedFundings, however, is currently documented only for the first perp DEX.

Here is a minimal Python reader that keeps current, predicted, and historical data separate:

import time
import requests

INFO = "https://api.hyperliquid.xyz/info"
session = requests.Session()


def post(payload):
    r = session.post(INFO, json=payload, timeout=10)
    r.raise_for_status()
    return r.json()


def current_funding():
    meta, contexts = post({"type": "metaAndAssetCtxs"})
    names = [asset["name"] for asset in meta["universe"]]

    return {
        coin: {
            "funding": ctx["funding"],
            "premium": ctx.get("premium"),
            "oraclePx": ctx.get("oraclePx"),
            "markPx": ctx.get("markPx"),
        }
        for coin, ctx in zip(names, contexts)
    }


def predicted_funding():
    rows = post({"type": "predictedFundings"})

    return {
        coin: {
            venue: details
            for venue, details in venues
            if details is not None
        }
        for coin, venues in rows
    }


def funding_history(coin, start_ms, end_ms=None):
    payload = {
        "type": "fundingHistory",
        "coin": coin,
        "startTime": start_ms,
    }

    if end_ms is not None:
        payload["endTime"] = end_ms

    return post(payload)


now_ms = int(time.time() * 1000)

print(current_funding()["BTC"])
print(predicted_funding().get("BTC", {}))
print(
    funding_history(
        "BTC",
        now_ms - 24 * 60 * 60 * 1000,
    )[:3]
)

Use metaAndAssetCtxs for a live dashboard, predictedFundings when you need the next cross-venue estimates, and fundingHistory for charts or research. The snippet deliberately does not paginate history, normalize other venues' schedules, persist results, or retry failures; those belong in a collector rather than this minimal reader.

These reads also consume the public REST budget. Hyperliquid currently gives most documented Info requests weight 20 under the shared 1,200-weight-per-minute IP limit. fundingHistory and userFunding additionally consume one weight for every 20 returned items, which matters when you backfill many markets or accounts.

Settlement on chain and the sign of realized funding

Hyperliquid records funding payments on-chain in HyperCore state rather than charging them as a separate exchange fee. The official funding documentation describes funding as purely peer-to-peer, while the Info API exposes the realized entries for an address through userFunding.

A funding event has this shape:

{
  "delta": {
    "type": "funding",
    "coin": "ETH",
    "usdc": "-3.625312",
    "szi": "49.1477",
    "fundingRate": "0.0000417"
  },
  "time": 1681222254710,
  "hash": "0x..."
}

For account bookkeeping, delta.usdc is the field to reconcile. A negative value is a debit from that account; a positive value is a credit. Keep the recorded event instead of reconstructing past cash flows from today's current or predicted rate.

The settlement does not require a separate action from the trader. It changes account balance as HyperCore state is updated. That also means funding can affect risk: Hyperliquid's liquidation documentation explicitly notes that funding payments can move the liquidation price of an open position.

A complete funding rate explanation therefore has to separate three things: the formula that computes the rate, the hourly market rate that applies to positions, and the realized USDC entry that was actually posted to an account.

What funding arbitrage has to normalize

A large positive number on one venue and a smaller number on another is not yet an arbitrage opportunity. First put both rates on the same time basis, then compare the funding windows that are actually expected to settle.

For example, comparing a one-hour Hyperliquid number directly with an eight-hour venue number can exaggerate or reverse the apparent spread. nextFundingTime is useful here because it tells you when the particular venue entry is expected to settle; the other venue's current documentation still determines the interval you should use for normalization.

Execution costs come next. A cross-venue position needs an entry and exit on both legs, so maker/taker fees, spread and slippage can exceed several attractive-looking funding periods. The predicted rate can also move before settlement, and the spread can reverse while the trade is open.

For monitoring code, keep these concepts separate:

current rate     → what is accruing now
predicted rate   → what may settle next
historical rate  → what settled for the market
user funding     → what was actually booked to this wallet

Mixing those fields is one of the easiest ways to produce a funding-arbitrage backtest that cannot be reproduced in live trading.

For a single funding dashboard, the first fixes are software: cache market metadata, page historical data correctly, and avoid polling information you already have. If the remaining workload is a set of genuinely independent collectors that needs fixed, reproducible egress and isolated per-IP request budgets, crypto proxies can provide stable proxy addresses for that network layer. They do not change Hyperliquid's formula, account state, or venue-level trading constraints.