Cryptocurrency
price methodology.

The markets and reference rates that enter the calculation.

1.1 Exchange Integration

CoinPaprika integrates with cryptocurrency exchanges via their public APIs. Each exchange must provide market pair identifiers (e.g., BTC/USD, ETH/BTC), last traded price for each market pair, and 24-hour trading volume for each market pair.

1.2 Scope

Only spot markets are included in the price calculation pipeline. Derivative markets (futures, perpetual swaps, options) are excluded, as their prices can diverge significantly from the underlying spot price due to funding rates, expiry mechanics, and leverage dynamics.

1.3 External Reference Data

Fiat exchange rates are sourced from Open Exchange Rates to convert between fiat currencies (EUR, GBP, JPY, etc.) and USD. Stablecoin peg rates — USDT, USDC, and other major stablecoins — are converted to USD using a volume-weighted index derived from their USD on-ramp markets.

From individual market observations to one reference price.

The algorithm is designed to calculate prices based solely on the current state of the market, with no dependency on prices from previous algorithm runs. Each execution starts from scratch, bootstrapping its own conversion rates from live market data, and converges on accurate prices through multiple iterations. The entire pipeline executes every 60 seconds.

Data Collection

From every integrated exchange, CoinPaprika fetches all available spot markets. Each market provides: market pair name (e.g., BTC/USD), last traded price in the quote currency, and 24-hour trading volume in the quote currency.

Establish BTC/USD Reference Rate

The algorithm starts with zero assumed prices. The first calculation is the BTC/USD weighted average price, derived directly from all BTC/USD spot markets. Bitcoin is chosen because BTC markets are typically the most liquid across exchanges.

BTC_USD = Σ(Price_i × Volume_i) / Σ(Volume_i)
where i = each BTC/USD market across all exchanges

First Pass: BTC and Fiat Markets Only

Using the BTC/USD rate, the algorithm processes markets where one side of the pair is either BTC or a fiat currency. BTC-denominated markets (e.g., ETH/BTC, SOL/BTC):

Price_USD = Price_BTC × BTC_USD

Fiat-denominated markets (e.g., ETH/EUR, BTC/JPY):

Price_BTC = Price_USD / BTC_USD

Subsequent Passes: Incorporate All Markets

Many cryptocurrencies also trade against other cryptocurrencies. The algorithm uses conversion rates from the previous pass to resolve these markets iteratively.

Pass 1: BTC/USD markets → BTC_USD rate
Pass 2: BTC + fiat markets → conversion rates for major coins
Pass 3: All markets using Pass 2 rates → refined rates, more coins covered
Pass N: Repeat until convergence → all reachable coins have prices

Outlier Detection and Removal

Before final aggregation, anomalous market prices are identified and excluded. Markets excluded upfront include those with zero trading fees, transaction mining incentives, stale data (>30 min), and blacklisted pairs. Statistical outlier detection uses median-based bounds adjusted for liquidity depth.

The statistical stages are described in Section 3.

Final Price: Volume-Weighted Average

After outlier removal, the final price is the volume-weighted average of all remaining valid markets:

Price_USD = Σ(Price_i_USD × Volume_i_USD) / Σ(Volume_i_USD)

Higher-liquidity markets naturally carry more weight, ensuring the aggregated price reflects where the majority of real trading activity occurs.

Four checks to limit unreliable market observations.

Outlier removal runs as four independent stages before any price is averaged. Each catches a failure the others cannot see.

3.1 Stage 1 — Excluded Markets

Markets on exchanges under verification, and markets manually excluded after review, are dropped before anything is measured.

3.2 Stage 2 — Volume Anomalies

Volume is checked before price, because a fabricated volume corrupts every weight downstream. Markets reporting negative or implausibly large volume are rejected outright. Past that bound, an asset's markets are accumulated smallest-first, and a market is rejected only when it fails several independent tests at once: the accumulated total must exceed a floor, the market's volume must be out of proportion to the smaller markets already accumulated, and the new total must exceed both the asset's previous observed maximum and its 24-hour median by a multiplier. Requiring all of them together is what keeps a genuine new listing on a large venue from being mistaken for fabricated volume. The limits scale with the asset's own median volume: the more liquid the asset, the tighter the constraint. A rejection here is not final. Flagged markets are surfaced for review, and a market confirmed as genuine is re-admitted to the calculation.

3.3 Stage 3 — Trusted Price Band

Rather than applying one statistical test to every asset, CoinPaprika derives a trusted price band per asset per run, using the strongest method the available market depth supports and falling back through five tiers:

