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 (c01, c04).
Step 1: Establish what the page actually says
Start by listing statements, keeping each close to the original wording. For this provider, the sourced statements relevant to a value calculation are:
- Almost all tokens are priced using CoinGecko's API (c12).
- 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 (c13, c14).
- Tokens that are not circulating or are yet to be issued are not counted (c15).
- Tokens held in a team vesting contract are not counted in the TVL example, framed as tokens not yet issued (c16).
- There is no double-counting within the same protocol: a deposit, receipt token and re-deposit is counted once (c17, c18).
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.
Step 2: Record the price source without adding properties
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 (c12, c13, c14). 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.
Step 3: Treat the supply rule as an inference to verify
This is where most recalculations go wrong. The only supply-relevant sentence is that non-circulating or unissued tokens are not counted (c15), illustrated by a vesting example in a TVL context (c16). The page does not state whether vesting allocations are excluded from market-cap supply. Treat that as unestablished and ask the provider directly.
If you must proceed, state your working rule explicitly and label it an assumption to verify. Here is a hypothetical illustration only, using invented numbers:
| Item | Hypothetical value | Status |
|---|---|---|
| Total supply | 100,000,000 | Assumption |
| Vesting-contract allocation | 20,000,000 | Assumption |
| Supply used under assumed rule | 80,000,000 | Calculation |
| Price per token | $0.50 | Assumption |
| Value under assumed rule | $40,000,000 | Calculation |
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.
Step 4: Test whether the double-count rule applies
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 (c17, c18). 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.
Step 5: Record the timestamp and contribution route
Each metric has its own open-source adapter repository that anyone can contribute to (c04), and project listings are submitted via a pull request to the corresponding repository (c05). Record the figure's timestamp and the adapter version you read. Whether community maintenance causes reporting lag is not stated by the source; do not assert it as fact.
What the source does not say
- It does not give a market-cap formula or define the numerator's supply basis.
- It does not say whether vesting or locked allocations are excluded from market-cap supply; the vesting example is framed in a TVL context (c16).
- It does not describe how CoinGecko API prices are aggregated or weighted (c12).
- It does not state that the within-protocol double-count rule applies to market-cap figures (c17, c18).
- It does not specify update frequencies or how to reconcile a figure after a listing change (c08).
Audit checklist
- Quote the supply statement, keeping TVL and market-cap contexts separate.
- Log the price source and the fallback condition (c12, c13, c14).
- Label every supply assumption you introduce and mark it unverified until the provider confirms.
- Scope the double-count rule to what it was stated for (c17, c18).
- Timestamp the figure and note the adapter version consulted (c04, c05).
Run this sequence and you will end with a defensible decomposition: sourced statements, scoped observations and clearly labeled inference, rather than a reconstructed formula presented as the provider's own.