Reference guides

Dexscreener filters are pair-screening controls for liquidity and age

Dexscreener filters are pair-screening controls that narrow live decentralized-exchange markets by chain, minimum liquidity, and pair age. For a focused scan, choose the chain first, set the lowest pool liquidity you will accept, limit the pair's age, and rank the survivors. Add volume or transaction conditions only after those two gates. Each result represents a trading pair, not a unique token, so the same asset can appear through several pools.

Key takeaway: Pair age belongs to the pool address, so a newly created pool can make an established token look young.

Set the liquidity floor and age window as one decision

The liquidity floor and age window determine which part of the pair market enters the shortlist. A narrow age cap surfaces recent pools, while a higher liquidity minimum removes pools below the chosen depth.

Set the chain before choosing either value. Solana, Ethereum, Base, and Arbitrum have different activity patterns, quote assets, and transaction economics. Combining them into one informal benchmark weakens the screen. A Raydium pool quoted in Wrapped SOL belongs in a different comparison from a Uniswap pool quoted in WETH, even when their displayed dollar liquidity looks similar.

The floor should reflect the depth required for the research task. The age setting should express recency, not perceived token quality. Use a maximum age for newly created pairs, a minimum age for pools that have survived an initial trading period, or both values to define a closed interval. Every active condition narrows the same result set.

Filtering costs nothing; execution costs remain separate

Using Dexscreener filters costs $0 and requires zero wallet signatures. Applying, clearing, or sorting a screen creates zero network transactions and consumes zero gas units because the interface reads indexed market data.

Costs begin only after someone leaves the screen and submits an on-chain action through a trading venue. A swap on Uniswap or PancakeSwap pays the pool's defined fee and the network transaction cost. A trade through Raydium or Orca follows Solana's transaction and pool-fee mechanics. Price impact comes from the chosen pool's available depth. None of those execution costs changes because a pair was discovered with a liquidity or age filter.

The public screen also works without connecting a wallet. That separation matters: filtering is a read-only research operation, while trading is a state-changing blockchain transaction.

Pair age measures the pool, not the token

Pair age describes elapsed time for a specific liquidity-pair record. It does not represent the age of the token contract, mint, project, or community.

An established token can receive a newly created pool on another decentralized exchange or against another quote asset. That pool starts with its own pair address and age. Adding liquidity to the existing pool changes its reserves without creating a new age. Creating a separate pool produces a separate record, even when both records contain the same base token.

Exact time conversions prevent accidental window changes. One hour contains 60 minutes, while 24 hours contains 1,440 minutes. Seven days equals 168 hours, and 30 days equals 720 hours. A minimum and maximum entered in the same unit form an age band: the lower bound removes younger pairs, and the upper bound removes older ones.

Liquidity is a threshold, not a trade-size guarantee

The connected topic is covered under Dexscreener breakdown. The liquidity filter compares the reported value of each individual pool with the selected minimum or maximum. It screens pool depth; it does not measure token supply, market capitalization, trading volume, or the balance of a wallet.

A Dexscreener pair record reports liquidity in USD alongside the quantities of its base and quote tokens. A pool has two asset sides, and their values move as swaps alter the reserves. The displayed dollar total therefore changes with reserves and token prices.

Pool design also changes how that total behaves during execution. Uniswap v2 distributes its two reserves along a constant-product curve. Uniswap v3 concentrates liquidity inside price ranges. Raydium concentrated-liquidity pools and Orca Whirlpools also place capital within chosen ranges. Equal reported totals do not promise equal depth at every price, so the filter is a first gate rather than a price-impact calculation.

A worked screen for a recent Solana pair

Worked example. Every changing market input in this example is hypothetical. The hypothetical screen selects Solana, sets minimum liquidity at $75,000, requires a minimum age of 2 hours, caps age at 48 hours, and requires at least $120,000 of volume during the 6H interval.

Hypothetical Candidate A reports $90,000 liquidity, an age of 6 hours, and $150,000 of 6H volume. Hypothetical Candidate B reports $60,000 liquidity, an age of 10 hours, and $130,000 of 6H volume. Hypothetical Candidate C reports $100,000 liquidity, an age of 72 hours, and $200,000 of 6H volume.

This Dexscreener filters example applies every condition with AND logic. Candidate A passes all five inputs. Candidate B misses the liquidity floor by $15,000. Candidate C exceeds the maximum age by 24 hours. The starting set contains 3 pairs; the completed screen leaves exactly 1 pair. Changing any hypothetical input requires recalculating membership from the full set.

Use activity filters to test the surviving pairs

Activity filters refine the pairs that already meet the age and liquidity requirements. Volume measures traded value during a selected window, while buys, sells, and transactions measure event counts rather than pool reserves.

The screener presents activity over 5M, 1H, 6H, and 24H intervals. Five minutes equals 300 seconds. Six hours contains 360 minutes, and a 24H period contains four consecutive 6-hour blocks. These windows are not interchangeable: a short burst inside 5M says little about whether activity persisted across 24H.