• Interquartile. Requires several markets above a volume floor. Qualification is decided on the asset's stronger markets, but the band itself is computed across all but its emptiest ones. The band widens with the asset's own dispersion, so a volatile asset is not punished for being volatile.
• Median bound, narrow. Requires several markets above a lower floor, with more than half of all markets already clustered around the median. The band is then tightened to the lowest and highest price actually observed.
• Median bound, wide. As above, with fewer markets required and a wider tolerance.
• Reference price. No usable market cohort, but a previous reference price exists. The band's width scales with the asset's median volume.
• Last observed price. No reference price either, but a recent observation exists.

A liquid asset with many honest markets gets a tight band. A thin asset gets a wide band rather than a wrong one.

Stablecoins are treated as a separate class. The volume threshold for the strongest tier is lowered, so that tier stays available for assets whose individual markets are smaller, and the dispersion factor is tightened. An asset that should sit at its peg is given a far narrower tolerance than a volatile one. Prices outside an asset's band never enter its average. Markets inside the band face one more check: a market — or a group of markets sitting on the same side of the median — whose distance-weighted volume would pull the average materially away from the median is excluded as well. And if every market for an asset lands outside its band, the markets are rejected rather than the band: the asset keeps its previous price instead of adopting a suspect one. For thinly-listed assets, absolute sanity checks run alongside the band: a price or volume implausible on its face, or an implied market capitalization exceeding Bitcoin's, is rejected regardless of what the band would allow.

3.4 Stage 4 — Exchange-Level Anomalies

A final pass aggregates volume per exchange and compares it against that venue's own recent history — its previous maximum and its 24-hour median. The comparison is made only when the venue's market list is unchanged: a volume jump explained by newly added markets is not an anomaly, but the same jump on an unchanged market set is. This catches a venue-wide distortion that each individual market would survive.

3.5 Why a Band Is Derived for Every Asset

Assets are priced through one another, so one bad market propagates. An asset quoted at $1 on a single small market, joined by a second market of similar size quoting the inverse pair at $1,000, would carry that asset's reference price from $1 to roughly $500 on the next run — and from there into every asset quoted against it, and onward through the graph. Deriving a band for every asset, including those with too little data to measure precisely, breaks that chain at the first link. Specific thresholds are intentionally withheld to prevent gaming.

How activity is aggregated at market, asset and global level.

4.1 Per-Exchange Volume

The 24-hour trading volume for each exchange is the sum of USD-converted volumes across all its active, non-blacklisted trading pairs. Pairs that have not updated within 30 minutes are excluded.

Exchange_Volume = Σ(Volume_pair_i × Price_pair_i_USD)

4.2 Per-Asset Volume

The 24-hour trading volume for an individual asset is the sum of volumes across all its valid market pairs on all integrated exchanges.

4.3 Global Volume

The global cryptocurrency trading volume is the sum of all per-exchange volumes.

How exchange data quality is evaluated.

Each exchange receives a Confidence Score on a 0–100 scale, reflecting the reliability and quality of its reported data. The Confidence Score influences how the exchange's data is weighted and filtered in the price calculation pipeline.

5.1 Evaluation Criteria

5.2 Confidence Score Application

• Exchanges under review are excluded entirely from price and volume calculations.
• Confidence Scores are reviewed and updated periodically, and may change immediately in response to significant events (hacks, regulatory action, prolonged API outages, etc.).
• Exchange data is subject to additional scrutiny through the Market Pair Liquidity Indicator (see Section 6).

5.3 Estimated Real Volume (ERV)

Estimated Real Volume is a measure introduced in 2019 to combat fake volume and wash trading. ERV is derived from the Liquidity Indicators of all markets on a given exchange. Each market's reported 24-hour volume is adjusted using weights assigned to its liquidity indicator category (Good, Average, or Bad).

ERV is recalculated continuously throughout the day and may differ significantly from raw reported volume on exchanges with low confidence scores.

What the Good, Average and Bad indicators mean.

Individual market pairs receive a real-time liquidity assessment based on orderbook spread (percentage difference between best bid and ask), orderbook depth (value within ±1% and ±10% of mid-price), volume consistency, and outlier checks.

6.1 Indicator Categories

• Good — Strong liquidity and normal market conditions.
• Average — Constrained or fluctuating market conditions; liquidity is lower than the reported volume suggests.
• Bad — Inadequate liquidity relative to reported volume, or severely unbalanced market conditions.

Market pairs that fail liquidity checks are down-weighted in the VWAP calculation. If no other source exists to calculate an asset's price and volume, the pair is still used — with a clear indication that liquidity could not be verified.

How available supply is measured and verified.

7.1 Proof-of-Work Coins

