Skip to main content

Documentation Index

Fetch the complete documentation index at: https://hypernode-docs.polynode.dev/llms.txt

Use this file to discover all available pages before exploring further.

HyperLiquid’s funding rate system keeps perpetual contract prices aligned with their underlying spot prices. It combines an on-chain oracle system, configurable mark price calculation, and per-perp funding parameters.

​
Oracle system

The oracle layer provides price feeds for all assets on the exchange. Oracles are classified by the OracleKindMap into three modes:
Oracle KindDescription
OpenContinuously updated oracle. Validators publish prices every ~3 seconds, computed as a weighted median across external exchanges (Binance weight 3, OKX 2, Bybit 2, Kraken 1, Kucoin 1, Gate IO 1, MEXC 1, HL spot 1). The final oracle price is the stake-weighted median of validator submissions.
QueueQueued delivery oracle. Price updates are batched and applied in sequence, used for assets where atomic price updates could create extraction opportunities.
RoundRound-based oracle with discrete update windows. Prices update at fixed intervals rather than continuously, suitable for assets with lower liquidity or update frequency requirements.
Each block receives multiple price inputs that feed into funding calculations: 
mark_px_inputs          -- mark price calculations
spot_px_inputs          -- spot price feeds
external_perp_px_inputs -- external perpetual prices (e.g., from Binance)
oracle_pxs              -- oracle price updates

​
Mark price calculation

The mark price is the reference price used for funding rate computation and liquidation triggers. It is derived from a combination of:
  1. Oracle price — the external reference price for the underlying asset
  2. Spot price inputs — on-chain spot market prices where available
  3. External perp prices — prices from external perpetual exchanges for cross-referencing
  4. Order book mid-price — the current mid-market price on HyperLiquid
The mark price aims to be resistant to short-term manipulation while remaining responsive to genuine price movements.

​
Impact USD

The funding rate calculation uses an impact USD parameter that determines the notional size used when sampling the order book for the premium/discount calculation: 
impact_usd         -- impact USD for funding calculation
default_impact_usd -- default impact USD value
A larger impact_usd value smooths out the funding rate by sampling deeper into the order book, while a smaller value makes funding more responsive to thin liquidity at the top of book.
Impact USD is conceptually similar to Binance’s “Impact Margin Notional” — it represents the notional value used to calculate the bid/ask impact prices that determine the premium index.

​
Funding rate formula

HyperLiquid supports two funding rate formulas:

​
Default formula

The standard funding rate is calculated as: 
Premium = (Impact Bid Price + Impact Ask Price) / 2 - Oracle Price
Funding Rate = clamp(Premium / Oracle Price + Interest Rate, -clamp, +clamp)
Where clamp limits the maximum funding rate per period to prevent extreme values. On most exchanges with similar mechanisms, the clamp is typically set to 0.05% (5 basis points) per 8-hour interval, though HyperLiquid’s specific clamp values are governance-configurable per asset. Example calculation: 
Oracle Price = $100.00
Impact Bid = $100.08
Impact Ask = $100.12
Premium = ($100.08 + $100.12) / 2 - $100.00 = $0.10
Funding Rate = clamp($0.10 / $100.00 + 0, -0.05%, +0.05%) = 0.05%
In this example, the raw premium is 0.10% but it exceeds the clamp, so the funding rate is capped at 0.05%. Longs would pay shorts 0.05% of their position value at the next funding settlement.

​
Settlement frequency

Funding is settled every hour at one-eighth of the computed 8-hour rate. The formula calculates an 8-hour funding rate, but payments are distributed hourly in equal installments. For example, a 0.05% 8-hour rate results in ~0.00625% paid each hour.

​
Binance formula option

HyperLiquid can optionally use the Binance funding formula for specific perps: 
use_binance_formula -- flag to enable Binance-style funding calculation
When enabled, the funding rate follows the Binance premium index and funding rate methodology, which uses a time-weighted average premium over the funding interval.

​
Per-perp funding parameters

Each perpetual market has individually configurable funding parameters:

​
Funding multipliers

perp_to_funding_multiplier -- per-perp funding multiplier
The funding multiplier scales the calculated funding rate for a specific market. A multiplier greater than 1.0 amplifies funding payments, while less than 1.0 dampens them. This allows the protocol to tune funding aggressiveness per market based on liquidity conditions and historical premium behavior.

​
Interest rates

perp_to_funding_interest_rate -- per-perp interest rate
The interest rate component represents the baseline rate embedded in funding. For most perps this is close to zero, but it can be configured per-market. This is distinct from the borrow/lend interest rates in the BOLE system, though the two interact: 
setFundingInterestRates       -- governance action to set per-asset rates
assetToFundingInterestRate    -- map of asset -> funding interest rate

​
HL-only perps

Some perpetual markets exist only on HyperLiquid without an external reference price: 
hl_only_perps -- perps only on HL (no external reference)
For these markets, the funding rate relies entirely on the on-chain oracle and order book premium, since there is no external perp price to cross-reference.

​
Funding distribution

Funding payments are distributed between longs and shorts based on the calculated rate. The distribution process is rate-limited by guard mechanisms: 
funding_distribute_guard -- rate limiter for distributions
funding_update_guard     -- rate limiter for rate updates
funding_err_dur_guard    -- error duration tracking
The execution sequence each interval is: 
update_funding_rates -> refresh_hip3 -> apply_bole_liquidations
Funding rate updates, HIP-3 oracle refreshes, and borrow/lend liquidation checks happen in a fixed sequence. This ordering matters because funding rate changes can affect margin levels, which in turn can trigger liquidations.

​
Distribution guards

The three guards serve distinct purposes:
GuardPurpose
funding_distribute_guardControls how frequently funding payments are settled to user accounts
funding_update_guardControls how frequently the funding rate itself is recalculated
funding_err_dur_guardTracks and rate-limits error conditions during funding calculation
These guards prevent excessive computation per block and ensure funding calculations remain consistent across the validator set.

​
Per-block execution data

Each block produces several data outputs relevant to funding: 
node_trades              -- executed trades
node_fills               -- fill events
node_raw_book_diffs      -- raw order book changes
hip3_oracle_updates      -- HIP-3 oracle price updates
The hip3_oracle_updates field is particularly relevant for HIP-3 deployed tokens that use deployer-managed oracle feeds rather than the protocol’s built-in oracle system.