> 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/math-engine/funding-rate.md). # Funding Rate Perpetual futures never expire, so a periodic cash transfer between longs and shorts — funding — anchors the contract's price to the oracle (spot) price. During each funding interval the Exchange samples the instantaneous premium index $$(P\_{ref} - P\_{oracle})/P\_{oracle}$$ — the perpetual's own traded price against the oracle, not the mark (F.1) — and accumulates it weighted by the time elapsed since the previous sample. At any point in the interval the rate is the time-weighted average premium plus a fixed interest component, pro-rated from an 8-hour quote convention to the actual settlement window and clamped to a symmetric cap $$\pm c$$ (F.3). At settlement, each position pays or receives an amount proportional to its notional value at the oracle price (F.4): with a positive rate, longs pay shorts; with a negative rate, shorts pay longs. The construction is exactly zero-sum between matched long and short open interest. ![The funding rate is a fan-in of the premium accumulator and the interval clock, and settlement feeds back both into a fresh accumulator and into the positioning pressure that moves the next premium.](/files/fhOhTBi5KwZFG60k6O6S) *The funding rate is a fan-in of the premium accumulator and the interval clock, and settlement feeds back both into a fresh accumulator and into the positioning pressure that moves the next premium.* ## Setting | Symbol | Name | Description | Units | Domain | | --------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------- | --------- | | $$P\_{oracle}$$ | oracle\_price | External index (oracle) price of the underlying asset. Samples with a non-positive oracle price are skipped by the implementation, so the effective domain is strictly positive. | USDX per unit of asset | (0, ∞) | | $$P\_{ref}$$ | perp\_reference\_price | The perpetual's own traded price on the Exchange's book — the volume-weighted median of the recent-trade window (O.7). This is the perp side of the premium index. `OracleValidator::trade_reference_price` returns the last trade price when the window is empty, and `None` when that is also unset — a market that has never traded, or one whose trade history and last trade price were both just cleared by a large oracle re-anchor (`OracleValidator::accept_trusted`) — at which point the oracle commit path substitutes $$P\_{oracle}$$ (`commit_oracle_and_sample_funding`); there is no time-based staleness check on the window otherwise, so on a market that traded a few times and then went quiet without a re-anchor, $$P\_{ref}$$ keeps reflecting those trades — however old — until enough new trades displace them. | USDX per unit of asset | (0, ∞) | | $$P\_{mark}$$ | mark\_price | The Exchange's mark price, $$w \cdot P\_{oracle} + (1-w) \cdot P\_{ref}$$. Drives margin and liquidation — but NOT the premium index (see F.1) or the settlement notional, which is struck at $$P\_{oracle}$$ (see F.4). | USDX per unit of asset | (0, ∞) | | $$i$$ | interest\_8h | Fixed interest component of the rate quote, added to the average premium before clamping. $$0.0001$$ (0.01% per 8h). | dimensionless (per 8h) | fixed | | $$W$$ | window\_secs | Length of one funding settlement window. Hourly in production (3600). | seconds | (0, ∞) | | $$\Delta t$$ | time\_delta\_secs | Seconds elapsed since the previous sample in the interval. Samples at or before the previous sample time are ignored, so the effective domain is strictly positive. Derived in code from millisecond timestamps divided by 1000. | seconds | (0, ∞) | | $$A$$ | accumulated\_premium | Running sum of premium-index samples weighted by their time deltas, $$\sum\_i p\_i , \Delta t\_i$$, over the current funding interval. Reset to zero at each interval boundary. | dimensionless-seconds (premium × seconds) | unbounded | | $$T$$ | total\_time\_secs | Total elapsed time in the current interval, from the interval start to the most recent sample. Derived, not stored: when zero (no samples yet) the implementation short-circuits and returns a zero rate rather than dividing. | seconds | (0, ∞) | | $$c$$ | funding\_rate\_cap | Per-market symmetric cap on the funding rate, stored in market parameters. Two configured values: $$0.001$$ (0.1% per settlement window) on the crypto perps, $$0.0005$$ on the FX, commodity, and index perps. Which markets in each class are actually deployed changes with the venue's rollout state — see Market Specifications for the live per-market set rather than a fixed snapshot here. | dimensionless (fraction per funding interval) | (0, ∞) | | $$f$$ | funding\_rate | The clamped funding rate applied to positions at settlement; always lies in $$\[-c, +c]$$. | dimensionless (fraction per funding interval) | \[-c, +c] | | $$S$$ | size | Absolute position size in units of the underlying asset (always non-negative; direction is carried separately by the position side). | units of asset | \[0, ∞) | | $$\sigma$$ | side\_sign | Direction indicator for the position: $$+1$$ for a long position, $$-1$$ for a short position. Encodes the match on position side in the implementation. | dimensionless | \[-1, 1] | ## The mechanism ### Premium Index Sampling Each oracle tick produces one sample of the instantaneous premium index: the relative deviation of the **perpetual's own traded price** from the oracle price. The numerator is $$P\_{ref}$$, not $$P\_{mark}$$, and the distinction is load-bearing. Since $$P\_{mark} = w \cdot P\_{oracle} + (1-w) \cdot P\_{ref}$$, substituting the mark would give $$(P\_{mark} - P\_{oracle})/P\_{oracle} = (1-w) \cdot (P\_{ref} - P\_{oracle})/P\_{oracle}$$ — the true premium scaled by $$(1-w)$$, i.e. 5% of it at the production $$w = 0.95$$, with a damping factor that moves silently whenever a margin parameter is retuned. The premium is defined against the traded price so that it measures the deviation it is named for. A positive premium means the perpetual trades rich to the index (longs are crowded); a negative premium means it trades cheap. The implementation skips any sample whose oracle price is not strictly positive, leaving the interval state unchanged, so the division is always well defined. $$ p = \frac{P\_{ref} - P\_{oracle}}{P\_{oracle}} \tag{F.1} $$ Samples arrive at an irregular cadence, so each premium index (F.1) is weighted by the time elapsed since the previous sample before being added to the interval accumulator $$A$$. This makes the accumulator the exact time integral of the (piecewise-constant) premium index over the interval, independent of sampling frequency: 1-minute and 5-second cadences produce identical averages for the same premium path. Samples with a timestamp at or before the previous sample time are ignored, so $$\Delta t$$ is strictly positive. $$ A \leftarrow A + p \cdot \Delta t \tag{F.2} $$ ### Funding Rate The funding rate is built in three steps: the time-weighted average premium (the accumulator (F.2) divided by total elapsed time $$T$$), plus the fixed interest component $$i$$, pro-rated from the 8-hour quote convention to the actual settlement window $$W$$, and finally clamped to the symmetric per-market cap $$\pm c$$. The quote convention matters: $$A/T + i$$ is a **per-8-hour** rate, the industry standard. The amount charged at an hourly boundary is that rate scaled by $$W / 28800$$. The clamp is applied last, to the pro-rated value, so $$c$$ bounds the wealth transfer per settlement window regardless of how dislocated the perpetual becomes. When no time has elapsed in the interval ($$T = 0$$, i.e. no samples yet), the implementation returns zero rather than dividing by zero. The predicted funding rate published mid-interval is defined to be this same value: the current average is the best estimate of the final rate. $$ f = \operatorname{clamp}!\left(\left(\frac{A}{T} + i\right) \cdot \frac{W}{28800},; -c,; +c\right) \tag{F.3} $$ Because the clamp binds on the composed quantity, the basis at which it engages is $$8c - i$$: at the production $$c = 0.001$$ that is a **0.79% basis**, not 0.1%. ### Funding Payments At settlement each open position exchanges cash proportional to its notional value **at the oracle price**. The signed amount is the position's notional $$S \cdot P\_{oracle}$$ times the funding rate (F.3), with the sign flipped for shorts via $$\sigma$$. The convention is: a positive amount means the account pays; a negative amount means the account receives. So with a positive rate ($$f > 0$$, perpetual rich to index) longs pay and shorts receive, and with a negative rate shorts pay and longs receive. For equal long and short size at the same rate, the two amounts cancel exactly. The notional is struck at $$P\_{oracle}$$ rather than $$P\_{mark}$$ so that both sides of a matched pair are valued on the same external anchor — the two counterparties must exchange identical magnitudes, and the oracle is the price neither side's own trading can move. $$ \Pi = \sigma \cdot S \cdot P\_{oracle} \cdot f \tag{F.4} $$ ## Invariants * The funding rate is always bounded: $$-c \le f \le +c$$ for every interval state ((F.3)). * Zero premium implies a rate of exactly the pro-rated interest: if $$P\_{ref} = P\_{oracle}$$ for the whole interval, then $$A = 0$$ and $$f = i \cdot W/28800$$. (Earlier revisions of this model omitted the interest term and read this as a zero rate; the interest term makes the resting rate non-zero.) * When not clamped, the sign of the rate matches the sign of $$(A/T + i)$$, not of the average premium alone: a perpetual trading rich enough to the index yields $$f > 0$$; $$f < 0$$ needs $$A/T < -i$$, i.e. the perpetual must trade cheap by more than the interest component (0.01% per 8h) before the rate flips negative. * Funding is exactly zero-sum for matched open interest: for equal long and short size at the same oracle price and rate, $$\Pi\_{long} + \Pi\_{short} = 0$$ ((F.4)); verified by property-based testing across the full rate range. * Payments are linear in position size: tripling $$S$$ triples $$\Pi$$ exactly. * The rate is well defined at all times: with no samples in the interval ($$T = 0$$) the rate is exactly $$0$$, never a division error. * Samples with non-positive oracle price or non-increasing timestamps leave the interval state unchanged. * The TWAP is sampling-cadence invariant for a constant premium: any positive sampling frequency yields the same $$f$$ for a given premium $$p$$, equal to $$(p + i) \cdot W/28800$$ (when below the cap) — not to $$p$$ itself, since the interest term and the window pro-rating both apply. ## Worked example Consider the BTC perpetual with the oracle steady at $$P\_{oracle} = 50{,}000$$, observed over 8 hours of premium accumulation. For the first 4 hours the perp reference is $$50{,}020$$, a premium index of $$p\_1 = 20/50{,}000 = 0.0004$$ per (F.1); for the last 4 hours it is $$50{,}035$$, so $$p\_2 = 35/50{,}000 = 0.0007$$. Sampling once per minute, each phase contributes its premium times its duration to the accumulator per (F.2): $$A = 0.0004 \times 14{,}400 + 0.0007 \times 14{,}400 = 5.76 + 10.08 = 15.84$$ premium-seconds. Over $$T = 28{,}800$$ seconds the raw time-weighted average premium is $$A/T = 15.84 / 28{,}800 = 0.00055$$ — exactly the duration-weighted mean of the two phases, $$(0.0004 + 0.0007)/2$$. Adding the interest component gives an 8-hour quote of $$0.00055 + 0.0001 = 0.00065$$. Production settles **hourly**, so per (F.3) the rate actually charged at a boundary is that quote pro-rated: $$f = 0.00065 \times 3600/28800 = 0.00008125$$. With a cap of $$c = 0.001$$ this is far inside the band, so the clamp does not bind. Now settle a 2 BTC long. Its notional is $$2 \times 50{,}000 = 100{,}000$$ USDX, so per (F.4) the payment is $$\Pi = +1 \times 100{,}000 \times 0.00008125 = 8.125$$ USDX — positive, so the long pays. A 2 BTC short of the same size has $$\Pi = -8.125$$ USDX and receives the same amount: the transfer is exactly zero-sum. Had the perpetual instead sustained a 10% premium, the 8-hour quote of $$0.1001$$ would pro-rate to $$0.01251$$ and be clamped to $$c = 0.001$$, so every position would settle at the cap. Note where that boundary sits: the clamp engages at a basis of $$8c - i = 0.0079$$, i.e. **0.79%**, not at 0.1%. ## Analysis > **Stale relative to the model above.** The Sensitivity, Response curves, and Parameter space sections below are machine-generated by the math-engine pipeline (`eng/ops/intelligence/math-engine`, owned by the Modeling & Security pod) from an earlier revision of this model — they still elasticize/plot against `mark_price` rather than `perp_reference_price`/`oracle_price`, and the surfaces still hold the cap at `±0.0075` (0.75%) rather than the production `0.001` (0.1%) discussed above. Regenerating them requires that pipeline to re-derive the model from the current Rust source, which is out of scope for this doc-alignment pass; flagging here rather than hand-editing generated output or silently leaving it uncaveated. ### Sensitivity Elasticities ε = (∂y/∂x)·(x/y), computed numerically from the verified expressions at each worked-example point. |ε| > 1 means the output moves more than proportionally with that input. | Expression | Input | Elasticity ε | | --------------------- | -------------------- | ------------ | | `premium_index` | mark\_price | 1.43e+03 | | `premium_index` | oracle\_price | -1.43e+03 | | `sample_contribution` | mark\_price | 1.43e+03 | | `sample_contribution` | oracle\_price | -1.43e+03 | | `sample_contribution` | time\_delta\_secs | 1 | | `funding_rate` | accumulated\_premium | 1 | | `funding_rate` | total\_time\_secs | -1 | | `funding_rate` | funding\_rate\_cap | 0 | | `funding_payment` | side\_sign | 1 | | `funding_payment` | size | 1 | | `funding_payment` | mark\_price | 1 | | `funding_payment` | funding\_rate | 1 | ![Sensitivity tornado — Premium index](/files/0rmlq9xOdNUQCEyMqtoG) ![Sensitivity tornado — Funding rate (clamped TWAP)](/files/D5A0l56shLjrGV6vccNq) ![Sensitivity tornado — Funding payment](/files/4NjHeksTEZDaxcAiyABd) ### Response curves ![The instantaneous premium index is linear in the mark price and crosses zero exactly where mark equals the fixed $50,000 oracle price.](/files/1SUb1mnSA8fBVdGHRDph) *The instantaneous premium index is linear in the mark price and crosses zero exactly where mark equals the fixed $50,000 oracle price.* ![Over a full 8-hour interval (T = 28,800 s) the funding rate rises linearly with the accumulated premium until the average hits the ±0.0075 cap, where it saturates.](/files/tqWwYRMIzFSX3NdUVsJg) *Over a full 8-hour interval (T = 28,800 s) the funding rate rises linearly with the accumulated premium until the average hits the ±0.0075 cap, where it saturates.* ![At a positive 0.05% rate and $50,000 mark price, payments scale linearly with size and are exactly mirrored between long and short, so matched open interest nets to zero.](/files/D9Gh9DRfsPPKs892Ov1G) *At a positive 0.05% rate and $50,000 mark price, payments scale linearly with size and are exactly mirrored between long and short, so matched open interest nets to zero.* ### Parameter space Joint parameter effects evaluated from the verified expressions over 2-D grids. ![The clamp carves wedge-shaped saturation zones where |accumulated premium / time| exceeds the ±0.75% cap, so short accumulation windows saturate at far smaller premiums; cap held at 0.0075.](/files/ji9aNK1hpC7XtKG2JwFF) *The clamp carves wedge-shaped saturation zones where |accumulated premium / time| exceeds the ±0.75% cap, so short accumulation windows saturate at far smaller premiums; cap held at 0.0075.* ![The bilinear size × rate interaction produces hyperbolic level sets of equal payment, with the sign flip at rate = 0 splitting payers from receivers; mark price held at 50,000 for a long position.](/files/NAwQ05XWubuRagsGi4Av) *The bilinear size × rate interaction produces hyperbolic level sets of equal payment, with the sign flip at rate = 0 splitting payers from receivers; mark price held at 50,000 for a long position.* ## References * Derived from and adversarially verified against the Exchange's Rust implementation and its test suite. * Sibling model: [insurance-fund](/math-engine/insurance-fund.md) * Sibling model: [liquidation-engine](/math-engine/liquidation-engine.md) * Sibling model: [margin-math](/math-engine/margin-math.md) * Sibling model: [oracle](/math-engine/oracle.md) * Sibling model: [order-book](/math-engine/order-book.md) * Sibling model: [position-tracker](/math-engine/position-tracker.md) * Sibling model: [settlement](/math-engine/settlement.md) --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.nexus.xyz/math-engine/funding-rate.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.