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
Over 500 unit tests; every formula in the internal MATH document has a test, including a scenario lifecycle of the worker on the 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: five 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.