If you searched for how the funding rate is calculated, you almost certainly already have a number in front of you — the percentage on the exchange’s contract page — and you want to know where it came from, and why the figure you worked out by hand does not match what actually hit your account.
The formula is not the hard part. The hard part is the three assumptions sitting around it: the settlement interval, what the rate gets multiplied by, and the factor used to annualise. Get any of them wrong and nothing throws an error. You just get a number that looks entirely reasonable.
The formula: premium index first, interest term damped, then normalised by frequency
Binance has used this form for USD-M perpetuals since 18 September 2025:
F = [ P + clamp(I − P, 0.05%, −0.05%) ] ÷ (8 / N)- P — average premium index. How far the contract has drifted from the spot index, taken as a weighted moving average across the settlement window. Contract above spot, P is positive; below spot, negative. This term is the funding rate; everything else only adjusts it.
- I — interest rate. A constant the exchange sets, standing in for the borrowing-cost difference between the quote currency and the base currency. The default is 0.03% per day, which works out to 0.01% over an eight-hour window. BNBUSDT and ETHBTC are set to zero.
- clamp(…, 0.05%, −0.05%) holds the interest-versus-premium difference inside ±0.05%. It is a damper: when the premium swings hard, this term is not allowed to drag the rate somewhere absurd.
- N — settlement frequency, in hours.
8 / Nis the frequency normalisation factor. What the brackets produce is an eight-hour baseline rate; dividing by 8/N gives the amount this particular contract actually settles each period.
That divisor was only added in September 2025, and it is the piece most explainers still leave out. Run the old formula against a contract that settles every four hours and you get a number exactly twice too large.
It arrived alongside the shortening of settlement intervals. Extreme funding had shown up on individual contracts, and a shorter cycle spreads the shock of any single settlement — but spreading it should not quietly double what a full day costs. With the divisor in place, the same premium level produces the same daily total no matter how many settlements it gets split across.
Mistake one: assuming everything settles every eight hours
“Every eight hours, at 00:00, 08:00 and 16:00 UTC” is the most-repeated sentence on this subject, and it is only true for some contracts. Binance runs a batch on four hours and a few on one.
There is a trap in the API here. fapi/v1/fundingInfo only lists the pairs whose interval has been adjusted — everything else simply does not appear in the response. So “this symbol isn’t in the list” means “it is the standard eight hours”, not “unknown”. Our own scanner encodes exactly that: absent falls back to eight, with the value clamped between 0 and 24 hours, because an absurd interval gets multiplied straight into the borrow-rate calculation and nothing downstream will complain about it.
Get the interval wrong and every step after it is wrong too: the per-period amount, the annualised figure, and the hour count used for carrying costs. All three fail silently.
Mistake two: multiplying your margin by the rate
Funding is charged on notional value, not on margin. Notional = mark price × position size.
A position with 1,000 USDT of margin at 10x leverage carries 10,000 USDT of notional. At a rate of 0.01%, that settlement moves 10,000 × 0.01% = 1 USDT, not 0.1. Leverage scales notional, so it scales the funding payment with it — a cost if you are simply long, income if you are collecting the rate inside a hedged position, and an error of the same size either way.
One more thing that gets missed: you only pay or receive if you hold the position at the settlement timestamp. Close a minute before 00:00 and that period costs you nothing and pays you nothing; open a minute after it and the same applies. Funding does not accrue over your holding time. It is a transfer taken from an instantaneous snapshot.
Mistake three: annualising with three times 365
Three settlements a day, 365 days a year, so people write rate × 1095. That holds for eight-hour contracts and is half the right answer for four-hour ones.
The general form works in hours:
annualised = per-period rate × 8760 ÷ interval in hours8760 is the number of hours in a year. Eight-hour intervals give a multiplier of 1095, four-hour ones 2190, one-hour ones 8760.
| Interval | Settlements per year | Annualised at 0.01% per period |
|---|---|---|
| 8 hours | 1,095 | 10.95% |
| 4 hours | 2,190 | 21.90% |
| 1 hour | 8,760 | 87.60% |
With the normalisation factor in place, a four-hour contract at the same premium level already prints half the per-period number an eight-hour one would, so the annualised figures land in the same place. The table is there for a different and more common error: two identical-looking numbers in a funding table are not worth the same. Annualise before sorting across symbols, or the four-hour contracts get pushed systematically below where they belong.
A worked example you can check
An eight-hour USDT perpetual, with an average premium index of P = 0.008% over some window, and I = 0.01%:
I − P = 0.002%, inside ±0.05%, so the clamp does nothing and it passes through unchanged- brackets =
0.008% + 0.002% = 0.01% N = 8, so8 / N = 1and there is no scaling → F = 0.01%- on 20,000 USDT of notional, longs pay 2 USDT and shorts receive 2 USDT
- annualised =
0.01% × 8760 ÷ 8 = 10.95%
Same premium on a four-hour contract: the brackets still give 0.01%, divided by 8 / 4 = 2 for 0.005% per period, and 0.005% × 8760 ÷ 4 = 10.95% annualised. The two agree, which is exactly what the normalisation factor is for — and a free way to check your own arithmetic. If they disagree, a step went wrong somewhere.
For why this payment exists at all, what a funding rate is starts from the missing expiry date on a perpetual contract.
The rate you calculate is not the yield you keep
This is the last gap between a funding calculator and a real account statement. Collecting one period of funding costs four taker fills: two legs, each opened and closed.
round-trip cost = 2 x (perp taker fee + spot taker fee)
+ 2 x (perp half-spread + spot half-spread)
break-even periods = round-trip cost / per-period rate, rounded upThe spread term is the one that gets dropped, and it is the same order of magnitude as the fees. Measured on our own accounts: INJUSDT came to 0.30% in round-trip fees and 0.048% in round-trip spread. CHRUSDT prices to five significant figures, so a single tick is 0.074% and the round-trip spread lands around 0.30% — as expensive as the fees themselves. The ugliest of them was HOLOUSDT: counting fees alone, one period nets +0.002% and reads as tradeable; with the spread included it is −0.09%.
Which is why an annualised figure on its own tells you very little. Pair it with the break-even count: if a row needs 20 periods, roughly 6.7 days, to pay back its costs, and the rate typically flips sign within two, that row is not tradeable at all. How the strategy handles this in practice covers the execution side, and the year-by-year record is published in full, worst year included.
Checking it yourself
- Current rate and next settlement time: the funding row on the contract page, or
fapi/v1/premiumIndex - Whether this contract runs on eight hours:
fapi/v1/fundingInfo— absent from the response means eight - Settled historical rates:
fapi/v1/fundingRate. This is not the same thing as the live estimate for the current period, which is still moving - What you were actually charged: the funding fee entries in your account statement, checked against notional × rate
When the numbers refuse to reconcile, it is nearly always one of those three — the interval, the base, or the annualisation. For anything else, the FAQ is a reasonable first stop.