Compare how a data provider defines market capitalisation before treating two crypto market-cap charts as comparable.
Reader focus for this site: comparing crypto market-cap definitions across data providers. Primary cite: docs.llama.fi.
Compare how a data provider defines market capitalisation before treating two crypto market-cap charts as comparable.
How market-cap definitions diverge
A five-step audit method for confirming a provider's market-cap definition, price source and supply treatment, with a clearly flagged hypothetical worked example.
This midday update restates the verification steps for operators checking primary sources before repeating a claim. It is a separate checklist from earlier posts on this site.
The short answer: you cannot fully confirm a provider's market-cap definition from a methodology page alone. You can confirm what the page states, then separate that from what it leaves open, and record which parts of your calculation rest on assumption.
This guide uses one provider's published methodology notes as a concrete example of that audit process. The source describes how the provider tracks DeFi metrics, prices tokens, and treats token supply in the context of total value locked (TVL). It describes itself as producing "inclusive, non-biased, and community driven statistics" and states that its adapters are open-source and contributions are open .
When two charts are not comparable
Notice the context: the supply and double-count notes sit under the provider's TVL discussion, not a market-cap formula. This is the first place to be precise.
The page supports only a narrow statement: pricing is via CoinGecko's API for almost all tokens, with an on-chain fallback using pool weights . It does not describe how the API price is composed, aggregated or weighted. Do not write that it is a volume-weighted average unless the provider says so.
For an audit trail, log the fallback condition separately. A pool-weight price is derived from the composition of one market; whether that produces a different number from the API price is a property of the two methods, not something the source states.
This is where most recalculations go wrong. The only supply-relevant sentence is that non-circulating or unissued tokens are not counted , illustrated by a vesting example in a TVL context . The page does not state whether vesting allocations are excluded from market-cap supply. Treat that as unestablished and ask the provider directly.
- Almost all tokens are priced using CoinGecko's API .
- Where API pricing cannot be used, an on-chain method may be applied, commonly by comparing pool weights of a very liquid Uniswap V2 market .
- Tokens that are not circulating or are yet to be issued are not counted .
- Tokens held in a team vesting contract are not counted in the TVL example, framed as tokens not yet issued .
- There is no double-counting within the same protocol: a deposit, receipt token and re-deposit is counted once .
What the source does not say
The $40,000,000 figure is a purely hypothetical product of an assumed exclusion rule; it is not a verified market figure and should not be published as one. If the provider confirmed vesting tokens are included, the equivalent calculation would use 100,000,000 tokens. The point of the table is to force the assumption into the record, not to settle the rule.
The no-double-count rule is stated for the same protocol in a TVL-style example, where a deposit, a receipt token and a second deposit are counted once . Whether that rule governs market-cap figures is not established by the page. Note it as a scoped observation: within-protocol double counting is addressed for TVL; extension to market-cap is an inference.
A practical check: list each component your calculation sums and ask whether any two components represent the same underlying token. If yes, the source does not tell you which one to drop in a market-cap context.