Methodology: how the numbers on this site are made

Contents

1. The formulas
2. Venues and sources
3. Interval handling
4. Spread and Spread APR
5. What gets filtered
6. Refresh and stale data
7. Rolling history
8. Symbol mapping
9. Traditional-asset perps
10. LP pool versus routed markets
11. Known limitations

The formulas

Sign convention throughout: a positive rate means longs pay shorts, a negative rate means shorts pay longs. Rates are stored as decimals (0.0001 is 0.01%) and shown as percentages with four decimals.

1. Hourly rate = rate per interval ÷ interval hours.
2. 8h rate = hourly rate × 8.
3. APR = hourly rate × 24 × 365, which is the same as 8h rate × 3 × 365 (a factor of 1,095 on the 8h rate). It is simple annualisation: no compounding, and it assumes the rate never changes.

Illustrative inputs, not market data: 0.0100% per 8h gives 0.00125% per hour and 10.95% APR. A 4-hour venue quoting 0.0020% per interval gives 0.0005% per hour, 0.0040% per 8h and 4.38% APR.

Venues and sources

Fourteen sources feed the tables, listed below by the label that appears in the Venue column. All except the pool are plain HTTPS calls to the venue's public endpoint; the pool is read from the chain. No API keys or accounts are involved.

Each source is fetched with an 8-second timeout. One slow or failing venue never blocks the others.

Interval handling

Venues settle funding every 1h, 4h or 8h (some per contract, some continuously). We take the interval from the venue's own data where it provides one and fall back to the default shown in the table above where it does not. The page then shows three things side by side: the rate per interval as the venue quotes it, the interval itself, and the normalised 1h, 8h and APR values.

Two consequences are worth knowing. First, an 8h-equivalent figure for a 1h venue is a projection of the current hourly rate, not what a trader would pay over the next eight hours. Second, venues that settle continuously (GMX, Paradex, the LeverUp pool) are shown with their hourly equivalent, and "next funding" is blank for them.

Spread and Spread APR

For one asset, Spread (8h) = the highest 8h rate across venues minus the lowest 8h rate. Spread APR = Spread (8h) × 1,095. On the home page and the arbitrage scanner the table lists assets that appear on at least 4 venues, widest spread first, and skips closed markets and GMX. Both apply the liquidity screen described under What gets filtered unless the scanner is opened with ?all=1.

Illustrative inputs: venue A at +0.0100% and venue B at −0.0050% per 8h give a spread of 0.0150% per 8h, or 16.43% Spread APR. That is the gap between two quotes, not a return: it ignores trading fees, the price difference between the two contracts, margin on both legs, liquidation risk and rates that change before payment.

