Hyperliquid Funding Rate History: How to Get It and What It Actually Measures

Hyperliquid settles funding every hour, on every perp, against roughly $18 billion of open interest at its September 2026 peak (The Block via KuCoin). That is 8,760 settlements per market per year, each one moving real USDC between longs and shorts. For anyone researching carry, basis, or positioning signals, Hyperliquid funding rate history is the most information-dense table the venue produces. It is also the one most often misread.

The misreading is rarely a data problem. The rate itself is public, hourly, and reproducible. The problem is that the number encodes three things at once: a fixed interest charge, a clamp that changes behavior depending on how large the premium is, and a settlement convention that uses the spot oracle rather than the mark price. A backtest that treats the funding column as a clean measure of "market crowdedness" will find patterns that are actually artifacts of the formula.

This guide is for the quant or data engineer who needs to answer three questions before trusting a funding series: how the rate is computed, where a complete history actually comes from, and which parts of the signal are mechanics rather than alpha. It builds on our earlier posts on where Hyperliquid historical data comes from and every table in the Hyperliquid dataset, and goes deep on one table and one research use.

By the end you will have the formula with its edge cases, a comparison of the four ways to obtain history, a list of mechanics that masquerade as signal, a step-by-step carry backtest, and a validation checklist you can run before any funding number touches a model.

#How Hyperliquid Funding Actually Works

The published formula is short, but every term in it has a consequence for how the history should be read. From the official funding docs:

F = P + \operatorname{clamp}(r - P,\; -0.0005,\; 0.0005)

where F is the funding rate, P is the average premium index over the hour, and r is the interest rate. Five details matter more than the formula itself.

#The rate is computed on an 8-hour basis and paid at one-eighth per hour

The formula produces an 8-hour rate for compatibility with centralized exchanges. Hyperliquid then pays one-eighth of it every hour. The interest component r is fixed at 0.01% per 8 hours, which is 0.00125% per hour, or about 11.6% annualized paid to the short side. This is the first trap: the value the API returns in fundingRate is already the hourly settled rate. Dividing it by 8 again, or annualizing it as if it were an 8-hour number, produces figures that are off by a factor of eight.

#The premium is sampled every 5 seconds and averaged

The premium is not a single end-of-hour observation. Hyperliquid samples it every 5 seconds and averages roughly 720 observations into one hourly value. A short, violent spike inside the hour contributes 1/720th of its magnitude to the settled rate. If your hypothesis is about intra-hour dislocations, the funding series cannot test it; you need the book snapshots.

#The premium uses impact prices, not the mid

premium = impact_price_difference / oracle_price, where the impact difference is max(impact_bid - oracle, 0) - max(oracle - impact_ask, 0). The impact bid and ask are the average execution prices for a fixed notional, not the top of book. Two consequences follow. First, a thin book widens the impact spread and can push the premium away from zero even when the mid sits exactly on the oracle. Second, when the oracle sits inside the impact spread, both max terms are zero and the premium is exactly zero. That dead band shows up in history as long runs where funding equals the interest component precisely.

#The clamp creates two regimes

The clamp bounds r - P to ±0.0005 on the 8-hour basis. When the premium is small, the term is active and funding is pulled toward the interest rate. When the premium is large, the clamp saturates at its edge and funding simply tracks the premium minus 0.05%. The docs' own example makes this concrete: a 1% premium yields a funding rate of 0.95%, not 1.01%. So the series has a flat regime near the interest floor and a linear regime above it. A model that assumes one continuous relationship between premium and funding is wrong at the knee.

#Settlement uses the oracle price and is capped at 4% per hour

The payment at each settlement is position_size × oracle_price × funding_rate. The oracle price is each validator's weighted median of CEX spot prices, not the perp's mark. If you reconstruct funding P&L from positions, use the oracle column, or your numbers will drift during periods when mark and oracle diverge. Funding is capped at 4% per hour regardless of asset, which the docs describe as less aggressive than CEX caps. A capped hour is a censored observation and should be flagged as such.

One more wrinkle for 2026 data. HIP-3 perps, the builder-deployed markets that reached $4.44 billion of open interest in August (The Block), use a different premium formula: premium = 0.5 × (impact_bid + impact_ask) / oracle − 1, plus a deployer-set funding multiplier and interest rate. Funding history for a HIP-3 market and a native market are not the same quantity, and a cross-sectional study that pools them without a venue flag will mix two mechanisms.

#Where Hyperliquid Funding Rate History Comes From

There are four routes to a funding series, and they do not contain the same columns. Pick based on what your research needs to join against, not on which one is easiest to call.

#The API gives you the rate but not the context

fundingHistory is the canonical source for the settled rate and the averaged premium. Call it with a coin, a startTime in milliseconds, and an optional endTime; page by advancing startTime past the last row until the response is short. The response does not carry open interest or oracle price, so a carry backtest built on it alone cannot size positions, compute settlement in USDC, or condition on crowdedness. You will end up joining it against metaAndAssetCtxs snapshots you recorded yourself, which only exist from the day you started recording.

#The archives give context but not guarantees

