How to resolve a warning on a CoinMarketCap or CoinGecko listing

What does a CoinMarketCap or CoinGecko listing warning mean?

A listing warning means the platform has presented a concern alongside a project profile; it does not, by itself, tell you which correction will resolve the concern. Read the exact wording and note where it appears before changing the listing or contacting support.

The notice may point toward a discrepancy in project details, token supply information, contract or market data, or the status of a project’s public channels. Treat these as areas to investigate, not as a definitive list of platform warning categories. The platform’s own message and current instructions are the evidence to work from.

Start a case file with:

• A screenshot or saved copy of the notice, including the profile location.
• The exact project, token, network and contract details shown on the listing.
• The relevant official project pages and records that support the correct information.
• A short description of what changed, if anything, before the notice appeared.

Avoid submitting a broad request to “remove the warning” without explaining what is inaccurate or what evidence has changed. If the issue is not clear, compare the profile against your primary sources first. For wider listing context, see how CoinMarketCap listing submissions work and how to get listed on CoinGecko.

How do you identify the issue before contacting support?

Identify the specific statement or data point that conflicts with the project’s verifiable records. A useful diagnosis links the visible notice to a source, rather than assuming that every warning has the same cause.

Compare the listing with the project’s official website, documentation, explorer records and current public channels. Check spelling and naming as well as facts: a correct contract paired with an outdated token name can still leave a reviewer unsure which asset the project represents. For market information, make sure the linked market or pair actually corresponds to the token and network in the listing.

Use a simple evidence map before drafting your request:

If a source is stale, fix it at the source first and make sure related project pages do not contradict one another. Then describe the correction in plain language and attach only evidence that directly supports it. When the concern involves published supply, use the separate guide to verifying token supply to structure the check.

How to verify supply on CoinGecko and support a correction

To support a supply correction, show how the figure was derived and where the underlying token information can be checked. A headline number without context can leave a reviewer unable to distinguish circulating supply from total or maximum supply.

First, define the supply terms used in your materials. Explain any locked, vested, burned or otherwise excluded balances only when those descriptions match the project’s records. Then compare the explanation with the token contract and relevant explorer information. If the project has more than one token contract, a migration, or balances held across addresses, document the relationship clearly instead of combining figures without explanation.

A strong supply evidence pack should make the reasoning legible:

• Identify the token contract and network relevant to the listing.
• Link to the public records used to support the figure.
• Explain which balances are included or excluded and why.
• Match the explanation across the listing, project website and documentation.
• Flag any unresolved discrepancy rather than presenting an estimate as confirmed.

For a contract migration or changed token details, address the profile update as well as the supply question. The supply verification service and listing profile remediation cover related work, but the evidence still needs to reflect the project’s actual records. Do not alter a published supply claim simply to make it resemble another tracker’s display; explain the method behind the project’s own figure.

How should you prepare a case for CoinMarketCap versus CoinGecko?

Prepare a separate, platform-specific case for each listing because the notice, profile details and submission instructions may differ. One shared evidence folder can help the team stay consistent, but each message should address the platform’s actual concern and follow its current support process.

For either platform, put the issue first: quote or summarize the notice, identify the affected profile detail, state what has been corrected and point to the evidence. Keep the project identity consistent across the request, contract information and official links. If the correction depends on a source page, make sure that page is live and accessible before referring a reviewer to it.

Do not assume that a successful correction on one platform automatically changes the other listing. Check each profile after the relevant support exchange, and retain the submitted message and evidence so the project can respond coherently if asked for clarification. The CoinMarketCap listing guide and CoinGecko listing guide explain the broader listing context; this guide focuses on correcting a profile concern after it appears.

A practical draft is short: one paragraph identifying the issue, a compact list of corrections, and direct links to the supporting records. Avoid promotional language, repeated follow-ups that add no new evidence, or claims about a platform’s internal review criteria. The reviewer needs a clear path from the notice to the verified correction.

What happens during a listing profile remediation?

Listing profile remediation turns a confusing notice into a documented correction request. The work is most useful when the project team can provide access to authoritative public sources and confirm which information is current.

At Bitcoin Insider, a named evidence review checks the notice against the project’s official pages and available token records before a submission is drafted. This review is designed to catch mismatched names, stale links, unclear supply explanations and unsupported statements before they become part of the case. The project retains control of its platform accounts and approves factual claims before anything is sent.

A typical workflow is:

• Intake: collect the notice, listing URL, project links and contract details.
• Diagnosis: map the concern to the information that needs checking.
• Correction: update project-controlled sources where needed and assemble evidence.
• Submission: prepare a concise, platform-specific request for the project to review and send through the appropriate channel.
• Follow-up: organize any response and additional evidence into a clear record.

The pace depends on how quickly the team can verify information and on the platform’s response. The deliverable is an organized remediation case, not access to an unpublished review queue. You can also review the scope of listing profile remediation or read how we work before deciding whether outside support is useful.

What can affect a warning review, and what should you do next?

The project can control the accuracy of its sources, the clarity of its evidence and the completeness of its request; it cannot control how CoinMarketCap or CoinGecko assesses the case or when either platform responds. A corrected profile therefore does not itself establish that a warning will be removed, and an outcome cannot be promised. Keep the remediation focused on accurate information rather than trying to influence a platform’s review.

Before sending a case, confirm that the facts agree across the listing, official website, documentation and explorer records. Check that every link opens to the intended source, that the contract and network are unambiguous, and that the request explains the correction without adding unrelated marketing material. If a fact remains uncertain, label it as unresolved and investigate it rather than presenting it as settled.

If there is no obvious factual error, do not invent one to fit a suspected warning cause. Ask the platform for clarification through its current support route, then respond to the specific information requested. Keep a dated internal record of the notice, edits and correspondence so the project team can avoid conflicting explanations later.

For a focused review, send Bitcoin Insider the listing URL, the notice as it appears, the relevant official project links and the contract or supply records connected to the concern. We will map the evidence to the visible issue and tell you what can be prepared before a platform request is made.

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. Capture the noticeSave the exact wording and listing location. Note which profile detail appears to be affected.
2. Check the underlying recordsCompare the profile with official project sources, token records and relevant market pages.
3. Correct project-controlled informationUpdate stale or inconsistent sources first, and make sure related pages tell the same factual story.
4. Build a concise evidence packExplain the correction and include direct, relevant links that let a reviewer verify it.
5. Submit and keep a recordFollow the platform’s current support instructions and retain the request and any reply for follow-up.