How to verify circulating supply on CoinMarketCap

What does circulating supply mean in a CoinMarketCap review?

Circulating supply is the amount of a token that a data provider considers available to the public market under its methodology. For a project preparing a CoinMarketCap update, the practical task is to explain the calculation and provide enough evidence for someone else to follow it.

Do not treat total supply, maximum supply, and circulating supply as interchangeable labels. A token may already exist on-chain but still be subject to a lock, vesting schedule, or other restriction that affects how the project classifies it. Conversely, a wallet label alone does not explain whether its balance should be included. The project must connect each classification to observable records and a documented rationale.

Begin with a dated snapshot of relevant balances and define the calculation in plain language. Show the starting supply figure, the balances considered unavailable, and the resulting circulating amount. If the token has several contracts or a migration history, state which contract addresses and chain records the calculation covers. Make the snapshot date prominent so readers can distinguish the submitted calculation from later changes.

This calculation is part of a broader data-readiness process, not a substitute for a listing application. For the listing context and submission preparation, see how to get listed on CoinMarketCap.

How should you reconcile wallets, locks, and vesting?

Reconcile circulating supply by matching each balance to an address, a source record, and a clear treatment in the calculation. The aim is not to label every large holder as unavailable; it is to show why a balance is or is not counted and make that decision auditable.

Create a working ledger with one row per relevant address or address group. Useful fields include the chain, contract address, observed balance, wallet purpose, restriction status, supporting document, and inclusion decision. Keep the classification terms consistent throughout the ledger and the public supply statement.

Review the main categories systematically:

• Vesting and lock contracts: record the contract or service, the relevant allocation, and the schedule or restriction evidence.
• Treasury and foundation wallets: explain the entity’s control and whether the balance is reserved, deployed, or otherwise available.
• Team and investor allocations: connect the stated allocation to vesting documents and on-chain evidence where available.
• Burned balances: provide the address and evidence for the project’s classification rather than relying on an unsupported label.
• Bridged or migrated tokens: reconcile representations across contracts so the same economic units are not counted twice.

Where an address serves more than one purpose, split the balance by documented allocation if the records support that split. If they do not, flag the uncertainty for resolution rather than quietly choosing the most favorable treatment. This ledger is also useful when preparing a circulating supply verification review.

Which documents make the supply calculation reviewable?

A reviewable submission connects the number in the supply calculation to records that can be checked independently. Organize the evidence so a reviewer can move from the summary figure to the underlying addresses, restrictions, and project disclosures without guessing which file supports which claim.

Prepare a concise evidence packet with a contents page and consistent file names. Include the items that apply to your token:

• Token contract address, chain, and links to relevant block-explorer records.
• A dated wallet-balance export or reproducible balance query, with the snapshot date stated.
• Vesting, lock, treasury, and allocation records that support exclusions or classifications.
• Token migration or bridge documentation where multiple representations exist.
• The circulating-supply formula, address ledger, and a short explanation of assumptions.
• Current tokenomics materials and public disclosures that use the same definitions.

The client should provide authoritative project records, confirm who controls project wallets, identify any recent changes, and approve the final classifications. Our preparation checklist distinguishes what we assemble from what only the project can attest to: source links and reconciliation on one side; ownership context, legal records, and sign-off on the other.

Check that dates, token units, and contract addresses match across files. If a document conflicts with an explorer record or public tokenomics page, explain the discrepancy and resolve it before submission. Keep sensitive internal records access-controlled and share only the material needed to substantiate the calculation.

How do you submit a supply update without creating inconsistencies?

Submit a supply update only after the calculation, evidence packet, and public project materials tell the same story. A clean handoff reduces avoidable clarification and gives the reviewer a direct route from the stated figure to its supporting records.

Use this sequence as a final control:

• Confirm that the stated circulating figure uses the same snapshot date as the supporting balances.
• Check the total-supply and circulating-supply definitions wherever they appear in project materials.
• Verify addresses, token decimals, chain names, and units against the relevant records.
• Make exclusions legible: identify the balance, its restriction or status, and its supporting evidence.
• Submit through the official CoinMarketCap contact or support route available to the project, and retain the submitted version and correspondence.

