Aligning funding rates across venues

Two schedules

A perpetual's funding rate is quoted per interval, and intervals differ by venue and sometimes by symbol. Before any comparison, each rate needs to be put on a common basis and assigned to the period it actually pays for.

Intervals also change over time. Between January and July 2026, Venue A moved 37 perpetuals from 8-hour to 4-hour funding at least once, and Venue C changed the interval on 22 symbols. Code that stores one interval per symbol will miscount payments for every one of them.

Data

Realized rates for Venues A, B and C cover January 1 to July 31, 2026 and come from each venue's public funding history. Hyperliquid realized and predicted rates come from our own capture. For the predicted rates on the other three venues we took a short measurement of their public streams from June 1 to July 12, 2026, from Tokyo, sampled once a second. That measurement was for this study only and is not part of any product. We label the venues by letter because the subject is method, not a comparison between exchanges. The worked examples below use BTC perpetuals.

Annualizing

A rate r paid every h hours annualizes, without compounding, to r × 8,760 / h. Hyperliquid's hourly rate is multiplied by 8,760 and an 8-hour rate by 1,095. An hourly rate of 0.00125% and an 8-hour rate of 0.01% are the same 10.95% a year.

The most common mistake we see is multiplying Hyperliquid's hourly rate by 1,095, as if it were 8-hourly, which understates it by a factor of eight. A close second is comparing raw per-interval rates side by side, which makes Hyperliquid funding look like an eighth of everyone else's.

Compounding matters less than people expect between venues and more than they expect against a simple rate. At these levels, hourly and 8-hourly compounding differ by under 0.01 points a year. Compounded and simple annualization differ by about 0.6 points at 10.95%. Either convention is fine as long as it is the same on both sides and stated.

Assigning a rate to its period

To compare Hyperliquid with an 8-hour venue for the interval that settles at time T, sum the eight Hyperliquid hourly payments whose settlement times fall in the half-open window from T − 8h (exclusive) to T (inclusive). Including the settlement at T − 8h and excluding the one at T shifts the window by one hour. The error looks harmless, and its effect is measured below.

Timestamps on funding records add a second trap. On Venue A, the settlement time recorded in the funding history can sit a few milliseconds after the hour; we saw offsets up to 9 ms. An as-of join that picks the last record at or before 08:00:00.000 will miss the record stamped 08:00:00.004 and return the one from 00:00, assigning the previous interval's rate to the current one. On an hourly grid this misassigns one row in eight, always at the boundary where the rate has just changed.

Predicted is not realized

Every venue publishes a predicted rate that updates through the interval and converges to the realized rate at settlement. The predicted rate is what a trader could see. The realized rate is what was paid. Using the realized rate to make a decision before settlement is lookahead, and using the predicted rate as the amount paid is a cost error.

PREDICTED VS REALIZED, VENUE A BTCFDC MEASUREMENT

Seven hours before settlement the Venue A prediction differs from the realized rate by 0.39 bp on average, against a typical realized rate near 1 bp per 8 hours. Most of the convergence happens in the last few minutes, as expected for a rate that depends on premiums still to be observed. Hyperliquid's hourly prediction converges faster in clock time because its interval is shorter. In 8-hour-equivalent terms its error is 0.19 bp thirty minutes out and 0.02 bp one minute out. A carry signal that reads the predicted rate several hours before settlement inherits the forecast error shown above, and its backtest should include it.

How large the spurious spread gets

We computed the BTC funding spread between Hyperliquid and Venue A for every 8-hour Venue A interval from January to July 2026, 636 intervals in all, first correctly and then with each error introduced on its own. Spreads are Hyperliquid minus Venue A, annualized.

Annualized percentage points, simple. Hyperliquid realized mean 10.9%, Venue A realized mean 9.0%.

The first three errors barely move the mean spread, which is why they survive review. What they change is dispersion. A backtest that trades whenever the spread exceeds 10 points sees 41 opportunities with correct alignment and more than twice that with a careless join. The additional intervals come from alignment alone, and none of them corresponds to a payment that actually happened.

What a spread does not account for

Even correctly aligned, a funding spread between Hyperliquid and Venue A is not a pure carry. Hyperliquid perpetuals are margined in USDC and Venue A's in USDT, so the two legs settle in different stablecoins. The venues compute premiums from different reference prices and apply different caps. Funding is only one part of the position's P&L, alongside basis moves, fees and margin costs, and none of those are modelled here.

How the funding table handles it

In our funding dataset, every settled rate carries the venue's native interval for that payment (interval_s), the settlement time of the period it pays for (ts_funding, so the period runs from ts_funding minus interval_s to ts_funding) and an hourly rate (rate_1h), so a join by period never depends on a record's timestamp. Predicted rates are stored as separate rows (kind = predicted) stamped with ts_capture, so a backtest can only see what was published at the time. Interval changes are recorded per payment, which keeps symbols that moved between 8-hour and 4-hour funding correct across the change. Column definitions are in the schema reference, and the dataset is described on the funding page.

Checklist

• Annualize with the venue's actual interval for each payment, and state whether the figure is simple or compounded.
• Match payments by the period they cover, using half-open windows that include the settlement at the end.
• Never as-of join funding records on their timestamps without checking the venue's offset from the hour.
• Use predicted rates for decisions and realized rates for P&L, and keep both on the clock at which they became known.

The examples here are BTC only. On smaller perpetuals, rates are more volatile, caps bind more often and interval changes are more frequent, so the same errors produce larger spurious spreads.