For PoW-based cryptocurrencies (e.g., Bitcoin, Litecoin), circulating supply is queried directly from block explorer APIs. Values are verified against multiple independent block explorers and updated automatically as new blocks are mined.

7.2 Tokens (Smart Contract-Based)

For ERC-20 and similar tokens, circulating supply is calculated as:

Circulating Supply = Total Supply - Locked Tokens

Locked Tokens includes:
- Team/founder vesting wallets
- Treasury or reserve wallets
- Burn addresses
- Locked staking contracts

7.3 Verification

Circulating supply figures are cross-referenced with data disclosed by project teams and updated when unlock events, token burns, or other supply-affecting events occur. Specific thresholds are intentionally withheld to prevent gaming.

The formulas behind market cap and distance from ATH.

8.1 Market Capitalization

Per-asset:  Market Cap = Current Price (USD) × Circulating Supply
Global:     Global Market Cap = Σ(Market Cap of all tracked assets)

8.2 All-Time High (ATH)

For each asset, CoinPaprika tracks the highest aggregated price ever recorded, the date it occurred, and the current distance from ATH:

ATH Distance (%) = (ATH Price − Current Price) / ATH Price × 100%

Requirements for assets and exchange integrations.

9.1 Cryptocurrency Assets

To be listed on CoinPaprika, a cryptocurrency must meet the following requirements:

• A functional, project-owned website with clear project information
• A working block explorer with verifiable on-chain data
• Active trading on at least one CoinPaprika-integrated exchange
• Transparent communication — the project maintains public channels (X/Twitter, Telegram, Discord) with timely updates and responsiveness to community issues

9.2 Exchanges

To be integrated as a data source, an exchange must:

• Operate a functional website with verifiable trading activity
• Provide a public REST API that meets CoinPaprika's data standards (market pairs, prices, volumes)
• Maintain up-to-date API documentation
• Provide a dedicated point of contact for data quality issues

Connecting CoinPaprika IDs to other reference systems.

Reference data is only usable inside a regulated workflow if it joins to the identifiers that workflow already runs on. CoinPaprika maps its asset IDs to external identifiers:

• DTI — Digital Token Identifier (ISO 24165), issued by the Digital Token Identifier Foundation. The ISO standard identifier for digital tokens, and the identifier regulatory reporting regimes reference for digital assets.
• ISIN — International Securities Identification Number (ISO 6166), which joins crypto positions to instrument records in existing back-office, custody and accounting systems.
• Provider IDs from CoinMarketCap, CoinGecko and CryptoCompare, for reconciliation and migration without re-mapping a universe by hand.

Mappings are available through the API ID Mappings endpoint: docs.coinpaprika.com — API ID Mappings

What commercial relationships can—and cannot—change.

CoinPaprika is independently owned. It is not owned by, and holds no stake in, any cryptocurrency exchange, trading venue, market maker or token issuer. This distinguishes CoinPaprika from aggregators owned by the venues whose data they publish.

11.1 What a Commercial Relationship Can and Cannot Affect

CoinPaprika operates a paid expedited listing service (Fast Track) and carries advertising. Both are disclosed here, because a claim of independence is only useful if it is specific about its limits.

Fast Track buys moderator time: a submission and its metadata are reviewed and processed on a priority schedule instead of the standard queue. It buys nothing else.

No payment of any kind affects:

• the price calculated for an asset, which is produced by the pipeline described on this page and subject to the same outlier detection as every other listed asset;
• an exchange's Confidence Score;
• a market pair's Liquidity Indicator;
• ranking, which is derived from calculated market capitalization.

Listing is a decision about coverage. Pricing is a measurement. An asset admitted through Fast Track is measured by exactly the same method as any other: a thin asset receives a correspondingly wide trusted band and a low liquidity indicator.

Advertising is labeled as advertising and is never presented as data.

Questions about this methodology, including any concern about a potential conflict of interest, can be raised through our contact page: coinpaprika.com/contact

The published refresh schedule for each data type.

Why the calculation method changed in December 2018.

Prior to December 2018, CoinPaprika used a price calculation algorithm that relied on conversion rates from previous algorithm runs. For example, converting an ETH/USDT market price to USD required the USDT/USD rate from the previous iteration — creating a historical price chain. During periods of high volatility, this dependency caused visible price lag. During sharp BTC drops, CoinPaprika's aggregated BTC/USD price would temporarily remain higher than the actual market because stale conversion rates dampened the impact of rapid price movements. In December 2018, the algorithm was redesigned to eliminate all historical dependencies. The current iterative convergence approach bootstraps fresh conversion rates from live market data on every execution, ensuring prices always reflect the present state of the market.