---
schema: 1
kind: prose_mirror
lang: en
canonical: https://funding-radar.com/en/methodology
---

# Methodology: where the numbers come from

All radar data comes from the public APIs of five exchanges: Binance, Bybit, OKX, Bitget, Hyperliquid. Polling runs every 2–5 minutes across ~2,700 perpetual pairs. Everything shown on the site is computed by the formulas on this page; every formula has a test, and the data has automated checks — including reconciliation against the exchanges that bypasses our own connectors. Below is the digest: definitions, thresholds, and how the trust loop works.

## Units and normalization

- **Funding rate** — Internally the rate is always stored as a fraction per settlement interval: −0.02 means −2% per interval. Pages print it as a percentage, and machine surfaces (the JSON feed, .md mirrors) name the units explicitly — percent_per_interval next to fraction_per_interval — so a program reading both cannot be off by 100×.
- **Hourly rate** — hourly = rate ÷ (interval in hours). The only scale on which exchanges are comparable: −0.8% per 8h and −0.4% per 4h are the same −0.1%/h. Intervals are dynamic (1–8 hours), taken from the exchange per pair, never hardcoded: exchanges move heated pairs to shorter intervals mid-event.
- **Sign and side** — A positive rate means longs pay shorts; negative — shorts pay longs. Views always spell out the receiving side in words (“longs receive”) instead of leaving the reader to guess from the sign.
- **A prediction, not a fact** — The displayed rate is a prediction for the next settlement; the exchange keeps recomputing it until the charge (measured: about 0.003 pp per minute on hot pairs). The charged rate is a separate entity: it goes into history and is reconciled against the exchange after the fact.

## Events: what the radar calls extreme

- **Event threshold** — An event opens when |hourly rate| ≥ 0.1% with pair volume above $300K/day. It closes when the rate falls below 0.05%/h — hysteresis, so the event does not flap at the threshold. The event's peak is the maximum |hourly rate| over its lifetime.
- **Settlement calendar** — The next 4 hours, pairs with |rate/h| ≥ 0.05% and volume above $1M. Each row carries the statistics of that pair's own past settlement windows: the average price move before the charge and the number of measurements — the scale of risk sits right next to the yield.

## The economics the calculator computes

- **Settlement snipe** — Net capture = |rate per interval| − entry/exit fees (2 × 0.055%) − slippage buffer (0.05%). Fees are typical taker rates; set your own in the account settings and the calculator uses them.
- **Hedged pair** — The pair's income is the hourly-rate spread between exchanges; the cost is four legs of fees (two positions × entry and exit). The headline number is breakeven: how many hours the spread needs to repay the entry. Next to it, the spread's “lifetime” — how long it has held above the repay-within-a-day threshold: a one-off spike and a sustained divergence are different things.
- **Assumptions next to the numbers** — Every computed number carries its assumptions where it is printed: fees are from settings, not “yours”; the liquidation point ignores margin tiers; slippage is a buffer, not a forecast. A number without a denominator and assumptions is an impression, not a fact.

## Settlement window: facts, not opinions

- **Captures** — For every settlement of an event pair, the price path is recorded in ±5 and ±15 minute windows around the charge (from 1-minute closes). The five-minute window is more honest for a snipe — the fifteen-minute figure overstates its risk almost twofold; the wide window is kept because on some pairs the post-settlement reversal only completes by minute 15.
- **With the denominator** — Window statistics are printed with the number of measurements: “±2.1% on average across 12 captures”, never a bare percentage. Fewer than three captures — the view shows a dash, not statistics built on two points.

## Orderbook walls and their history

- **What counts as a wall** — The book is bucketed by 0.1% of distance from price; a wall is a bucket holding ≥ 5× the median bucket volume and at least $5,000, within 0.15–10% of price (closer executes instantly, farther does not matter). The level's price is the bucket VWAP.
- **Break-through history** — A level is “tested” if price reached it, and “broken” if 15 minutes later the close was on the other side. It is printed as “broke through N of M times” — with the denominator: at M < 5 that is coincidence, not statistics. Consecutive touches merge into one episode so a single approach does not inflate the denominator.
- **Distance from the current price** — The database stores the price at snapshot time, and the distance to a level is always recomputed from the current price on read: stored percentages go stale as the market moves.