Coin pages use a slightly different base: one value per venue (the median of that venue's rows for the coin), with the median across venues as the headline figure. Their statistics also leave out GMX and LeverUp markets that are routed to Hyperliquid, which would otherwise count Hyperliquid twice. If every remaining market is closed, the last known rates are used and the page says so.

What gets filtered

• Multi-venue crypto only. A crypto asset is kept in the snapshot only when it appears on at least two venues (LeverUp rows are always kept). Single-venue long-tail listings do not appear. Gold, FX, index, stock and pre-IPO markets are kept regardless.
• Home page subset. The default home table shows the 25 assets with the most venues, plus LeverUp pool assets, capped at 220 rows. Filters in the page (class, venue, asset) show the full set for that slice and are marked noindex.
• Coin pages. Each of the curated coin pages needs at least 3 venues in the latest snapshot. With fewer, the page still renders but is marked noindex and dropped from the sitemap until coverage recovers.
• Liquidity screen (default spread views). The home teaser and the arbitrage scanner compare only legs that look liquid, because the widest funding gaps are usually on thin coins. Open interest in USD is read from the feeds already fetched for three venues: Hyperliquid (open interest in coins × mark price), Bybit (its USD open-interest value) and dYdX (open interest in coins × oracle price). A leg on one of those venues counts when the asset's open interest there is at least $1,000,000. Binance, OKX, Aster, Lighter, edgeX, Paradex and LeverUp markets report no open interest in the feeds used here; their leg counts if the asset is one of the curated coins or is listed on 6+ venues, and no venue that does report open interest shows it below the floor. The row then shows the widest gap between qualifying legs, which can be narrower than the all-venue spread on the coin page. Open interest is a rough proxy: it is not order book depth, and the threshold is a judgement call. ?all=1 on the scanner turns the screen off and lowers nothing else; the page's canonical URL stays the base scanner URL.
• Delisted and disabled markets are skipped by every source that exposes the flag.

Refresh and stale data

A scheduled job rebuilds the snapshot every 10 minutes. The time on each page ("Last updated" in the footer, or the "as of" time next to a statistic) is the time that snapshot was generated, in UTC, not the time the venue last changed its rate. Rendered pages are cached for a few minutes, so a page can lag the snapshot slightly.

When a venue fails in a run, its rows from the previous snapshot are carried forward and tagged stale with the time of its last good fetch (the grey "stale · HH:MM UTC" badge). Carried rows are kept for at most 6 hours since the last good fetch; after that the venue is shown as unavailable and contributes nothing. The status line at the top of the home page counts venues updated in the latest run, so "12/14" means two venues are stale or down. Stale rows are still included in statistics while they are shown, so a stale badge next to a rate means that rate may be out of date.

Rolling history

For the curated coins only, the run that happens in the first ten minutes of each UTC hour stores one summary point: venue count, cross-venue median 8h rate, lowest and highest venue 8h rate. At most 168 points (7 days) are kept; older points are dropped. Hours when the market is closed are skipped. Coin pages show 24h and 7d windows from these points. Averages of hourly medians are not time-weighted by venue interval, and a window shows fewer samples than hours whenever collection started recently or a run was missed; the page states the sample count.

Symbol mapping

Venue symbols are cleaned (quote suffixes such as USDT or -PERP removed, prefixes dropped) and mapped to one canonical asset so rows line up. Contracts quoted in thousands (k-prefix, 1000×) map to the base coin; rates are percentages, so the contract multiplier does not change them. Aliases such as XAU, XAUT and PAXG map to GOLD (tokenised gold is noted in the row), and US500, SPX500 and SP500 map to SP500.

SPX versus SP500. On crypto perp venues a bare "SPX" is normally the SPX6900 memecoin. We treat a bare SPX as the S&P 500 index only when its mark price is above 1,000; otherwise it becomes SPX6900. The index itself is matched by the SP500 / US500 / SPX500 names. This is a heuristic on price, so a mislabelled row would be mapped wrongly.

Traditional-asset perps (gold, FX, indices, stocks)

Hyperliquid lists these through HIP-3, where independent builders deploy their own dexes (here "xyz" and "mkts"). Funding is computed hourly like core perps, but the underlying market is only open during traditional hours. Where a venue gives no open flag we label rows closed from Friday 21:00 UTC to Sunday 22:00 UTC. That is a weekly approximation: it ignores exchange holidays, early closes and the daily break in some markets. Pre-IPO markets are treated as always open. Closed-market rows are kept in tables but excluded from spreads and, unless nothing else is open, from coin statistics. Prices, funding and index definitions differ between builders and venues, so the same canonical name does not guarantee an identical underlying.

LP pool versus routed markets

LeverUp appears twice in the tables. The plain LeverUp rows are markets routed to Hyperliquid HIP-3: the funding shown is Hyperliquid's, so those rows carry no independent signal and are left out of spreads and coin statistics. The "LeverUp (pool)" rows are on-chain pool markets that do have their own pricing: a funding rate (per-second value × 3,600 for the hourly figure) plus a separate holding fee for each side. In the pool rows the long cost is funding plus the long holding fee and the short cost is the short holding fee minus funding, so the two sides pay different amounts. The headline 1h, 8h and APR columns for a pool row show the funding part only; the L / S column shows the per-side totals.

The calculator has separate modes for these cases.

Known limitations

• Rates are what each venue publishes at fetch time. Predicted, last-settled and current-premium values are not always the same thing across venues, and we do not reconcile them.
• GMX funding is set by the imbalance between long and short open interest in each pool and is quoted with a separate borrowing fee, so it is listed per pool but not mixed into spreads or coin statistics (see the venue table for the unit conversion).
• As a sanity guard, any row whose 8h-equivalent rate is above 3% in either direction is treated as bad data and left out of every table, the heatmap, the scanner and the JSON feed. The per-venue count is in the status endpoint.
• Normalising to 1h or 8h makes venues comparable; it does not make them equivalent. Settlement timing, caps, and index methodology differ.
• Binance and Bybit can come from the Hyperliquid predictedFundings feed instead of their own APIs when a direct call fails; the row's source note says when that happened.
• The market-hours rule is an approximation and the SPX mapping is a price heuristic.
• Data may be delayed, stale or wrong. Nothing here is financial advice.

The raw snapshot is available as JSON; its rate_1h, rate_8h and apr fields are decimals computed as above.