The asset_ctxs CSVs are the only official source that places funding beside open interest and oracle price at the same timestamp. The docs state plainly that the bucket is uploaded approximately monthly, that there is no guarantee of timely updates, and that data may be missing. For a research dataset that means gap detection is your job. misc_events_by_block is more complete, because funding settlements are protocol events written by the node, but each file is a JSON envelope per block with an events array that is often empty, and the funding variant sits beside transfers, staking, and liquidations.

#The predicted rate is a different series

predictedFundings returns the next hour's expected rate across venues. It is useful for live execution and useless for history: it is not stored, and a settled rate is not what was predicted an hour earlier. Any backtest that uses the settled rate as if a trader could have known it at the start of the hour has look-ahead bias, the same issue we covered for Solana in building a dataset without look-ahead bias.

#What a reconciled dataset adds

The Hyperliquid Historical dataset carries hourly funding as one of its nine tables, reconciled across the API and the node archives, with open interest and oracle price aligned to the same hourly key, and a coverage page that states where gaps exist rather than leaving you to find them. The point is not that the raw sources are bad. It is that a funding study needs the rate, the premium, the oracle, and the open interest on one row, and no single official source delivers that.

#What Funding Does and Does Not Measure

Funding is often described as the market's cost of leverage or a gauge of how crowded the long side is. On Hyperliquid both readings are partly true and partly formula. Here are five effects that show up in a naive analysis as signal and are in fact mechanics.

#The interest floor is a constant, not a sentiment reading

In calm markets the clamp is active and funding sits at or near 0.00125% per hour. Across a universe of 200 markets, most hours look like "slightly positive funding, longs paying shorts." That is the fixed interest rate, present by construction in every hour where the premium is below about 0.06% on the 8-hour basis. A mean-reversion strategy that shorts "positive funding" is mostly shorting a constant. Subtract the interest component before looking for a signal, or model the two regimes separately.

#Zero-premium runs are a liquidity artifact

When the oracle sits inside the impact spread, the premium is exactly zero and funding equals the interest rate exactly. In thin markets this happens for long stretches. A histogram of funding across coins will show a spike at the floor that scales with illiquidity, not with trader conviction. Condition on open interest or impact spread before comparing funding levels across assets.

#The 0.05% offset above the knee is not a discount

Once the premium exceeds the clamp width, settled funding equals premium minus 0.05% on the 8-hour basis. A study that regresses funding on premium will find a slope of one and an intercept of −0.0005. Both are formula constants. Treat them as known, not estimated.

#Capped hours are censored, not extreme

The 4%-per-hour cap is generous, but it binds during liquidation cascades on small-cap perps. A capped hour tells you the premium was at least large enough to hit the cap; it does not tell you how large. Model such hours as censored observations, and never use a capped funding value to estimate the tail of the premium distribution.

#Hourly cadence changes the autocorrelation structure

Centralized venues typically settle every 8 hours. Hyperliquid's hourly settlement means a funding series has 8 times as many observations over the same period, each one an average of 5-second samples. Autocorrelation at lag 1 is high because adjacent hours share the same positioning. A strategy with a 1-hour holding period that "captures funding" captures one-eighth of what an 8-hour-venue strategy would per settlement, and pays taker fees on both legs to do it. Always express rates per hour, then annualize by multiplying by 8,760, and compare against execution cost on the same basis.

The common thread: the funding column is a transformation of the premium index, and the premium index is a transformation of book depth relative to an external oracle. The research question is usually about one of those upstream quantities. Work backward to it rather than treating the final number as the thing itself.

#Backtesting a Carry Strategy on Funding History

A delta-neutral carry trade shorts the perp, holds spot (or a long on another venue), and collects funding when it is positive. It is the simplest strategy that funding history can support, and the one where the mechanics above do the most damage. The steps below assume an hourly table with coin, hour, funding_rate, premium, oracle_px, and open_interest on each row.

1. Define the universe as of each hour, not as of today. Markets get listed and delisted. Build the candidate set from the rows that exist at hour t, and never from the current meta listing, or delisted losers vanish from the sample.
2. Lag the signal by one hour. The decision at hour t can use only settled rates up to t − 1. The rate that settles at t is the first one you collect after entering, and it was not knowable when you entered.
3. Strip the interest component. Compute excess = funding_rate − 0.0000125 per hour. Rank or threshold on the excess, or on a trailing mean of it, so you are not ranking on a constant.
4. Compute funding P&L in USDC using the oracle. Each settlement pays size × oracle_px × funding_rate. Use the oracle column, not mark or last trade, because that is what the clearinghouse uses.
5. Charge the full round trip. Two legs to enter and two to exit, at taker unless you have evidence of maker fills. Annualize both the expected funding and the cost on the same per-hour basis before comparing them.
6. Model the hedge leg's own funding. If the long side is a perp on another venue, it pays or receives that venue's funding on its own clock. Convert to hourly before netting; an 8-hour rate and an hourly rate cannot be summed as they stand.
7. Flag capped hours and gaps. Exclude or censor hours where funding_rate sits at ±4% per hour, and refuse to interpolate across missing hours. A missing settlement is a missing payment, not a zero.
8. Separate HIP-3 markets. Run native and HIP-3 markets as two studies. Their premium formulas differ, and deployer-set multipliers make HIP-3 funding a different distribution.

