Funding methodology

Version 4 starts with the first sweep after the September 25, 2026, release. Version 4 makes each predicted row point at the next settlement after the observation time. Hyperliquid reports the start of the running hour as its next funding time. That settlement has already occurred. Versions 1 to 3 stored that time, so each stored Hyperliquid prediction pointed 7 to 53 minutes into the past. Version 4 adds one funding interval to that time. Version 4 did not change a rate, an interval, or an aggregate.

Version 3 starts with the first sweep after the September 23, 2026, release. The strict version 3 history API reports that first sweep as its dataset start. Version 2 began September 12, 2026, at 08:52:28.326 UTC, according to persisted first-sweep metadata. The original version 1 collection began July 16, 2026, at 11:09:08.181 UTC.

Version 3 reads the funding interval of each market from the venue feed. Many venues list 1-hour, 4-hour, and 8-hour markets side by side. Before version 3, the aggregate feed divided Aster, BingX, HTX, Phemex, Orderly, and BloFin rates by 8 for every market. That made each 1-hour market 8 times too low and each 4-hour market 2 times too low. The aggregate feed also divided the hourly Hibachi rate by 8.

BTC and ETH settle every 8 hours on those venues, so stored BTC and ETH hourly rates did not change. Version 2 Aster rows keep a raw rate and raw interval that the collector calculated with a wrong 1-hour value. Version 2 Crypto.com rows keep a raw rate calculated with a wrong 8-hour value. PerpFinder does not edit stored rows.

The overview, the history charts, the arbitrage spread history, and the default history API show one joined series. The joined series uses version 2 sweeps up to the first version 3 sweep. It then uses version 3 sweeps up to the first version 4 sweep, and version 4 sweeps after it. The hourly rates and the aggregates continue across each join. If two versions stored the same 15-minute sweep, the joined series uses the newer version. Version 2 and version 3 Hyperliquid predicted rows keep the stored next settlement time. On version 2 Aster and Crypto.com rows, the joined series shows the raw rate and the raw interval as empty. The API response gives methodologyVersions: [2, 3, 4], the join note, and the excluded fields.

methodologyVersion=4 selects version 4 sweeps only.methodologyVersion=1, methodologyVersion=2, and methodologyVersion=3 select one earlier stored series, with the stored values unchanged. The history page links each version and its coverage fields.

• Current: the rate for the running interval, according to the source mapping. It can change before settlement.
• Predicted: a separate venue forecast for a future settlement. The forecast can change.
• Realized: a venue settlement record with its settlement timestamp and reported rate.

These rate types are never mixed in current-rate aggregates or pair spreads. In the overview, normalized columns use a predicted row if the current row is absent. The current and predicted columns show the available source types.

A check mark identifies a configured capability in PerpFinder's collector. It does not establish availability in every observation or prove that the adapter reads each interval directly. Venue links open primary API references or responses.

OKX's configured source mapping has no separate predicted rate. Kraken's direct adapter divides its absolute funding amount by mark price to obtain a relative rate. Gate's documentation marks funding_rate_indicative as deprecated; the collector still reads this legacy field when present.

• Binance direct BTC/ETH adapters read fundingIntervalHours from fundingInfo. Bybit direct adapters read fundingIntervalHour. If the field is missing, the current row uses a labeled 480-minute assumption and realized rows get no normalized rate.
• Kraken and dYdX direct adapters use a fixed 60-minute period. Their source labels also say venue-reported.
• OKX direct current rows derive minutes from funding timestamps. Missing or invalid timestamps trigger a labeled 480-minute assumption. Realized rows then get no normalized rate.
• Gate reads funding_interval in seconds and converts it to minutes. If the field is missing, the current row uses a labeled 480-minute assumption.
• Hyperliquid predicted rows read fundingIntervalHours, with a one-hour fallback. Current rows can use the aggregate feed's assumed period.
• MEXC aggregate rows use collectCycle. The MEXC funding API describes that field.
• Aggregate rows from Binance, Bybit, OKX, Bitget, MEXC, Gate, BingX, KuCoin, Phemex, HTX, BloFin, Orderly, and Aster keep the reported raw rate and the reported interval of each market. A market without a reported interval gets no rate.
• If only the interval request of a venue fails, a market uses the interval that the venue reported for it in the last 24 hours. The row shows last-known and the age of that interval. After 24 hours, the market gets no rate.
• Other aggregate rows use the documented venue schedule. The collector calculates their raw period rate from that schedule and labels the row as an assumption.

An asterisk therefore identifies an explicit stored assumption, but its absence does not prove direct interval verification. Raw realized rates remain available for settlement analysis; normalized historical rates can also use fixed schedule assumptions.

Rates in storage use fractions: 0.0001 means 0.01%. Hourly rate = raw rate × 60 ÷ interval minutes. Eight-hour rate = hourly rate × 8. A null or invalid interval produces no normalized value.

Hypothetical example: a raw rate of 0.0008 over 480 minutes equals 0.08% per eight-hour interval. Its hourly rate is 0.0001, or 0.01%. Annualized extrapolation is 0.0001 × 24 × 365 = 0.876, or 87.6%.

On an assumed constant $10,000 notional position, that interval rate corresponds to an $8 funding payment. This example excludes trading costs and assumes the rate holds through settlement. Annualized figures compare rates on one scale; they do not forecast yearly income or compound returns.

The collection target is one sweep every 15 minutes, or 96 sweeps per asset per complete UTC day. A sweep contains source responses from one collection run; their individual timestamps can differ. A missed run leaves a coverage gap.

• At sweep level, sourceTimestamp records collection start. ingestedAt records the stored aggregate's ingestion time.
• At row level, sourceTimestamp can be venue time, aggregate-feed time, or the collector's fallback time.
• intervalStart identifies the 15-minute bucket. It can precede the collection timestamp.
• Realized records use the venue settlement timestamp. Collection imports real settlement-history windows of up to 30 days.
• Imported settlements can predate collection. PerpFinder does not present their event time as its own observation time.
• Prediction matching uses the last stored prediction before the same settlement and records its lead time.
• The prediction accuracy page compares predictions and settlements in one shared period for each venue and asset.
• For version 1 to 3 Hyperliquid predictions, the accuracy ledger adds one hour to the stored next settlement time. The ledger labels each corrected pair. It applies the correction only when the stored time is on the hour and less than one hour before the observation.

Funding sweeps have no synthetic backfill. Imported settlement records come from venue history endpoints. The history API reports returned counts, coverage, and dates separately for sweeps and settlements. Those fields do not establish complete coverage outside the returned period.

• The validator rejects nonfinite rates, rates above 5% in absolute value per period, and timestamps over five minutes in the future.
• Rows older than 30 minutes at ingestion carry a stale status. Some current-rate aggregates can retain stale rows.
• Missing rates or intervals can prevent a comparison. Zero is a valid reported rate and must differ from a missing value.
• Numeric conversions in direct adapters can turn an empty rate string into zero. A zero alone cannot prove that the source published zero.

Pair tables require at least $1 million of reported open interest on each side. This filter does not measure order-book capacity or fill quality. Published spreads are gross, with net results labeled incomplete while costs remain unmeasured.

Funding strategies are not risk-free. Rates can change, one position can liquidate, and venue failures can affect one account. Net results require entry and exit fees, spread, slippage, borrowing costs, and the actual funding path.

Report data or content errors through the correction policy.PerpFinder data operates the funding collection process, with review by PerpFinder review.