How to get listed on CoinGecko: requirements, form and timeline

What does a CoinGecko listing do for a token?

A CoinGecko listing gives a project a profile in CoinGecko’s market-data directory; it is not an exchange listing or an endorsement. The profile brings the project’s market and reference information together, so accurate public details matter as much as completing a form.

Before applying, decide whether the project is ready to be represented in a public data product. A founder or operations lead should be able to answer these questions clearly:

• Is the token contract identifiable on its chain explorer, and does the project use the same address everywhere?
• Is the token actively traded on an exchange CoinGecko tracks, with a market page that can be checked?
• Do the website and official channels explain the project and link to the correct token information?
• Can the team explain circulating and total supply without contradicting public records?

If any answer is unclear, fix that issue first. A listing request cannot substitute for a live market, a working website or a coherent explanation of the token. This is also why a CoinGecko listing and a listing on a centralized exchange are separate milestones. For a wider checklist, see listings and verification and how to get listed on CoinMarketCap.

Which CoinGecko listing requirements should you check first?

CoinGecko listing requirements are best treated as a readiness checklist, not as a promise of acceptance. The project should present enough consistent, public evidence for a reviewer to identify the asset, inspect its market activity and understand its supply information.

Organize a working folder before you submit. Include the canonical project website, token name and ticker, chain and contract address, official social and community links, exchange and market links, and a concise project description. Add the sources that explain token supply and any relevant contract or migration details. Check that every link is live and points to the project’s official destination.

The most useful quality check is a cross-source comparison. Search the ticker and contract address on the project website, explorer, exchange market page and official channels. Look for spelling differences, old addresses, inactive links, or supply figures that use different definitions without explanation. Correct the source pages where possible; prepare a short factual note where an apparent mismatch has a legitimate reason.

Do not present a market as active merely because a token page exists. The trading pair and exchange need to be identifiable, and the project should confirm that the exchange is supported by CoinGecko. If the market is not yet suitable, address that before submitting rather than asking the form to resolve it.

How do you complete the CoinGecko listing form?

Complete the CoinGecko form with one canonical set of facts and source links. A clear application helps the reviewer verify the project without guessing which address, website or market page the team considers authoritative.

Prepare the answers outside the form first. Assign one person to check names, ticker, chain, contract, official links and market URLs against the project’s own public materials. Use the exact token and project names shown on those sources; avoid promotional language where a factual description is requested. If the project has several chains, distinguish each contract and explain which asset the application concerns.

Before sending, run through this final review:

• Open each submitted URL in a private browser window and confirm it loads.
• Confirm the contract address is the same on the website, explorer and application.
• Check that exchange links open the relevant trading pair, not a general exchange home page.
• Make sure the team’s official channels are current and clearly connected to the project.
• Keep a copy of the submitted answers and the date of submission for follow-up.

Use the current CoinGecko request route and answer every field accurately. If a field does not fit the project’s structure, explain the situation briefly and link to evidence rather than adding unsupported claims. After submission, monitor the contact channel supplied and keep the project’s public information stable while the request is under review.

How to verify supply on CoinGecko before applying

To verify supply on CoinGecko, make the token’s supply information traceable to public evidence and explain any difference between on-chain totals and the project’s circulating-supply figure. The team should know what each figure means and where a reviewer can check it.

Start with the token contract and the relevant chain explorer. Identify the total supply, any minting or burning functionality, and any locked, vested, treasury or otherwise restricted allocations that affect the circulating figure. Not every token has the same supply design, so do not force unlike categories into one number. Instead, document the definition used and provide the source that supports it.

Then compare that explanation with the token page, project website, tokenomics material and any existing market profiles. If a migration or contract change has taken place, make the relationship between old and current contracts explicit. Keep the explanation concise: state the figure, the definition, the relevant address and the evidence. For additional preparation, use this supply verification guide and review supply verification support.

A useful readiness test is whether an informed reader can reproduce the reasoning from the links alone. If not, add a public explanation or correct the underlying materials before applying. Evidence is more useful than a confident assertion that a figure is correct.

How long does CoinGecko listing review take?

CoinGecko listing review has no fixed completion date that a project can safely plan around. The practical timeline includes preparation, submission, any follow-up or clarification, and the platform’s review; the project controls the first two, not the final decision or its timing.