A worked sanity check: a sustained hourly rate of 0.05% annualizes to 0.0005 × 8,760 ≈ 438%. That number looks like an opportunity until you ask how many consecutive hours it persisted, whether open interest was large enough to absorb a hedge at the quoted impact prices, and whether the hour was capped. In practice the rate decays as arbitrageurs enter, which is the mechanism working as designed. Your backtest should show that decay; if it does not, the universe selection or the lag is wrong.

For the position-level side, our Solana backtesting post covers execution-cost modelling and reproducible Parquet inputs, and the same discipline applies here.

#Validating a Funding Series Before You Trust It

Run these checks on any Hyperliquid funding table, whether you pulled it from the API, decoded it from node archives, or bought it. Each one catches a failure we have seen in real pipelines.

• Row count equals hours in range. For each coin, count(*) should equal the number of hours between listing and the end of coverage. Any shortfall is a gap; locate it, do not fill it.
• Timestamps land on the hour. Settlement times should be on exact hour boundaries in UTC. Off-boundary rows usually mean a snapshot table was mislabelled as a settlement table.
• Units are per hour. The median absolute rate across a liquid market should be on the order of 0.001% to 0.01%. If your median is near 0.01% to 0.1%, you are holding 8-hour rates.
• Interest floor is visible. In calm periods, a large share of rows should equal 0.0000125 (0.00125%) exactly or within rounding. If it never appears, the premium and the clamp were not applied the way the docs describe, or the source transformed the value.
• premium and funding_rate are consistent. Recompute F from P using the formula and compare. Residuals should be zero except on capped hours and HIP-3 markets.
• Capped hours are flagged. Count rows at exactly ±0.04 per hour and mark them.
• Open interest and oracle share the hour key. If they come from a different source, confirm the snapshot time is at or before settlement, never after.
• Coin symbols are stable across renames. Hyperliquid has renamed and relisted assets; check that a coin's history is not split across two symbols.
• HIP-3 markets carry a venue flag. Without it, a pooled study silently mixes two premium formulas.
• Spot-check against userFunding. Pick a wallet with a known position, pull its payments for a day, and reconcile size × oracle × rate against the USDC deltas. This is the only end-to-end test that proves the rate, the oracle, and the settlement convention agree.

If all ten pass, the series is fit for research. If the first three fail, stop; nothing downstream is worth running.

#The Rate Is the Output, Not the Input

Every hour, Hyperliquid folds a fixed interest charge, a clamp, 720 impact-price samples, and an external oracle into one number and moves USDC on it. That number is reproducible and public, which makes it tempting to treat as ground truth. The better framing is that it is the last step of a pipeline, and the research signal lives one or two steps upstream, in the premium and the book depth that produced it.

The immediate action: before the next model run, recompute F from P across your table and count the residuals. If the count is not zero outside capped and HIP-3 hours, you have found the first thing to fix. As HIP-3 markets grow past a third of open interest, the venue flag stops being a nicety and becomes the difference between one study and two.

Inspect the hourly funding table, with oracle and open interest on the same row. Browse the Hyperliquid Historical dataset · Check coverage and known gaps

#Frequently Asked Questions

#How often does Hyperliquid pay funding?

Every hour, on every perpetual market. The rate is computed on an 8-hour basis and one-eighth of it is settled each hour, according to the official docs.

#Is the fundingRate from the API hourly or 8-hour?

Hourly. It is the settled rate for that hour. Do not divide it by 8. To annualize, multiply by 8,760.

#Why does funding often equal exactly 0.00125% per hour?

That is the fixed interest component. When the premium is small, the clamp pulls the rate to the interest floor. It is a formula constant, not a market reading.

#Does the funding payment use the mark price?

No. The settlement is position_size × oracle_price × funding_rate, where the oracle is a weighted median of CEX spot prices.

#How far back does Hyperliquid funding history go?

The fundingHistory endpoint returns full history in pages of 500 rows. The asset_ctxs archive on S3 starts in 2023 but is uploaded roughly monthly with no guarantee of completeness. For reconciled coverage dates, see the dataset coverage page.

#Are HIP-3 funding rates comparable to native perps?

Not directly. HIP-3 markets use a mid-based premium formula and a deployer-set funding multiplier and interest rate. Keep them in a separate study or carry a venue flag.

#Sources

• Hyperliquid docs: Funding · formula, interest rate, clamp, cap, oracle settlement, HIP-3 premium
• Hyperliquid docs: Info endpoint, perpetuals · fundingHistory, userFunding, predictedFundings, metaAndAssetCtxs
• Hyperliquid docs: Historical data · S3 buckets, asset_ctxs, misc_events_by_block, update caveats
• The Block, 8 Sept 2026 · HIP-3 open interest and share of total
• KuCoin News citing The Block, 23 Sept 2026 · $18B open interest record