# How the hourly Hyperliquid funding rate is calculated > Hyperliquid computes an 8-hour-equivalent rate from an impact-price premium and fixed interest term, then settles one eighth every hour. The payment uses oracle-price notional, while current, predicted, historical, and realized values come from separate Info API queries. - Source: https://papaproxy.net/blog/hyperliquid-funding-rate.php - Published: 2026-08-07 - Author: Alex Young - Category: API & data · PapaProxy.net Blog --- ## Key takeaways - Hyperliquid defines an 8-hour-equivalent formula but settles one eighth every hour; positive rates debit longs and credit shorts, while negative rates reverse the direction. - The premium uses impact bid/ask execution prices versus the oracle, sampled every five seconds and averaged over the hour; it is not simply the mark-to-oracle difference. - The fixed interest term is `0.01%` per 8 hours, the clamp is ±`0.05%`, and funding is separately capped at `4%` per hour. - Funding cash flow uses position size × oracle price × the hourly rate, so leverage changes the effect relative to margin rather than multiplying the notional charge. - Use `metaAndAssetCtxs` for current rates, `predictedFundings` for next cross-venue estimates, `fundingHistory` for market history, and `userFunding` for realized wallet debits and credits. ## 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: TextCopy code ```text 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: TextCopy code ```text 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: TextCopy code ```text 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%`: TextCopy code ```text 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: TextCopy code ```text 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. | What you need | Request type | Fields to read | | --- | --- | --- | | Current rate for perpetuals | `metaAndAssetCtxs` | `funding`, `premium`, `oraclePx`, `markPx`, `impactPxs`, `openInterest` | | Predicted next rates across venues | `predictedFundings` | coin → venue → `fundingRate`, `nextFundingTime` | | Historical rate series | `fundingHistory` | `coin`, `fundingRate`, `premium`, `time` | | Funding actually applied to a wallet | `userFunding` | `delta.fundingRate`, `delta.szi`, `delta.usdc`, `time` | The **predictedFundings response format** is a nested list rather than an object keyed directly by market: JSONCopy code ```json [ [ "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: PythonCopy code ```python 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: JSONCopy code ```json { "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: TextCopy code ```text 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](/crypto-proxy.php) can provide stable proxy addresses for that network layer. They do not change Hyperliquid's formula, account state, or venue-level trading constraints.