To get a token listed on CoinGecko or CoinMarketCap, you wait for genuine trade history, verify the contract on every explorer, publish supply data anyone can check on chain, keep live channels, then submit one complete package and wait without chasing. That is how to get listed on CoinGecko without the predictable rejections.
Tracker listing is where a token stops being a contract address and becomes something people can search for. It is also the step projects most often attempt too early, get rejected without explanation, and then repeat with the same material. The trackers do not publish their thresholds and will not tell you why a submission failed, so the order of preparation matters.
What you need before you start
- a market with genuine trading across multiple days and multiple wallets;
- a verified contract, logo, name, symbol and decimals on the explorer of every chain the token lives on;
- a public supply page listing every excluded address, what it holds and why;
- a website, an active community room and a social account posting more than announcements;
- one named person, with shared credentials and a shared inbox, who will own the listing after approval.
How to get listed on CoinGecko step by step
The same sequence works for CoinMarketCap. Each step removes one reason a reviewer has to decline.
1. Do not submit until there is trade history
The trackers exist to report market data. A token with a pool created yesterday and four transactions has no market data to report, and the submission is declined on that basis alone. Give the pool time to accumulate genuine trading across multiple days and multiple wallets. A burst of volume from a handful of addresses is worse than no volume, because it reads as manufactured and the reviewer has seen it a thousand times.
- Check: trading spread across days and wallets
- Watch out: concentrated volume from few addresses
2. Make the explorer page do the work
Verify the contract source, add the token logo through the explorer’s own process, and make sure name, symbol and decimals resolve correctly. Reviewers open the explorer first, and a page that answers their questions without an email exchange gets processed faster. If the token exists on several chains, do this on each of them. A submission that lists three chains and has one verified contract raises the exact question you do not want asked.
3. Fix the supply figures before anyone asks
Total supply, circulating supply and the addresses excluded from circulation are the numbers most likely to stall a submission. Trackers publish circulating supply and are held responsible for it, so they are conservative about accepting a figure they cannot verify. Prepare a public page that lists every excluded address with what it holds and why: team allocation, treasury, locked rounds, burn address. If the exclusions are not checkable on chain, expect the higher figure to be published instead, and expect that to surprise your community.
- Check: every excluded address is readable on chain
- Watch out: the higher figure is published when exclusions cannot be verified
4. Have the channels a reviewer expects to find
A website that explains what the token does, a public community room with actual activity, and a social account posting more than announcements. These are checked, and an abandoned channel is worse than a missing one because it suggests the project stopped. Press coverage is not a formal requirement, but it answers the question a reviewer is implicitly asking: has anyone outside the project noticed it? Where the coverage lands and which outlets carry a followed link is documented on our crypto PR page.
5. Submit once, completely
Partial submissions are not held open pending more information. They are declined, and resubmitting too soon after a rejection is itself a negative signal on some trackers. Assemble everything first: contract addresses per chain, pool or market links, the supply breakdown with excluded addresses, the website, the channels, and a description that says what the thing does rather than what it will disrupt.
6. Expect silence, and do not chase it
Review queues are long and the trackers do not provide status updates. Repeated follow-ups through multiple channels are the most reliable way to be deprioritised. If a submission is declined, identify which of the above was thin, fix it, wait, and submit again with something materially different. Submitting the same package again produces the same result.
7. Maintain the listing after it appears
A listing is not a permanent state. Trackers flag and eventually delist assets whose volume collapses, whose contracts go quiet, or whose supply data stops matching the chain. Update circulating supply as vesting releases land, add new chain deployments as they happen, and keep the linked channels alive. Most delisting warnings arrive because nobody updated anything for a year.
What reviewers check and what gets declined
| Item | What the reviewer looks at | What gets declined or flagged |
|---|---|---|
| Trade history | Genuine trading across multiple days and multiple wallets | A pool created yesterday with four transactions, or volume from a handful of addresses |
| Explorer page | Verified source, logo, name, symbol and decimals on every chain | Three chains listed with one verified contract |
| Supply data | Total supply, circulating supply and each excluded address | Exclusions not checkable on chain, so the higher figure is published |
| Channels | Website, active community room, social account | Abandoned channels, which read worse than missing ones |
| Submission package | Contracts per chain, market links, supply breakdown, plain description | Partial submissions, and resubmitting too soon after a rejection |
| After listing | Volume, contract activity, supply matching the chain | Collapsed volume, quiet contracts, stale supply, dead links |
Owning the listing after approval
Who owns the listing
Approval creates an account with the tracker, a support channel and a set of fields somebody has to keep current. Assign it to a named person with the login stored where the team can reach it, because the common failure is a contractor who submitted the form, kept the credentials and left. Recovering access later means proving ownership of a project the tracker has no reason to remember.
Write down what that person checks and when. Once a month is enough for most projects: supply figures against the chain, market pairs still live, links resolving, the description still describing the current product. Ten minutes on a schedule prevents a wrong figure sitting on the page for a quarter until the community finds it. Keep the submission package with the credentials, since every later request is a variation on it, and route tracker email to a shared inbox, because a supply query unread in the account of someone who changed role becomes a removal nobody saw coming.
Keeping circulating supply accurate
Supply is the field most likely to go wrong without anyone touching it, because vesting events change the true figure on dates nobody has diarised. Put every scheduled release in the same calendar as the monthly check and edit the excluded address list the same week. A tracker that finds a treasury address moving tokens it was told were locked treats the whole breakdown as unreliable.
Prefer a method anyone can verify on chain over a number you submit. If the project runs a supply endpoint, keep it on infrastructure that survives a website redesign, since a dead endpoint becomes a frozen figure rather than an error someone notices. Burns, buybacks, migrations and reclassified allocations each need the excluded list edited rather than only the total; post the transaction hash on the supply page, because a figure that drops without explanation reads as a quietly moved allocation. Reconcile the tracker figure against your own page on the same day each month and keep a dated screenshot of both.
Adding markets, chains and redeployed contracts
New pools and new exchange pairs are submitted separately from the asset and are not picked up automatically on every tracker. Submit each new market with its pair address and exchange name once it has real trade history. A market with four trades gets declined, and the decline is attached to your account rather than forgotten.
A deployment on a new chain is an additional contract on an existing asset rather than a new asset, and submitting it as a new asset creates a duplicate entry that is slow to merge. Say explicitly that the token is the same asset bridged or deployed, and describe the mechanism, because the tracker has to decide whether the supplies are combined or kept apart.
A redeployed contract after a migration is the hardest case. Prepare the migration notice, the new contract, the conversion ratio and the old contract address before contacting the tracker, and expect the existing entry to be updated rather than a new one created. Remove dead markets as deliberately as you add new ones: a pair that no longer trades drags the volume figure the tracker uses for its own thresholds.
Delisting warnings and relisting
Reading a delisting warning correctly
A flag on the page is a data problem in almost every case: volume below the threshold, a market that stopped reporting, supply that no longer reconciles, or dead links in the profile. Work through those before writing to support. If volume is the reason, the answer is liquidity and demand rather than a message: concentrating what liquidity remains into one pool that actually trades beats maintaining several that do not. Send one message stating what was wrong, what was fixed and the link or hash proving it, not several tickets across channels.
How to get listed on CoinGecko after removal
Removal is not permanent, and the route back is the original process carrying a stronger case. The reviewer looks at whether the cause has changed, so a resubmission in the same month as the removal is usually declined on sight. The material that answers how to get listed on CoinGecko the first time is needed again: verified contracts, a supply page that reconciles, live markets with genuine trade history and channels carrying posts from this quarter. Add a short note on what went wrong and what changed, and do not announce the return before the entry appears.
Tracking results and edge cases
Tag the outbound links on the tracker page so referral traffic is attributable, and record the date the entry went live. Referral sessions from the tracker domain and searches on the token name both move within days if the listing did anything. Expect most value to arrive indirectly, since exchanges, wallets and data consumers read tracker entries, so judging the listing on sessions alone usually leads to a decision to stop maintaining it, which is the real loss.
Community members report errors first: a wrong logo, a description two versions old, a dead link, a symbol that no longer matches the contract. Whoever runs the community room needs to know where to forward them.
A ticker collision with an existing asset is decided by the tracker and rarely in favour of the newcomer, so check the symbol is free on both trackers before naming anything. A rebrand needs name, symbol, logo, description and links changed in one request with the contract unchanged. Chain reorganisations, pools migrating to a newer exchange version, endpoints that stop answering and pairs the exchange removes all break the feed without any action from the project; the monthly check catches it, and nothing else reliably will.
Common mistakes
- submitting a pool with a few days of trading, or with volume from a handful of wallets;
- listing several chains with only one verified contract;
- sending a partial package and resubmitting the same material after a rejection;
- chasing the review through multiple channels;
- leaving the credentials and correspondence with one contractor or one personal inbox.
What the trackers will not do
- Explain a rejection. There is no appeal and no feedback.
- Accept an unverifiable circulating supply. If exclusions are not checkable on chain, the higher figure is published.
- Treat manufactured volume as volume. Concentrated trading from few addresses is a documented rejection reason.
- Guarantee timing. Queues vary and no paid route changes the underlying requirements.
How long it takes and what it costs
Preparation starts with trade history across multiple days before any submission. After that, queues are long and vary, and the trackers give no status updates or timing guarantee. No paid route changes the underlying requirements. After approval, the running cost is time: about ten minutes a month for the maintenance check, plus edits whenever vesting releases, chains or markets change.
The full set of trackers and exchanges worth submitting to, with what each one requires, is on our exchange and tracker listing page, and the liquidity work that has to happen first is covered in our token listing sequence.
Frequently Asked Questions
When should a project submit to CoinGecko or CoinMarketCap?
Only once the market shows genuine trade history across several days and multiple wallets. Trackers report market data, so a token with almost no trading has nothing for them to report. A burst of volume from a handful of addresses is worse than none, because reviewers read it as manufactured.
Why are tracker submissions rejected?
Most commonly for thin trade history, unverified contracts, unverifiable circulating supply, or abandoned community channels. Partial submissions are also declined rather than held open. The trackers do not explain rejections and there is no appeal, so the useful response is to fix what was thin and resubmit later with materially different material.
What circulating supply figure will be published?
The one that can be verified on chain. If excluded addresses for team, treasury, locked rounds and burns are not checkable, the higher figure is published instead. A public page listing every excluded address, its balance and the reason, updated as vesting releases land, keeps the published figure correct.
Can a token be delisted from a tracker?
Yes. Trackers flag and remove assets whose volume collapses, whose contracts go quiet, or whose supply data stops matching the chain. Most warnings follow a long stretch with no updates. Removal is not permanent: the route back is the original process with a stronger case and a short note on what changed.
Does paying speed up a CoinGecko or CoinMarketCap listing?
No paid route changes the underlying requirements. Queues vary, no status updates are given and timing is not guaranteed. Repeated follow-ups across several channels are the most reliable way to be deprioritised, so the faster path is one complete submission that answers every reviewer question on the first read.