Transaction count is not a count of unique people. One address can submit repeated swaps, and routed activity can touch more than one pool. When Traders or Makers data appears, it adds address-level context to the event totals. Separate minimum-buy and minimum-sell conditions are useful when one-directional activity would otherwise satisfy a total-transaction threshold. Keep the time window identical when comparing those fields.

Quote assets and duplicate pools change the comparison

Quote assets determine which reserves and prices belong to a pair. One Ethereum token might trade against WETH and USDC on Uniswap, while a Solana token might trade against Wrapped SOL and USDC through Raydium or Orca.

Those assets also use different base-unit precision. USDC uses 6 decimals, meaning one token unit contains 1,000,000 base units. WETH uses 18 decimals, so one token unit contains 10 ¹⁸ base units. SOL uses 9 decimals, and one SOL equals 1,000,000,000 lamports. Dexscreener normalizes reported pool values into USD, but the underlying reserves remain separate on-chain quantities.

Apply the liquidity threshold to pair records, not ticker symbols. The same ticker can appear in multiple pools, on multiple protocols, or through separate deployments on Base and Arbitrum. Pair address, chain, decentralized exchange, base token, and quote token identify the actual market being filtered. A token-level assumption cannot merge those independent pools.

Sorting decides which filtered result appears first

Sorting changes the order of qualifying pairs without changing which pairs qualify. Filters control membership; the selected ranking field and its direction control presentation.

Ascending pair age places the youngest qualifying pair first. Descending pair age places the oldest first. Descending liquidity prioritizes the largest reported pools, while descending 24H volume prioritizes the greatest recorded value for that interval. The two order directions answer different questions, even when every filter value stays fixed.

Preset views include Newest plus 1H, 6H, 24H, 3D, and 7D horizons. Column customization changes which measurements remain visible, not the meaning of the active thresholds. Hold the chain, filters, time window, and rank key constant when comparing successive refreshes. Otherwise, a changed order may look like changed eligibility (more in Dexscreener alerts ).

The pair-record model behind the screen

The Dexscreener data model evaluates indexed pair records. Each record identifies a chain, decentralized exchange, pair address, base token, quote token, price data, time-bucketed volume, buy and sell counts, liquidity, and a pair-creation timestamp.

The documented token-address batch accepts up to 30 addresses, while pair and token lookup endpoints allow 300 requests per minute. Those API limits matter to automated screens, although the public interface handles its own requests. The underlying distinction remains the same: records belong to pools, not abstract ticker symbols.

Automatic discovery also starts at the pair level. A token enters the index after it has been added to a liquidity pool and the pool has at least 1 transaction. A minimum-liquidity condition cannot admit a record with no comparable USD liquidity value. Likewise, age sorting requires the pair timestamp, and activity thresholds require data for the selected interval. Missing pair data therefore changes eligibility before ranking begins.

Common questions about Dexscreener filters

What happens if live liquidity falls below the selected minimum?

The pair stops qualifying once refreshed data places its reported liquidity below the active minimum. Liquidity changes as reserves move, liquidity providers change positions, and the assets' dollar values change. A pair that passed earlier is not permanently included. Refreshing the same screen can therefore remove it without any change to the age threshold or sorting direction.

Is market capitalization a substitute for a minimum-liquidity filter?

Market capitalization is not a substitute for pool liquidity. Market capitalization relates token price to circulating supply, while fully diluted valuation uses the relevant total supply measure. Liquidity describes assets assigned to one trading pool. A token can display a large valuation beside a much smaller pool, so valuation and liquidity thresholds answer separate screening questions.

How should a missing USD liquidity value affect the screen?

A pair without a comparable USD liquidity value should not satisfy a numeric liquidity minimum. The record lacks the measurement needed for the threshold test. It may still show token, price, or activity fields, but those values do not reconstruct pool liquidity. Remove the minimum only when the research task deliberately includes records with incomplete liquidity data.

Does adding liquidity reset the age of an existing pair?

Adding reserves to an existing pool does not reset that pair's age. The pair retains its address and creation timestamp while its liquidity value changes. A newly created pool receives a different pair address and its own age, even when it uses the same two tokens and operates through the same decentralized-exchange protocol.

When is an FDV ceiling useful beside a liquidity minimum?

An FDV ceiling is useful when the shortlist must satisfy both a valuation range and a pool-depth requirement. Fully diluted valuation and liquidity remain independent measurements: one derives from supply and price, while the other reflects assets in a specific pool. Applying both conditions excludes pairs that meet only the depth rule or only the valuation rule.

Are Profile, Boosted, Ads, and Launchpad labels liquidity signals?

Profile, Boosted, Ads, and Launchpad labels are not measurements of pool liquidity. They describe separate listing, promotional, informational, or launch-related attributes. A pair carrying one of those labels still has to meet the chosen liquidity, age, volume, and transaction conditions. Do not convert a label into an assumed reserve amount or activity threshold.

Will price-change filters improve an age-and-liquidity screen?

Price-change filters add a momentum condition, not a quality score. They compare prices across the selected interval, and a very young pair may have little baseline history for longer windows. Apply the liquidity and age gates first, match the price-change interval to the activity window, and treat the percentage as a separate observation from volume and pool depth.

First published 2 Aug 2026