CoinGecko Supply Verification: What Projects Should Prepare

What does CoinGecko supply verification involve?

CoinGecko supply verification is a review of information a project submits about its token supply; preparation is the work of making that information understandable and supportable. Your goal is to show how the circulating figure was derived, what is excluded from it, and where the supporting records can be checked.

Treat your preparation file as an explanation, not as a claim that a particular document or format is officially required. CoinGecko's current request process and instructions are the authority for what to submit. Before assembling materials, confirm the token's CoinGecko page, the relevant asset and network, and the current route for a supply-related request.

A useful starting question for the team is: could someone who did not build the token model reproduce the stated figure from the records and definitions provided? If not, clarify the methodology before sending anything. For help with the broader verification task, see our circulating supply verification service; this article focuses on what the project can prepare itself.

How to verify token supply on CoinGecko: build a supply map

Build a supply map that connects the number you report to the token's on-chain and project records. It should make categories distinct and show the calculation path, rather than presenting a single total without context.

Include a dated working sheet with:

• Token name, ticker, network and contract address, checked against the project's official materials.
• The total supply figure used as the starting point, with the source or calculation method noted.
• Circulating allocations and the basis for treating each as circulating.
• Excluded or restricted allocations, such as vesting, treasury, team, ecosystem or other controlled holdings, where relevant to your token model.
• The resulting circulating figure and a concise explanation of how you reached it.

Use consistent units and precision throughout. If a dashboard, explorer view or internal model displays a different figure, record why; do not silently select the number that looks most favorable. This file is for reconciliation and explanation, not a substitute for CoinGecko's current submission instructions. If the team is also preparing an application to another data provider, keep that process separate and consult our CoinMarketCap supply verification guide rather than assuming the same request format applies.

Which CoinGecko circulating supply verification documents should you prepare?

Prepare records that substantiate the supply map and make the source of each figure easy to inspect. There is no universal document bundle in this guide: the right evidence depends on the token's contracts, controls and allocation structure, and CoinGecko's current instructions should determine what is actually submitted.

Organize potential evidence by allocation, with a short index that states what each item supports. Depending on the project, useful materials to assess may include:

• Public explorer records or contract references that identify relevant token balances and transfers.
• Vesting schedules, unlock terms or allocation tables that explain why tokens are excluded or treated as circulating.
• Governance records or published project documentation supporting treasury and ecosystem allocations.
• A methodology note that explains any assumptions, exclusions, contract relationships or manual calculations.
• Links to public documentation where a reviewer can check claims without relying only on a private spreadsheet.

Keep each file clearly named and dated, and avoid attaching unrelated promotional material. Where a record is private or sensitive, ask whether it is necessary and whether a redacted or summarized version can support the explanation. Provide a reviewer with enough context to understand the evidence without exposing confidential information unnecessarily.

How should a token team explain supply discrepancies?

Resolve discrepancies before submission where possible; where a difference remains, explain its cause and show which figure your methodology uses. A reviewer should not have to infer why the website, explorer, tokenomics document and supply sheet appear inconsistent.

Compare the sources the team controls: contract and network details, public token documentation, published allocation schedules, dashboards and the figures displayed on the project's own website. Check that they refer to the same asset and use the same units. Record the date each figure was checked, since displayed values can change as tokens move or project materials are updated.

For each mismatch, write a short note with three parts: the figures that differ, the reason for the difference, and the evidence or calculation supporting the figure in your request. For example, if a project document describes an allocation as locked but does not explain the lock conditions, add an authoritative source that clarifies those conditions or revise the description. Do not describe tokens as unavailable merely because they are held in a project-associated wallet; explain the relevant controls and use the terminology consistently. If the token's explorer information also needs attention, see explorer token information and logo updates.

A quality-control checklist before you submit to CoinGecko

A final review should confirm that the request is internally consistent, easy to follow and limited to material evidence. Assign a named team owner to perform this check; having the author of the supply model review it independently can help catch unclear assumptions.

Use this checklist:

• Does the token name, ticker, network and contract address match across the request and its evidence?
• Can the circulating figure be traced through the supply map without hidden formulas or unexplained adjustments?
• Are excluded allocations described with their status and supporting record, rather than only a label?
• Do public links open to the material cited, and do file names make their contents clear?
• Have outdated figures, conflicting descriptions and unsupported claims been removed or explained?
• Has the team checked CoinGecko's current request instructions and prepared answers to likely clarification questions?

Keep a copy of the exact version submitted, the evidence index and any correspondence. This creates a reliable internal record if the team later updates its methodology or needs to explain a change. If the issue is not supply methodology but an inaccurate project profile, consider the separate profile update and remediation service instead of adding unrelated requests to a supply submission.

What remains outside the project's control after submission?

A complete evidence pack improves clarity, but it cannot decide the outcome of a CoinGecko review. CoinGecko determines whether the submitted information meets its current review requirements, whether it requests clarification, and what supply information is displayed; a project should not present submission as approval.

Keep the working file current after sending the request. If the team changes its supply methodology, token allocation documentation or relevant contract references, record what changed and why before making any follow-up. Avoid sending repeated versions with different figures and no explanation: a concise change note helps preserve a consistent audit trail.

If your team needs assistance, MegaSatoshi can review the supply map, evidence index and explanation for consistency before you submit. We can also help with adjacent preparation, such as CoinGecko listing support or wallet logo and token list inclusion, when those are separate needs. Send us the token page or contract details, your current supply methodology and the records you have assembled; we will start by identifying gaps and agreeing the scope of a review.