Disclosure: This is an AI-assisted engineering note. I operate an optional paid x402 market-data endpoint mentioned near the end. Nothing in the free code trades, accesses a wallet, or claims an investment return.
A funding-rate dashboard can show four numbers for BTC/USDT perpetual futures, all with the same percent sign, even when they refer to different settlement periods, observation times, and contract conventions.
That is a software data-integrity problem, not a trading signal. I made a small, offline Python checker with 20 tests to demonstrate why the metadata matters.
Four quotes, four clocks
For perpetual futures, a funding rate describes a transfer between opposing long and short positions at a specified funding time. It is not a savings yield, and its sign does not tell you what any particular user will earn without knowing their position and the venue rules.
The exchanges expose different pieces of that information:
-
Binance describes a default eight-hour settlement schedule, but its funding documentation explicitly allows changes to the funding interval. The USD-M funding info API reports
fundingIntervalHoursfor adjusted symbols. -
Bybit exposes
fundingIntervalin minutes in its V5 instrument metadata. Don't silently treat that field as hours. -
OKX's public funding-rate endpoint reports the funding time and the next funding time. Its instrument identifiers, such as
BTC-USDT-SWAP, aren't identical to every other venue's symbol format. -
Bitget's current funding-rate endpoint documents
fundingRateIntervalin hours, with supported values including 1, 2, 4 and 8.
The settlement period for a specific contract can change. You must inspect the actual venue and instrument rather than assume every BTC/USDT perpetual follows an eight-hour clock.
An illustration with completely invented numbers
I deliberately chose fake observations to make the arithmetic visible. This table is not today's BTC/USDT market data, not an estimate of a real spread, and not a price prediction.
| Example venue | Fake quoted rate | Hypothetical settlement period | Basis points per settlement | Simple 24-hour illustration |
|---|---|---|---|---|
| Binance | +0.0100% | 8 hours | +1.0000 bp | +3.0000 bp |
| Bybit | +0.0080% | 4 hours | +0.8000 bp | +4.8000 bp |
| OKX | -0.0020% | 8 hours | -0.2000 bp | -0.6000 bp |
| Bitget | +0.0025% | 1 hour | +0.2500 bp | +6.0000 bp |
One basis point is 0.01 percentage points. Given a decimal fraction r and interval h hours, the illustrative math is:
from decimal import Decimal
def settlement_bps(decimal_fraction: str) -> Decimal:
return Decimal(decimal_fraction) * 10_000
def simple_24h_bps(decimal_fraction: str, interval_hours: str) -> Decimal:
return settlement_bps(decimal_fraction) * 24 / Decimal(interval_hours)
print(simple_24h_bps("0.00008000", "4")) # 4.80000000 bp
The 24-hour column assumes the same hypothetical rate repeats for each interval without compounding or changing. It is not APY, backtested return, a funding arbitrage, or a net profit forecast. An hourly funding quote and an eight-hour quote cannot be ranked as if they were rates for the same period.
A 100% offline Python checker, with 20 tests
I published a tiny free Python 3 checker with its source and tests. It requires no wallet, uses Python's standard library only and accepts explicitly synthetic input, so it cannot be mistaken for a live market-data feed.
Clone the source and run:
python3 -B tools/btc-funding/funding_interval_compare.py \
--input tools/btc-funding/synthetic_funding_input.json \
--asof 2026-10-24T08:01:00Z
python3 -B -m unittest discover \
-s tools/btc-funding -p 'test_*.py' -q
The code rejects duplicate venues, a mismatched instrument, non-finite rates, invalid periods, non-UTC timestamps, or a next funding time preceding the observation. It flags observations older than 120 seconds relative to the supplied --asof timestamp. All 20 isolated tests passed on October 24, 2026.
This is intentionally less than a trading system. It does not fetch rates, access wallets, submit orders, decide whether to hedge, or tell you which position would receive funding.
What a useful paid data endpoint needs to prove
A rate alone is insufficient for a defensible comparison. At minimum, I'd want to inspect:
- Instrument identity: BTC/USDT versus coin-margined BTC/USD and the venue-specific contract identifier.
- Observation time: when the source actually reported it, not merely when my HTTP response arrived.
- Settlement interval and next time: including venue-specific changes and data freshness.
- Source completeness: four different successful venue observations, not four rows repeating the same stale fallback.
- Limitations: caps, margin and mark-price conventions, funding settlement rules, network outages, plus costs and risk outside the rate itself.
For an optional live read-only convenience product, the BTC/USDT four-exchange x402 API buyer guide explains source requirements, the free explicitly fictional sample, HTTP 402 price, and caveats. The price is 0.010000 native Circle USDC on Base per authorized GET. You can read the page, inspect the unsigned quote, and run the offline checker without paying or connecting a wallet.
For transparency, PayAPI Market funded one test purchase of that endpoint on October 24, 2026 (Base transfer). That verifies a real payment rail, not accuracy of future exchange data, organic repeat buyers, or profit after costs. The market-data API belongs to the same single beneficial owner as this post.
The small habit worth keeping
Before sorting perpetual funding-rate quotes, ask: "Per what interval, for which exact contract, observed when, and settling when?" If any part of that answer is missing, don't convert a quoted percentage into an implied yield.
I would rather return "not comparable" than produce a precise-looking number built on mismatched clocks.
Not financial advice. Leverage, liquidation, slippage, changing funding, fees and counterparty risk can dominate a simple basis-point calculation. Article and example code were AI-assisted and reviewed against official API documentation.
Top comments (0)