Getting a Solana token listed on CoinGecko

What an aggregator listing actually is

A data aggregator does not provide a market. It reads markets that already exist and presents them in one place, which means its interest in your token is fundamentally about whether the data can be collected reliably.

That framing explains most of the criteria. An aggregator needs to be able to find your pool, read its trades, price them against something meaningful, and be reasonably confident the figures will still make sense next week. Everything else follows from that requirement.

It also explains why the process feels less like a pitch than an exchange application does. Nobody is evaluating whether your project will succeed. They are evaluating whether tracking it produces a page that is accurate and worth having, which is a much narrower question and a considerably easier one to pass if you prepare for it.

What they actually need from you

Requirements are published and they change, so the current list on their own site is the authority. What stays stable is the shape of it.

• A trackable venue. Your liquidity has to sit somewhere the aggregator can read. This is the item most likely to be a hard blocker.
• Non-trivial liquidity. A pool too thin to trade against produces prices that jump around, which is exactly the data quality problem they are trying to avoid.
• Complete, accurate metadata. Name, symbol, description, an image that loads from somewhere permanent.
• A real presence. A website that works and social accounts with content, because they are used to verify the token is what it claims.
• Some genuine usage. Enough trading that the page will not be empty.
• Contract details. The mint address, and the authorities that anyone reviewing will check anyway.

The three items that fail most applications

The first is the one worth checking before anything else, because it is the only one you cannot solve by working harder on the form. If your pool sits on a program that is not widely indexed, no amount of application quality changes the outcome, and the same root cause produces the more general problem covered in the aggregator visibility guide.

The third is the most frustrating because it is entirely within your control and costs nothing. Broken image links, a website that does not load, a description left empty: each one gives a reviewer a reason to move on, and reviewers processing a queue take the reasons they are given.

What to do before applying

1. Confirm your venue is trackable. Check whether your pair already appears on major screeners. If it does not, fix that first.
2. Fix depth. Simulate a realistic buy and sell. Erratic pricing is a data quality problem from their side, not just yours.
3. Complete the metadata. Every field, with an image hosted somewhere permanent rather than somewhere temporary from launch week.
4. Make the website and socials real. They will be opened, and an empty profile answers a question you did not want asked.
5. Check your authorities. A live mint authority invites scrutiny you can avoid by disabling it or explaining it.
6. Accumulate some genuine history before submitting, because a token that started trading yesterday has nothing to track.

Doing all six first turns a queue slot into a likely approval. Submitting before them turns it into a rejection that you then have to wait to retry, which is the actual cost of applying early.

One item on that list is worth expanding because teams treat it as a formality. The website and social accounts are not being checked to see whether they exist; they are being used to confirm the token is what the submission says it is. A reviewer opening a site that does not mention the token, or a social account with no reference to the mint address, has been given a reason to doubt the connection rather than confirm it. Making the link explicit in both directions, so that the site names the token and the token metadata points at the site, removes an entire category of ambiguity for the cost of one sentence.

Where activity helps and where it does not

Trading activity contributes to exactly one criterion, which is the demonstration that the token is genuinely used rather than a page nobody will visit. That is a real input and it is a supporting one.

What it cannot do is substitute for the structural items. It does not deepen your pool, make an unindexed venue readable, complete your metadata or produce a website. Running a campaign to strengthen an application while those are unresolved spends money on the one input that is easiest to discount while leaving the actual blockers untouched.

The shape of the activity matters as much as the amount, for the same reason it does everywhere else. Sustained moderate trading across a period reads as a token in use. A single enormous day followed by silence reads as something arranged for the application, which is the impression you were trying to avoid creating. The exchange listing guide covers the same dynamic where the stakes are higher.

After the listing

Two things are worth knowing about what happens once you are listed.

The data keeps being read. A listing is not a permanent state independent of what your token does. Pages for tokens whose liquidity disappears or whose trading stops become stale, and aggregators periodically review what they are tracking.

Accuracy becomes your problem. If your pool moves, if you migrate liquidity, if metadata changes, the listing can drift out of date and the wrong figures will be shown to everyone who looks. Aggregators generally provide a process for requesting updates, and using it is faster than hoping somebody notices.

The broader point is that an aggregator listing is a consequence of having a trackable, functioning market rather than a way to create one. Teams that treat it as a milestone to chase before the foundation exists find the application harder than it needs to be, and the launch checklist covers the order that makes it straightforward instead.