Before submitting, finish the website and market pages, check the token data, and gather answers to likely questions. This reduces avoidable back-and-forth. Once the request is in, keep the submitted facts consistent. If something material changes—such as a contract migration, a changed official website or a market becoming unavailable—make the relevant information clear through the appropriate channel rather than sending duplicate requests.

Plan around readiness, not an assumed publication date. If an announcement, token event or campaign depends on the profile being live, prepare a fallback schedule that does not imply approval before it happens. Keep a record of the request and follow-up, and respond to a reviewer’s specific question with direct evidence rather than a new promotional pitch.

For teams comparing platform work, CoinGecko versus CoinMarketCap listing is a useful distinction: each platform has its own application and review process. A CoinGecko request does not submit or approve a CoinMarketCap profile, and the reverse is also true.

How to address a CoinGecko profile warning

Address a CoinGecko warning by identifying the exact profile field or data issue, correcting the underlying public source where possible, and presenting verifiable evidence through the relevant support route. The goal is a consistent, accurate profile—not simply a change in how the issue is labelled.

First, record the warning text and the affected token or market page. Compare the flagged information with the project website, explorer, exchange market and official channels. Check for common sources of mismatch: an outdated contract address, an unsupported supply explanation, a broken link, a market that is no longer active, or a project name that differs between sources. Correct what the team controls before requesting a profile review.

Then prepare a short remediation note with the affected field, the correction made, and links that let a reviewer verify it. If the data is accurate but appears inconsistent because of a migration, vesting design or naming change, explain that context with primary evidence. Avoid sending several versions of the same request; a clear, documented response is easier to assess. Web3Do’s listing profile remediation support focuses on diagnosing the discrepancy and organizing evidence for review.

Keep a copy of the before-and-after details. That record helps the team answer follow-up questions consistently and update other public profiles if the same stale information appears elsewhere.

How is a CoinGecko listing different from trending?

A listing and a trending placement serve different purposes: a listing concerns a project’s market-data profile, while trending refers to visibility within a platform surface. A listing application is not a request to appear in trending, and appearing in a trending area should not be treated as evidence that a listing has been approved.

Teams often search for “CoinGecko trending,” “trending on CoinGecko” or the “CoinGecko trending list” while preparing a listing. Keep the workstreams separate. First make sure the asset’s profile and data are accurate; then assess whether an appropriate visibility campaign fits the project’s audience and timing. CoinGecko’s trending surfaces and the signals or rotation behind them are not the same thing as the listing review.

A practical sequence is:

1. Establish accurate token, supply and market information.
2. Submit the listing request with complete, consistent evidence.
3. Plan any visibility activity as a separate workstream, with its own scope and reporting.

For related mechanics, see how to get trending on CoinGecko, CoinGecko search visibility placements and trending campaigns. A query such as “CoinMarketCap banner ads vs CoinGecko trending” also compares unlike formats: one is an advertising placement, the other a platform visibility surface. Compare the objective, eligibility and deliverables before selecting either.

What should CoinGecko listing support include?

Useful CoinGecko listing support is preparation and coordination, not a promise of platform approval. It should help the team identify gaps, assemble a clean application package and respond to factual questions with evidence while keeping ownership of the project’s claims with the project.

Before engaging support, confirm the scope in writing. A practical scope may cover:

• A review of the project’s public profile, token details and market links.
• A checklist of missing, inconsistent or hard-to-verify information.
• Application preparation based on facts and materials supplied by the team.
• Supply or migration evidence organization where the project’s token design needs explanation.
• Follow-up coordination and a record of submitted information.

The project should provide accurate source material and approve all statements before submission. Ask who will have access to sensitive information, how access is limited, and whether the team can review the final application. A provider should never ask the project to misstate supply, market activity or control of an official account.

For a listing support engagement, the stated starting price is from $1,300 / project. The final scope should specify what work is included, what the project must provide and how follow-up is handled. See CoinGecko listing support and CoinGecko listing pricing for the relevant service and pricing information.

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. Audit the public informationCheck the website, token contract, supply explanation, official channels and live market links. Resolve inconsistencies before the application.
2. Assemble evidenceCollect canonical URLs, chain and contract details, exchange pairs, and sources that support the project’s supply definitions.
3. Complete the requestUse one consistent set of facts, answer each relevant field directly and keep a copy of what was submitted.
4. Respond to follow-upMonitor the contact channel and answer reviewer questions with the specific source or explanation requested.
5. Maintain the profile dataKeep public links and token details current, and document material changes such as a contract migration.