OKX perp funding: settled, predicted, and the field nobody reads

On any perp venue, “the funding rate” is at least three different numbers. Treating them as one is the source of most of the funding-related bugs we have seen in dashboards, bots, and screenshots. This is a short field guide to OKX's funding-rate surface and the two or three details that consistently trip people up.

The three numbers

• Settled rate. The rate that actually applied at the most recent settlement boundary. Published exactly once per 8 h on OKX. It is a historical fact — useful for PnL accounting, uninteresting for “what will I pay at the next funding?”
• Predicted rate. The venue's running estimate of what the next settlement's rate will look like. Updates continuously (OKX exposes it on a ~1 min cadence). This is the number a position holder actually wants to see — it is the venue's best guess of what you will pay or receive when the timer hits zero.
• Instantaneous premium. The raw premium index at a single instant — perp mid minus index price, expressed in rate units. Noisy by construction, not directly used for settlement on OKX. Common mistake to plot this and call it “the funding rate.” It is not.

Settled and predicted can disagree substantially, especially when the market has moved meaningfully inside an 8-hour window. The settled rate is locked in until the next boundary; the predicted rate is already responding to the new premium regime.

How OKX computes the predicted rate

The predicted rate on OKX (and most major perp venues) is a TWAP of the premium index over the funding interval, plus an interest-rate component, clamped to a venue-published cap. The clamp matters: on a sharply trending day the raw TWAP can blow through the cap and the venue's actual settlement will be the clamped value, not the underlying mean. A reconstruction that ignores the clamp will diverge from the venue UI on exactly the days where the funding rate is most consequential.

Two practical consequences. First: if you are reconstructing predicted funding from premium-index history, you need to apply both the TWAP window and the clamp, not just one. Second: the “predicted” number is path-dependent within the 8-hour window. Two snapshots an hour apart can disagree even on a still market, because the TWAP window has slid forward.

The fundingTime / nextFundingTime trap

OKX's funding-rate endpoint returns two timestamp fields with nearly identical names and very different meanings:

• fundingTime — when the current period settles. This is the timer you want for a countdown.
• nextFundingTime — when the period after that settles. Typically 8 h after fundingTime.

Reading nextFundingTime as the countdown target produces a clock that always reads 8–16 h, never zero. We have seen this bug in production dashboards twice. The symptom is a countdown that looks plausible on a freshly loaded page but never crosses the settlement boundary live.

Per-pair intervals

OKX is uniformly 8 h on every perp. Other venues are not. Binance USD-M lists a handful of altcoin perps on 4 h intervals (and during funding-cap events some pairs run as short as 1 h or 2 h). Hard-coding an 8-hour interval breaks on those.

A safer pattern: infer the interval from the venue's own funding-rate history — the median of the last three gaps between settled ticks. This handles per-pair variation and survives a missing tick. Anchor the projected next settlement on the most recent observed tick rather than ceiling against epoch — venues do not all align their funding schedule to round UTC hours.

Displaying both, useful order

If a UI shows funding to a position holder, the predicted rate is the actionable value and should lead. The settled rate is useful context but historical. We find +0.0021% (last: -0.0056%) reads more naturally than -0.0056% → +0.0021%: the eye lands on the decision-relevant number first, with the prior settlement available in parens for reference. Small UI choice; non-trivial impact on how fast an operator parses the surface.

What this does not cover

We have only addressed OKX in detail. Binance, Hyperliquid, and the modern perp DEXs all have their own implementations of the same three numbers — same conceptual frame, different defaults (interval lengths, clamp values, premium-index methodologies, interest-rate components). The shape of the trap is the same everywhere: settled vs predicted is a real distinction, the predicted number is path-dependent within the window, and the API surface has at least one timestamp field that invites being read wrong.

If you are building anything that reasons about funding — PnL attribution, basis-aware quoting, carry trades — start by walking the venue UI alongside the API for one settlement cycle and verifying you can reproduce its predicted number to within rounding. That single check would have saved every funding bug we have shipped.