Use the official CoinMarketCap website to locate current platform information and the appropriate project-facing route. Avoid sending contradictory versions through multiple channels. If the platform requests clarification, answer the specific question, update the evidence index if needed, and preserve a record of what changed.

For a related provider, the evidence discipline is similar, but its submission requirements and review are separate. Compare the process with CoinGecko listing preparation, rather than assuming one platform’s response carries over to the other.

What quality checks should happen before the file leaves the project?

A pre-submission quality check should test whether a reviewer can reproduce the calculation and understand its assumptions. Assign one person to reconcile the figures and another to check the evidence trail; separate review helps catch inconsistencies that are easy to miss when building the spreadsheet.

Use a controlled review checklist:

• Reproducibility: Can someone follow the formula from the balance records to the final figure?
• Traceability: Does every material exclusion point to a wallet, document, or on-chain record?
• Consistency: Do the website, tokenomics document, application materials, and calculation use the same terminology and snapshot date?
• Completeness: Are all known contracts, relevant wallets, migrations, and allocation categories addressed?
• Change control: Is there a dated final version, named approver, and record of edits after review?

The quality-control step at MegaSatoshi is a source-to-claim review: we map each supply statement to its evidence, mark gaps for the project to resolve, and return a structured packet for client approval. This is more useful than polishing a number without checking how it was derived. If an earlier figure was published, include a short explanation of the change and its effective date so the new calculation does not appear without context.

For a wider view of listing readiness and related verification work, use the listings and verification hub.

What can the project control in CoinMarketCap’s review?

The project controls the accuracy, clarity, and completeness of its evidence; it does not control CoinMarketCap’s review outcome or how the platform ultimately displays a supply figure. CoinMarketCap may assess the submitted material under its own review practices, request clarification, or retain a different classification, so a well-documented packet is preparation—not approval. Keep public disclosures accurate while a request is pending and avoid presenting a submitted change as already accepted. For your own control, retain the submitted calculation, the exact evidence version, the submission date, and any platform correspondence; if clarification is requested, answer against the cited address or document, record the change, and keep the revised figure consistent across project materials.

When should a project revisit its circulating-supply evidence?

Revisit the calculation when an event changes the balances or restrictions that support it, and keep the evidence synchronized with the project’s public token information. A once-correct figure can become difficult to defend if a vesting release, treasury movement, migration, or contract change is not reflected in the records.

Set an internal owner for supply data and define a change-notification path between finance, token operations, and communications. When a relevant event occurs, the owner should identify affected addresses, refresh the balance snapshot, update the ledger, and check whether the public explanation needs revision. Preserve the earlier version so the project can explain how and why the figure changed.

If the calculation is unclear, begin with the latest public figure, the contract addresses it refers to, and the records that support exclusions. Send those materials to MegaSatoshi with the project’s main contact and any known discrepancies. We will start with the source-to-claim review, identify missing evidence for your team, and return a structured packet for approval before you submit it.

Prices

Starting prices in USD. Custom bundles and volume discounts on request. Payment in USDT, USDC, BTC, ETH, SOL, TON or your project token.

How it works

1. Define the scopeConfirm the token contract, chain, snapshot date, and supply figure being reviewed. List migrations or additional representations that could affect the calculation.
2. Build the wallet ledgerMap relevant addresses to balances, purposes, restrictions, and a documented inclusion decision. Flag unclear ownership or unsupported classifications for the project.
3. Assemble and reconcile evidenceAttach explorer records, vesting or lock documents, allocation materials, and the formula. Check that all sources refer to the same token units and snapshot.
4. Approve and submitHave the project owner confirm wallet context and approve the final packet. Submit through the current official CoinMarketCap route and retain the version and correspondence.
5. Maintain the recordLog clarification requests and changes, then refresh the calculation when a relevant balance, restriction, or token representation changes.