Crypto funding rate caps and floors bound the final rate for a specified perpetual contract and funding interval. They are separate from the damping clamp inside some funding formulas. To estimate a holding cost, check both stages, the current limits and the settlement schedule: a capped rate every hour can create a very different cash obligation from the same capped rate every eight hours.
A limit on one rate is also different from a limit on total account loss. Position value can change, the contract can settle repeatedly, and the venue can revise its parameters. Start with the contract's current rules, then calculate the cash amounts across the events you intend to model.
Read the two clamps separately
A clamp returns its input if that input lies within two boundaries; otherwise it returns the nearest boundary. To avoid ambiguity, this article writes clamp(x, lower, upper). Some exchange documentation lists the upper boundary first, so copy the meaning rather than assuming its argument order matches a programming library.
Bybit documents a funding formula containing an inner clamp on the interest-minus-premium difference and an outer clamp on the resulting rate. Its ordinary formula can be evaluated in three steps. Bybit's funding-rate methodology is the venue-specific reference.
Call the inner adjustment A: clamp I − P between −d and +d. Form the uncapped rate as U = P + A. Then obtain the final rate by clamping U between the lower funding limit and the upper funding limit.
Here, P is the applicable average premium index, I is the interest component and d is the damping boundary. Bybit's documented damping boundary is 0.05%. This does not mean the final funding rate is confined to ±0.05%: the premium is added after that inner adjustment is bounded.
When I − P stays inside the damping boundaries, adding the full difference to P produces I. Outside that region, the adjustment cannot fully offset the premium. The uncapped rate can consequently move far beyond the damping boundary before the outer limit applies.
This calculation is a model of that nested structure, not a universal formula for every exchange. In particular, Binance's published calculation includes an interval scaling term before its final cap. Check the chosen contract's methodology before transferring inputs between venues. Binance's funding-rate calculation describes that additional step.
Worked example: a 0.05% damper and a 0.30% cap
The following numbers describe a hypothetical contract, not current parameters for a listed symbol. Assume one eight-hour interval, I = 0.01%, d = 0.05%, an upper limit of +0.30% and a lower limit of −0.30%. All arithmetic in the table uses percentage points consistently.
| Average premium P | Interest minus premium | Bounded adjustment | Uncapped rate | Final rate |
|---|---|---|---|---|
| +0.02% | −0.01% | −0.01% | +0.01% | +0.01% |
| +0.20% | −0.19% | −0.05% | +0.15% | +0.15% |
| +0.50% | −0.49% | −0.05% | +0.45% | +0.30% |
| −0.50% | +0.51% | +0.05% | −0.45% | −0.30% |
The third row has two distinct binding constraints. The inner stage restricts a proposed −0.49% adjustment to −0.05%; the outer stage restricts the resulting +0.45% rate to +0.30%. Applying the outer cap directly to P, or clipping the final answer to the damping boundary, would produce a different calculation.
These examples use symmetric limits. Preserve both live boundaries separately; do not infer a lower limit by negating an upper limit unless the applicable specification establishes that relationship.
For an assumed 50,000 USDT position value, a +0.30% final rate gives 50,000 × 0.003 = 150 USDT. Under the positive-rate convention documented by Binance, longs pay shorts; a negative rate reverses that direction. The last row would therefore imply a 150 USDT receipt for the hypothetical long, assuming it participates in that event. Binance's funding payment rules define this sign convention.
The rate applies to the relevant position value, not automatically to posted collateral. For the broader cash-flow calculation, use the perpetual funding-cost ledger. If order size is expressed in contracts, first resolve the contract multiplier and position units; multiplying a raw contract count by a quote-currency rate can conceal a unit error.
Compare rates over the same horizon
A rate needs an interval. Consider three deliberately simplified scenarios over a full 24 hours. Each assumes constant 50,000 USDT exposure, participation in every event, unchanged rates and no reinvestment or compounding.
| Hypothetical schedule | Rate per event | Events in 24 hours | Payment per event | Total paid by the long |
|---|---|---|---|---|
| Every eight hours | +0.30% | 3 | 150 USDT | 450 USDT |
| Every hour | +0.30% | 24 | 150 USDT | 3,600 USDT |
| Every hour | +0.0375% | 24 | 18.75 USDT | 450 USDT |
The second row has the same displayed percentage as the first but eight times as many assumed payments. The third has one-eighth the event rate, making its simple daily sum equal to the first. Those equal sums require the stated assumptions; an interval change does not establish that the rate will divide proportionally.
For varying position values and rates, calculate sum(position value at event × final event rate as a decimal) with a declared payment-sign convention. Do not multiply the first observed rate by a guessed event count. Even equal daily totals can have different margin consequences because payments occur at different times.
A daily or annualized display is a normalization, not evidence that one event's rate will persist. Comparing perpetual funding with a dated contract also requires different accounting: the futures expiry and roll-cost guide traces the exposure transfer and two-leg execution costs involved in replacing an expiring contract.
Treat limit changes as changes to the model
Bybit says it can temporarily adjust funding limits during volatility. Its current methodology also describes an automatic switch to hourly settlement when funding reaches a preset boundary at settlement, with dynamic updates that may occur without separate announcements. Bybit's limit and frequency rules make an old specification an unsafe substitute for a current one.
For USDⓈ-M perpetuals, Binance likewise documents a change from eight- or four-hour settlement to hourly settlement when the previous settled rate reaches a cap or floor. Its example distinguishes touching a boundary before settlement from actually settling at that boundary. Binance's interval-adjustment rules explain that trigger.
Here is a separate fictional timeline showing why both parameters belong in the record:
- At 08:00 UTC, a contract settles at +0.30% under an eight-hour schedule. The assumed long pays 150 USDT.
- At 08:10, a new specification is observed: the upper limit is +0.50%, and the next event is 09:00. Assume those rules govern the upcoming events.
- At 09:00, the final rate is +0.40%; unchanged 50,000 USDT exposure produces a 200 USDT payment.
- At 10:00, the final rate is +0.10%, producing another 50 USDT payment.
Payments in this timeline total 400 USDT. A model frozen to the first schedule would record 150 USDT and expect no further event until 16:00, omitting 250 USDT. A model that refreshed the schedule but retained the old cap would also reject the valid assumed +0.40% rate.
These are invented transitions, not a claim about a particular live contract. They illustrate why a current cap does not establish the historical cap, and why a cap observed now does not promise the same boundary throughout a future holding period.
Keep a usable parameter receipt
Retain the raw response, venue, product, symbol, retrieval time, lower limit, upper limit, interval and next event time. Record an effective time when the source supplies one. Otherwise label the value as first observed at that time; retrieval alone cannot establish exactly when a rule changed.
Bybit's instrument endpoint exposes upperFundingRate, lowerFundingRate and fundingInterval, with the interval in minutes. Its ticker separately supplies fundingRate, nextFundingTime in milliseconds and fundingIntervalHour in hours. Normalize those units before comparing records. The instrument specification fields and ticker fields document their respective meanings.
Binance's GET /fapi/v1/fundingInfo returns adjusted cap, floor and interval information for symbols that have had such adjustments. An absent symbol is therefore not evidence of a zero cap or zero funding. Resolve the applicable baseline specification separately. Binance's funding-info endpoint states that scope.
Before accepting a cost estimate, validate three things: the final rate lies between the applicable boundaries; the calculation uses the correct interval and scaling; and the event calendar reflects the latest observed schedule. Archive the parameters alongside the estimate so another reviewer can reproduce it. The separate predicted-versus-realized funding guide addresses later rate revisions and booked payments.
For your next review, write down one complete tuple: contract, lower limit, upper limit, interval, next event and observation time. Then calculate the cash cost under the current schedule and an explicitly changed schedule. That gives the cap its proper meaning: a conditional boundary on one event's rate, within a holding-cost calculation that still needs time and position value.