> For the complete documentation index, see [llms.txt](https://docs.nexus.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nexus.xyz/trading/trading/perpetuals/funding-rates.md). # Funding rates How funding is measured against the index, when it settles, and what caps it. Funding keeps a perpetual's price anchored to its underlying index. At each funding interval, longs and shorts exchange a payment based on the gap between **where the perpetual trades on our order book** and the index price. There is no expiry and no central counterparty. Funding flows directly between position holders and nets to zero. ### The three prices Funding involves three prices, and each does a different job: | Price | What it is | What it drives | | ------------------------ | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------- | | **Index price** | The external reference price for the asset. | The anchor funding pulls the perpetual back toward. | | **Perp reference price** | What the perpetual is trading at on our book: the volume-weighted median of recent trades. | **The funding premium.** | | **Mark price** | A blend of the index and the perp reference (`w × index + (1−w) × perp reference`, `w = 0.95`). | Your margin, your unrealized PnL, and your liquidation price. | The mark does **not** drive funding, by design. The mark is mostly the index by construction, so measuring the perpetual's deviation against the mark would measure it against a number that already contains the index. That would understate the real deviation by roughly 20×, and funding could no longer pull the perpetual back toward the index. **The mark protects you from thin-book liquidations. The perp reference is what funding measures.** `GET /api/v1/markets/{market_id}/funding` publishes the premium and the rate history, but only one perp-side price. That field is named `mark_price` for historical reasons, but it carries the perp reference the premium is measured against, not the blended mark. The blended mark has no history endpoint. It is available only as the current value on `GET /markets/{market_id}/mark-price`. ### Mechanics * **Interval.** Funding settles **hourly** (`funding_interval_s = 3600`). Per-market configurable. * **Premium sampling.** The premium between the **perp reference and the index** is sampled every **60 seconds** (`funding_sample_interval_seconds = 60`) and time-weighted (TWAP) across the interval. * **Interest component.** The rate carries a fixed interest term of **0.01% per 8 hours** (`i`) for the cost of carry between the two sides. It is **not added unconditionally.** The rate is pulled *toward* `i`, and that pull is itself bounded at **±0.05% per 8 hours** (`b`). When the average premium is already within `b` of `i`, the rate rests exactly at `i`. When it is further away, the interest term contributes at most `±b`. This matches the convention on Binance, Hyperliquid, Aster, EVEDEX and Lighter. * **Rate convention.** The quoted rate is **per 8 hours**, the industry standard. Because our interval is hourly, the amount charged each window is the 8-hour rate pro-rated to the window, which means divided by 8. * **Direction.** The bounded pull creates a **resting band**, not a single flip point. For any average premium between **-0.04%** and **+0.06%** per 8 hours, the pull passes through unclamped and the rate sits exactly at `i` = 0.01% per 8 hours. Longs pay the same small positive rate across that whole band, wherever in it the premium sits. The rate turns negative (shorts pay longs) only once the average premium falls below **-0.05% per 8 hours**, which is `-b`, not `-i`. A perpetual trading exactly at the index, or somewhat cheap to it, still has longs paying. * **Accrual.** Funding is not a lump charge at the boundary. Each sample accrues a pro-rated increment against every open position, so what settles is the accumulated total for the time the position was open during the interval. See [Payment](#payment). * **Settlement.** At each hourly interval boundary, the accrued funding is applied to every open position. The sum across all positions is zero (no value is created or destroyed by funding). Putting the last three together, the rate charged for one hourly window is: ``` interest_pull = clamp( 0.0001 − avg_premium , ±0.0005 ) rate_charged = clamp( (avg_premium + interest_pull) × 1/8 , ±funding_rate_cap ) ``` ### Thin markets The perp reference is the volume-weighted median of the **last 5 trades**, whenever the market has any trade history at all. It falls back to the index price, which reads as a zero premium for that sample, in two cases. The first is a market that has **never traded**, since the median needs at least one print to compute from. The second is an oracle re-anchor on a large jump. A large enough move clears the recorded trade history, so the reference has nothing to compute from until the market trades again. That second case hits a market that has traded before, right after a large price move, which is when funding matters most. There is currently no time-based staleness check on those 5 trades. If a market trades a handful of times and then goes quiet, the reference keeps reflecting those prints, however old, until enough new trades push them out of the window. A quiet market does not fall back to a zero premium on its own. ### Per-window cap Each market caps how large a single funding payment can be, to bound risk during volatile periods: ``` funding_rate_cap = 0.001 (0.1% per window — the crypto-perp value; FX, commodity, and index perps use 0.0005) ``` This outer cap applies **after** the bounded interest pull and the 8-hour pro-rating. Once the premium is far from `i`, the pull has saturated at `−b`, and the cap engages at a basis of `8c + b`: ``` (basis − 0.0005) × 1/8 > 0.001 → clamps at a 0.85% basis ``` So a crypto perp, whose `funding_rate_cap` is `0.001`, pays the capped rate once it trades more than \~0.85% away from the index. The cap is a per-market parameter and differs across listed markets. The FX, commodity, and index perps (seven markets, including NDQ) are configured at `funding_rate_cap = 0.0005`, which binds at a 0.45% basis instead. Which markets in each class are deployed on testnet or mainnet changes with the venue's rollout state. See [Market Specifications](/trading/trading/perpetuals/market-specifications.md) for the live per-market set rather than a fixed snapshot here. The cap is relaxed across release gates as the system is validated under wider conditions. ### Payment Funding **accrues continuously and settles at the interval boundary**. Each premium sample advances a running total for every open position: ``` accrual = position_notional × rate_sample × (elapsed / funding_interval_s) ``` At the boundary, the interval's accumulated total is charged against (or credited to) account equity. So a position opened part-way through an interval pays only for the time it was open, at the rates in effect while it was open, not the settled rate applied to the whole interval. A position opened five minutes before the boundary on an hourly interval accrues roughly one twelfth of a full-interval payment. Held for a complete interval at a steady rate, that reduces to the familiar closed form: ``` funding_payment = position_notional × rate_charged ``` where `position_notional = position_size × index_price`. Funding is independent of unrealized PnL. You can pay funding on a profitable position or receive it on a losing one. ### Worked example A `BTC-USDX-PERP` position over one hourly interval, using that market's deployed parameters: `funding_interval_s = 3600`, `funding_rate_cap = 0.001`. You hold **2 BTC long**. Over the hour, the time-weighted average premium of the perp reference over the index comes out at **+0.12% per 8 hours**, so the perpetual traded rich to the index. The index sits at **60,000**. | Step | Value | | ----------------------------------- | ---------------------------------------------------------- | | Average premium (per 8h) | **0.1200%** | | Interest pull | `clamp(0.0001 − 0.0012, ±0.0005)` = **−0.0005**, saturated | | 8-hour quote | `0.0012 + (−0.0005)` = **0.0700%** per 8h | | Pro-rate to the hourly window (÷ 8) | **0.008750%** | | Outer cap binds? | `0.0000875 < 0.001` → **no** | | Position notional | `2 × 60,000` = **120,000** | | **Funding paid** | `120,000 × 0.0000875` = **10.50 USDX** | The premium was positive, so longs pay shorts: 10.50 USDX leaves your equity and is distributed across the short side. Had you held the same position for only the **last 15 minutes** of the interval, you would have accrued roughly `10.50 × 15/60` = **2.62 USDX**, because funding accrues per sample, not as a lump charge at the boundary. The example shows three things. First, the interest pull **saturated**. At a 0.12% premium the average is well outside the ±0.05% band around `i`, so the interest term subtracted its full bound rather than adding 0.01%. That is why the quote came out *below* the raw premium, not above it. Second, at an average premium of exactly 0% the pull would instead pass through unclamped, and longs would pay `0.0001 / 8` = **0.00125%** for the hour. Third, the outer cap is far away here. It would only bind above a **0.85%** premium, roughly seven times the premium above. The formal derivation of the premium, the interest term, the cap and the accrual is in the [Math Engine's funding-rate chapter](https://docs.nexus.xyz/math-engine/funding-rate). > **Status:** funding is live on testnet with hourly settlement and the parameters above. Per-market rates and caps are configurable and subject to tuning between gates. See [Market Specifications](/trading/trading/perpetuals/market-specifications.md) for the per-market intervals and caps. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.nexus.xyz/trading/trading/perpetuals/funding-rates.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.