Crypto market data methodology

Observed data versus estimates

Observed data means an exchange event or market value was received from a connected public source. Derived data means TradingHub calculated a score, normalization, aggregation or distance from those inputs. Estimate is used when a calculator or fallback assumption models a value rather than reporting an exchange-confirmed result.

TradingHub should not silently replace an unavailable feed with zero because zero is a valid market value. Panels therefore expose connecting, stale, unavailable or reduced-coverage states when the application cannot support a live claim.

Normalization, freshness and fallback rules

Funding rates are stored with their venue-specific settlement interval and are normalized only when a comparison explicitly requests a daily or annualized figure. Open-interest contract quantities are converted to comparable notional values only when the contract multiplier and mark price are available. TradingHub does not present unlike units as if they were identical.

Live panels distinguish loading, live, stale and unavailable states. A cached observation may be shown as stale with its last update time; it is not relabeled as live. REST fallbacks are used only for supported public endpoints and never replace a real-time stream with invented events.

Liquidation terminology

The terminal’s liquidation activity is based on observed executed liquidations. Exchanges do not publish the exact future liquidation price of every open position. Any product that projects future liquidation clusters must estimate hidden leverage and entry distributions. TradingHub keeps that distinction explicit.

Liquidation Map · Model 1.9

The map combines public perpetual-futures candles, open interest, mark price, funding context and observed executed liquidations. The model always runs on a canonical 5-minute candle series; the selected candle timeframe changes chart display only and cannot move modeled liquidation levels. Positive OI changes are distributed across explicit 5×, 10×, 20×, 25×, 50× and 100× leverage cohorts and a bounded entry-price uncertainty range. Nearby modeled levels are consolidated into bounded price clusters without discarding their underlying exposure. The heat layer renders each cluster as a hard rectangular price band across discrete OI time buckets, using a fine stepped intensity scale with no Gaussian halo, bilinear interpolation or temporal cross-fade. This preserves clear price-level separation without adding positions or inventing history. Remaining modeled exposure is reduced when OI contracts, price crosses a modeled level or an observed liquidation occurs nearby.

The Fast, Balanced and Structural modes are separate parameterizations rather than renamed visual presets. They use 8-hour, 18-hour and 42-hour exposure half-lives, progressively wider bounded entry uncertainty, different trigger-distance penalties and forward evaluation horizons of 6, 12 and 24 hours. Every live trigger and pool now reports cross-horizon consensus by independently running the state engine for all three modes. The signal-threshold control removes low relative-intensity cells and excludes weak clusters from selection; it does not manufacture stronger exposure.

Binance and Bybit public historical OI are loaded progressively for the visible range. OKX public instrument-level historical OI is not claimed when unavailable; OKX history grows only from snapshots observed by the browser. The Combined view normalizes each venue against its own OI before aggregation. Heat intensity is a relative model concentration unless the user selects the absolute session scale. The nearest significant cluster is presented as a trigger while the strongest significant same-side cluster is presented separately as the dominant pool; one is not substituted for the other. Liquidation balance is descriptive exposure below and above mark and is explicitly neutral inside a narrow imbalance band. Historical tooltip distances use the candle close at the inspected time, while live trigger distance uses the current mark. Zone lifecycle, conservatively calibrated model confidence, percentile cluster rank and venue composition are derived from available model history; USD figures are scenario ranges rather than observed position values. The profile uses only the latest model columns and separates modeled long and short exposure.

Forward validation starts only after the browser observes a live trigger confirmed by at least two model horizons. A prediction is stored before subsequent candles are evaluated, expires at the selected model horizon, and is marked tested only when a later candle intersects its recorded price band. Subsequent model state can classify it as partially consumed or consumed; an untouched expiry is invalidated. Touch rate is withheld until at least 30 predictions are resolved. Results are local to the browser and are never backfilled from already-known history. Browser zone alerts are optional, proximity-filtered and deduplicated.

Limit: this model cannot observe private entry prices, leverage, margin mode, collateral, maintenance tiers or individual positions. Price clusters and scenario ranges are analytical approximations, not exchange liquidation orders, a forecast or a trading signal. Local forward-validation statistics are not a global performance claim.

Latency and reconnects

Browser networking, the user’s connection and upstream exchange infrastructure can all affect delivery latency. TradingHub monitors source state and reconnects failed streams. A reconnect can create a temporary gap in observations; the interface should report that condition rather than imply uninterrupted coverage.

Markets database methodology

Identity: every cryptocurrency uses a permanent TradingHub asset ID and one canonical project page. Networks and verified token contracts are child records of that project. Former names, tickers and slugs remain searchable; old slugs redirect permanently to the current canonical URL.

Price and chart: Price and chart ingestion is provider-agnostic. Each project/market uses configured source records with explicit priorities and mappings; the runtime tries eligible sources in priority order, validates responses and preserves provenance. No exchange brand is a universal architectural primary. A failed provider can fall through to the next configured source without changing the public meaning of the asset. Historical chart points come from the exchanges’ candle APIs and are never randomly generated. Successful responses are normalized to USD/USDT terms and cached in D1. If both providers fail, TradingHub retains the last valid snapshot and chart, marks the data stale and does not replace missing values with zero.

Market cap, supply and volume: every canonical Markets/Radar asset has an explicit reviewed priority-1 supply source: protocol, blockchain/explorer, issuer/foundation API or another project-specific source with a defined parsing/calculation method. Aggregators such as CoinGecko are priority-2 fallback only when the reviewed primary source fails; CoinPaprika and CoinLore are not part of the normal priority-1/2 supply chain. The served supply source, source URL and fallback priority are retained with the validated cache. Market cap is calculated as the current TradingHub price multiplied by reliable circulating supply. Unknown or internally inconsistent supply fields stay hidden.

Markets and contracts: supported CEX adapters are labelled API verified only after the exchange confirms the instrument. Any additional CEX or DEX may be curated manually with an explicit market URL and is displayed as a manual listing, never as API verified and never with fabricated price or volume. Derivatives are secondary and require an explicit route. Token contracts are displayed only after verification; native networks do not have a contract address.

Updates and scope: public reads serve the last valid D1 snapshot immediately. Durable price snapshots become refresh-eligible every 3 minutes, CEX listing verification every 6 hours, reviewed supply every 12 hours, and chart ranges remain cached for 15 minutes. Distributed refresh locks prevent duplicate upstream work, unchanged normalized values are not rewritten, and health state is persisted only when the state changes. Candidate discovery requires corroborating spot listings and creates admin-only candidates; it never publishes a project. Radar membership is always a manual editorial decision and is not a rating or recommendation.

A configured source is accepted only after validation. Missing HTML values cannot borrow numbers from another metric, and explorer fields attributed to an aggregator are not primary chain evidence. Inconsistent supply or stale provider timestamps are rejected. A failed probe does not replace a still-fresh primary observation with an aggregator. Supply provenance is revalidated per asset every 12 hours; background work resumes in batches of six assets on subsequent visits. Updates depend on demand, not a guaranteed schedule.