## Open interest: coins, not dollars

Skew dynamics are computed in coins (OI in USD ÷ the price from the same snapshot): the dollar curve grows from price movement alone, and on a live event that produced the verdict “skew building” while positions had actually shrunk by a few percent. The phases “building / holding / unwinding” use a ±3% threshold over the last hour; the squeeze flag — price moving ≥1% against the paying side over the same window.

## How the data is verified

The checks are not promises but running scripts with reproducible results. Three layers, from code to the primary source:

- **Formula tests** — Every formula in our internal calculations document has a test, including a scenario run of the whole data-collection lifecycle on real tick-processing code. Code diverging from the document is a bug in one of the two.
- **Live-database invariants** — verify:data — 30+ invariants of the production database on every deploy: OHLC consistency, positive prices and volumes, snapshot freshness, orderbook side consistent with price, liquidation-sum plausibility, derived settlement intervals matching what the exchange declares (97%+ of live pairs).
- **Reconciliation with the source** — Settlement history stores the rate the exchange actually charged, not our prediction: a nightly reconciliation at 03:00 UTC pulls history across all five exchanges, and verify:history reports zero discrepancies. Weekly, a separate script checks a stratified random sample of live values against the exchanges bypassing our connectors: intervals, settlement times, rates, prices, OI, volumes (August 2026 run — 198 values, 0 discrepancies).
- **Why reconciliation, not just invariants** — In-house invariants stay green exactly until a number diverges from the outside world: three unit errors in liquidation notionals in August 2026 were caught by exchange reconciliation — all three had passed the invariants. After every fix a new invariant is added; reconciliation remains the judge.

## Machine access to the same data

- **JSON feed** — /api/radar — active events and the top pairs: units are named in the response, timestamps in ISO and milliseconds, percentages next to fractions, 30-second cache.
- **.md mirrors** — Every pair and coin card is available as Markdown at the same URL with an .md suffix (e.g. /en/coin/BTC.md): the same live numbers in a kilobyte of text, with a machine header — observation time, age and units. The index lives at /llms.txt.
- **MCP server** — Live data inside your AI assistant: six read-only tools, free and keyless — setup is described on the “Radar in your AI” page.

## Limitations — honestly

- The displayed rate is a prediction; the charged value may differ. History is reconciled with the exchange; a prediction has nothing to be checked against until it is charged.
- Fees and slippage in the calculations are typical; your tier differs — set yours in the settings.
- The liquidation point is simplified (no maintenance-margin tiers) — the real one can be closer.
- Data is cached for up to 30 seconds; when an exchange API fails, the views show the age of the data honestly instead of hiding it.
- Not investment advice: the radar makes the price of a decision visible; the decision stays yours.

## FAQ

- **Where does Funding Radar get its data?** — From the public APIs of Binance, Bybit, OKX, Bitget and Hyperliquid, polled every 2–5 minutes across ~2,700 pairs. The service uses no API keys and has no access to anyone's accounts.
- **Why does the rate on the radar differ from the exchange?** — The displayed rate is a prediction for the next settlement; the exchange recomputes it continuously, and the radar's cache lives up to 30 seconds. Charged rates in history are reconciled against the exchange nightly — with zero discrepancies.
- **How can I verify the data is trustworthy?** — The checks are reproducible: history stores what the exchange actually charged and is reconciled nightly against the source, a weekly sample of live values is checked against the exchanges bypassing the radar's own connectors, and database invariants run on every deploy. Statistics are always printed with their denominator.
- **Can I use the radar's data in my own bots or assistants?** — Yes: the open /api/radar JSON feed, Markdown mirrors of the cards (.md at the same URL) and a free anonymous MCP server for AI assistants. Terms are in the “Programmatic access” section of the legal page: reasonable use and a reference to the source.

Live page: https://funding-radar.com/en/methodology
Methodology & data verification: https://funding-radar.com/en/methodology