Solana token screeners compared

What a screener actually does

A screener is an indexer with a front end. It watches decentralised venues, reconstructs each pool's state and trade history from on-chain data, and presents the result as a page per trading pair.

Two consequences follow from this and both are frequently misunderstood. Nothing on a screener is submitted by a project, which is why tokens appear without anyone applying and why nothing on the page can be corrected by asking. And everything on a screener is derived, which means an error on the page is either an indexing problem or an accurate reflection of something that is genuinely true on chain.

The exception is cosmetic metadata. Images, descriptions and social links are typically drawn from the token's own metadata or submitted through a verification process, and those are the only fields a team has direct influence over.

How the main ones differ

The dimension that causes the most confusion is multi-pool handling. A token with pools on three venues will show one aggregate figure on a screener that combines them and three separate smaller figures on one that does not, and neither is wrong.

Indexing speed

For a launch, the interval between the first trade and the pair appearing is the number that matters, and it varies more than most people expect.

Pools created through the major launchpads on the largest venues typically appear within a minute or two, because those paths are the most heavily instrumented. Pools created directly on a less common venue can take substantially longer, and pools on a venue outside a screener's coverage never appear.

This produces a recognisable pattern of panic on launch day: the pair is missing from the screener the team is watching, the team assumes something is broken, and the actual situation is that a different screener already has it. Checking a second tool before diagnosing anything is the cheapest available step, and the fuller diagnostic sequence is in the missing pair guide.

There is a second speed question that matters more for teams and gets less attention: how quickly a screener reflects a change you made. Updating metadata, adding liquidity or claiming a listing does not propagate instantly, and the delay between doing something and seeing it reflected is where most of the second round of launch-day panic comes from. The rule of thumb worth holding is that on-chain state appears quickly because it is read from blocks, while anything involving a cache or a submission process can take hours. Waiting a full day before concluding that a change did not work saves an enormous amount of unnecessary troubleshooting.

Why they disagree

Three causes account for nearly every discrepancy between two screeners showing the same token.

Different pools. The most common by a wide margin. If liquidity exists in more than one place, each screener may be showing whichever pool it considers primary, and those can differ. Prices diverge whenever arbitrage between the pools is incomplete.

Different liquidity maths. Concentrated positions do not have a single obvious depth figure, since the answer depends on the price range being considered. Screeners resolve this differently and produce different numbers from identical on-chain state.

Different volume windows. A twenty-four hour figure can be a rolling window or a calendar day, and around a launch the two differ substantially.

Where they should not disagree is on transaction counts and individual trades, since those are read directly from blocks. A discrepancy there points at an indexing lag on one side, which usually resolves without intervention.

Which one for which job

For checking whether a pair exists at all, use whichever has the broadest venue coverage, and check a second before concluding it does not.

For watching a launch in real time, use the one with the lowest indexing latency, accepting that it may show less context.

For assessing real depth, read the pool directly rather than trusting any screener's summary figure. The derived number involves assumptions that the underlying state does not.

For comparing venues, be aware that screener volume figures include failed and duplicated activity in ways that vary by tool. Our own block-level sampling of what actually confirms per venue is published on the measured data page, and the gap between confirmed and attempted activity is larger than most summaries suggest.

For anything a buyer will see, check the token as a stranger would: fresh browser, no context, the way it renders on a phone. Teams look at their own token in a state of knowledge that no potential buyer shares.

What token teams should watch

The instinct is to watch price, which updates constantly and tells you almost nothing you can act on.

The fields worth checking on a schedule are narrower. Whether the pair appears at all on the tools people actually use. Whether the image and name render correctly, since a token displaying as an unnamed mint converts a fraction of the interest it receives and the fix is covered in the metadata display guide. Whether the liquidity figure matches what you believe you provided. And whether the transaction feed shows organic-looking activity rather than a single repeated pattern.

That last one deserves a note. Screeners display recent transactions publicly, which means anyone can look at the pattern of activity around a token and form a view about what is producing it. Activity that looks mechanical is visible to every visitor, and the impression it leaves is harder to correct than the metric it was meant to improve.

A weekly check across two screeners takes a few minutes and catches essentially every display problem that would otherwise be discovered by a potential buyer instead.