New Meme Tokens Ranked by Liquidity
Liquidity rankings are useful only when every token is measured at a comparable time, on identified pools, with the same inclusion rules. No complete frozen dataset accompanies this article, so it does not name a winner or claim current statistics. Coinatio's live table supplies current examples and should be read with its displayed timestamps. This methodology explains how to reproduce a ranking and how to distinguish reported pool value from liquidity that can actually absorb a trade. It is research context, not financial advice.
Editorial research by Coinatio, checked against the primary documentation cited below. Educational content only.

- Define a new token by a verifiable first tradable pool timestamp, not by social announcements.
- Rank on executable depth at fixed price impact when possible, while retaining reported pool liquidity as a separate field.
- Record chain, pool, quote asset, block or slot, provider timestamp, and retrieval timestamp for every observation.
- Treat provider gaps, concentrated liquidity ranges, locked assets, and rapidly changing pools as explicit uncertainty.
Population, denominator, and observation window
Start with all fungible tokens whose first verified permissionless swap pool became tradable during a stated UTC discovery window, such as the previous seven complete calendar days. The denominator is every discovered token that passes the inclusion rules, including tokens for which liquidity can be identified but is very small. A token with several pools remains one token in the denominator. Aggregate its eligible pools only after deduplicating the token contract or mint and confirming that wrapped or bridged representations are not being counted as independent launches.
Use a fixed measurement age, for example exactly 24 hours after first pool creation, with a tolerance declared in advance. A second view may use the latest complete hourly snapshot, but it must not be mixed with the age standardized ranking. Coinatio's live table supplies current examples rather than a frozen result set. Its current view can change as pools are added, removed, or repriced.
Liquidity measurement and ranking procedure
Collect pool reserves and state from chain specific sources, then use Birdeye or CoinGecko as discovery and cross-check providers rather than assuming either is exhaustive. For Uniswap style concentrated liquidity, nominal total value locked can overstate executable liquidity when capital sits outside the active price range. For Raydium pools, identify the pool program and quote vaults, and do not merge incompatible pool types without normalizing their mechanics.
The preferred score is two sided executable depth: the smaller USD notional that can be bought or sold before a fixed price impact threshold, such as 2 percent, after protocol fees but before network fees. Simulate against pool state at the recorded block or slot. If reliable simulation is unavailable, rank by the lower of the token side and quote side USD reserve in constant product pools, and label it a reserve proxy. Report gross pool liquidity beside the score, never as a substitute without disclosure.
Use one price source hierarchy fixed before evaluation. Stablecoin quotes may be valued at their contemporaneous reference price. Native asset quotes require a timestamp matched USD price. Rank descending, preserve ties within the precision of the source, and publish missing values as unavailable rather than zero. A sensitivity table at 1, 2, and 5 percent price impact reveals whether the ordering depends on a single threshold.
Exclusions, timestamps, and quality controls
Exclude nonfungible assets, obvious test deployments, pools that never enabled swaps, duplicate contracts, rebasing assets whose reserves cannot be normalized, and pairs where neither side has a defensible USD price at the measurement time. Do not exclude a token merely because a security scanner flags it. Preserve the flag separately so methodology does not silently select only safer looking assets.
Each row needs the token contract, chain identifier, first pool address, first tradable block or slot and UTC timestamp, measurement block or slot, provider observation timestamp, retrieval timestamp, and price timestamp. Reject snapshots outside the declared age tolerance. Resolve disagreements by querying onchain state at the target block where archival access exists, and retain provider responses for auditability.
Coverage, uncertainty, and interpretation
Provider coverage differs by chain, exchange, indexing latency, and pool type. Birdeye coverage is not identical to CoinGecko coverage, and protocol documentation describes mechanics rather than a universal inventory. A discovery ranking therefore means highest among observed eligible tokens, not highest across every launch. State the supported chains and DEX programs in the result metadata.
Liquidity can be withdrawn between observations, reserve values can be distorted by manipulated prices, transfer restrictions can prevent an apparently valid sale, and concentrated positions can move out of range. Honeypot.is and GoPlus checks help annotate contract behavior, but scanner output is evidence with false positives, false negatives, and chain specific gaps. Recompute frequently, show data age, and avoid turning a transient ordering into a claim about quality or future performance.
Sources
This article explains technical and market-data concepts. It is not financial, legal, tax, or investment advice. Verify current chain state and primary documentation independently.


