Predicted crypto funding is a provisional rate for a specified upcoming funding event; realized funding is the rate settled for that event or the cash payment actually booked to an account. Those last two records are different evidence. An estimate can revise before settlement, and a settled public rate does not establish your account's payment without its position and transaction records.
This article was prepared with AI assistance. The revision tape and cash amounts below are hypothetical teaching examples, not observed exchange rates, a funding forecast or a trading recommendation.
Give each funding number a status
A screen showing “funding” may answer a different question from a history export showing the same word. Before comparing values, classify the record:
| Record | Question it answers | Evidence to retain |
|---|---|---|
| Current estimate | What rate is indicated now for a named future event? | Observation time, target event time, venue, contract, interval and raw field |
| Settled public rate | What rate was recorded for that completed event? | Instrument, event timestamp, final rate and retrieval time |
| Account funding entry | What funding cash amount was booked to this account? | Account, transaction ID, currency, amount, sign convention and transaction time |
“Realized funding” can mean either of the last two rows. Label the output explicitly as a settled rate or a booked cash amount. A percentage and a currency amount should never occupy one undifferentiated column.
Funding also differs from expiry settlement and unrealized valuation. The futures settlement and mark-to-market guide explains those separate events. Here, the task is to preserve revisions and their evidence, rather than rebuild the general funding-cost ledger.
Why the estimate can change
Bybit's perpetual funding methodology says the displayed rate changes until the upcoming funding timestamp and is updated every minute. Its calculation incorporates the interest component and a weighted premium history; later premium observations receive greater weight in its illustrated interval. Bybit's introduction to funding rates documents that venue-specific process.
An early observation therefore need not equal the final rate. It was recorded before the calculation window finished. Calling every revision a data failure would confuse a provisional measurement with an immutable result.
Nor should “predicted” automatically be read as a statistically calibrated forecast with a confidence interval. Establish what that label means for the particular venue and field. Some interfaces describe a current calculation for the next event; an analyst's forecast of later events is a separate model with its own assumptions.
Bybit's ticker API, for example, supplies fundingRate and nextFundingTime, alongside instrument-specific interval information. Retain the target time rather than inferring it from the word “current.” Bybit's ticker field definitions also distinguish those fields from delivery-related values.
A revision tape for one event
Assume a fictional USDT-linear perpetual has a funding event at 08:00 UTC. A long position has a constant 10,000 USDT event value throughout this worksheet and is eligible for the payment. The interval and eligibility are assumptions, not general exchange rules.
For this example only, a positive cash cost means the long pays; a negative cost means it receives. Each provisional cash amount answers: “What would this event cost if this observed rate became final and the assumed value stayed unchanged?”
| Observed at, UTC | Target event | Record status | Rate | Conditional long cash cost |
|---|---|---|---|---|
| 04:00 | 08:00 | Provisional estimate | +0.012% | +1.20 USDT |
| 06:00 | 08:00 | Revised estimate | +0.018% | +1.80 USDT |
| 07:55 | 08:00 | Revised estimate | −0.002% | −0.20 USDT |
| After 08:00 | 08:00 | Settled public rate | −0.004% | −0.40 USDT |
The first estimate implied paying 1.20 USDT; the final rate implies receiving 0.40 USDT under the fixed assumptions. The cash-cost difference is −0.40 − 1.20 = −1.60 USDT. The rate changed by −0.004% − 0.012% = −0.016 percentage points, or −1.6 basis points. It did not change by merely −0.016% of the first estimate.
Suppose the account later records a 0.40 USDT funding credit. That supports the payment outcome for this invented account, while the public rate supports the event rate. Neither record proves that 04:00 displayed −0.004%. Keeping the old snapshot makes that distinction auditable.
Do not add all four conditional cash amounts. They are revisions of one event, not four separate charges. This is a practical failure mode when a monitor samples funding repeatedly and incorrectly sums every sample into “accrued costs.”
Match the event before measuring the revision
A numeric difference is meaningful only if both observations refer to the same venue, product and event. At a boundary, a latest-value endpoint may already describe the next event while the history endpoint describes the one that just settled. Subtracting those values creates a false revision.
Bybit's historical funding endpoint returns a rate and fundingRateTimestamp for completed events. Its documentation gives the example that, at 12:00 UTC for an eight-hour instrument, the latest returned rate settled at 08:00 UTC. Bybit's funding-rate history documentation makes that timing explicit.
Join the provisional snapshot's target event to the historical event timestamp, with venue and instrument identity included. Preserve the response retrieval time separately. A response fetched at 08:03 is not evidence that its contents were available at 07:55. The market-data freshness guide explains why observation age and local receipt time need separate treatment.
If the interval changes, do not manufacture a missing event from an old calendar. Keep the newly observed schedule and flag the comparison for review. Likewise, an unavailable history row is missing evidence, not proof of a zero rate.
Compare the payment using the field's own sign
An account export can use a different sign from the rate or from a worksheet's “cost” column. Bybit's Unified Account transaction log defines positive funding as receipt and negative funding as payment. It separately defines trading fees and other cash flow, and warns that data delivery may be delayed during extreme volatility. Bybit's transaction-log documentation is the relevant field reference.
The example's −0.40 USDT cash cost would consequently correspond to a +0.40 USDT funding receipt in that documented field convention. Reversing the sign twice would turn a receipt into a reported charge. Preserve the raw amount before normalizing it for a report.
If the booked amount differs from the worksheet, rate revision is only one possible explanation. Position value, contract units, settlement currency or eligibility may differ. Investigate those inputs using the funding timestamp and position-snapshot guide; do not edit the archived estimate to force reconciliation.
A compact evidence worksheet
Use this checklist for a disputed estimate or a funding-aware historical study:
- Identify the venue, exact contract and settlement asset.
- Save the estimate with both observation time and target event time.
- Preserve revisions as separate rows with the same event key.
- Retrieve the settled public rate and match its event timestamp.
- Retrieve the account funding entry, preserving its ID and raw sign.
- Explain any remaining difference with position evidence or mark it unresolved.
For historical decisions, use only observations available when that decision occurred. Replacing every archived estimate with the later settled rate would give the decision knowledge it did not have. The look-ahead bias guide describes that wider timing problem. Settled rates can be appropriate for modeling actual later funding costs; they cannot silently become earlier signal inputs.
This worksheet does not establish the accuracy of any forecasting strategy, and the venue examples do not establish a KLINEO funding-forecast feature. Its purpose is narrower: make clear what was estimated, what eventually settled and what the account actually received or paid.