Dexscreener filters are pair-age and liquidity gates for token screening

New Pairs now surfaces age beside four activity windows

Equally, Dexscreener's New Pairs feed places pair age and liquidity alongside recent market activity, making both fields useful as first-pass controls. The screen displays 5-minute, 1-hour, 6-hour, and 24-hour activity windows while Age continues to represent the lifetime of the individual pool, which is walked through in Dexscreener alerts.

The visible New Pairs preset uses an age ceiling of 24 hours and a liquidity floor above $1,000. These are discovery boundaries rather than universal trading thresholds. Changing the chain, market conditions, or intended order size changes how selective that combination becomes.

Filtering and ranking perform separate jobs. An age filter decides which pairs remain eligible, whereas the Newest ranking orders eligible pairs from the smallest age upward. A liquidity sort can place deeper pools first without admitting any pool that failed the chosen age or liquidity boundary. Keeping those operations separate prevents a sorted list from being mistaken for a filtered one, as covered in Using Dexscreener.

Pair age measures pool creation, not token deployment

Pair age in Dexscreener measures time since a specific trading pair was created, not time since its token contract was deployed. An ERC-20 token on Ethereum or an SPL Token on Solana can therefore have an old contract and a newly created pool.

The distinction becomes important when one asset trades through several venues. A token might have separate WETH pools on Uniswap v2 and Uniswap v3, or separate SOL and USDC markets on Raydium and Orca. Each pool receives its own creation time, liquidity value, transaction history, and chart.

One hour equals 60 minutes, 24 hours equals 1,440 minutes, and 7 days equals 168 hours. A minimum-age boundary removes pools that have not existed long enough for the intended observation period. A maximum-age boundary removes pools after they cross the selected horizon. The displayed age advances continuously even when the underlying token contract remains unchanged.

Liquidity is a screening floor, not an execution quote

The liquidity filter evaluates a pair-level estimate expressed in US dollars at the time the screen updates. It creates a common comparison value across SOL/USDC, WETH/USDC, WBNB/USDT, and other markets whose native asset quantities use different units.

Every pair contains 2 assets, while the pair-data structure separates liquidity into 3 fields: a USD estimate, a base-token amount, and a quote-token amount. Unit precision also differs. WETH on Ethereum uses 18 decimal places, native SOL uses 9, and native USDC on Ethereum and Solana uses 6. Dexscreener normalizes those quantities for the Liquidity column rather than comparing raw token balances.

Pool value is not identical to immediately usable depth at every price. Uniswap v2 and PancakeSwap v2 spread reserves across a constant-product curve, while Uniswap v3, Orca Whirlpools, and Raydium CLMM support concentrated positions. Liquidity placed outside the active price range contributes differently to execution. The screen's USD figure is therefore a strong exclusion tool, but an order still needs a pool-specific price-impact check.

Building a two-filter band without erasing the field

A pair-age band and a minimum-liquidity floor should express one discovery horizon and one depth requirement. Set the chain and age boundary first, observe the remaining field, and then introduce liquidity. When both values change at once, an empty screen does not reveal which boundary removed the candidates.

Dexscreener filters become easier to tune when selectivity is measured explicitly. A narrow age ceiling favors immediate discovery, while a minimum age preserves time for observable transactions to accumulate. Raising the liquidity floor reduces the number of thin markets, but it also removes new pools that have not yet attracted substantial deposits.

Worked example - every changing input is hypothetical. Suppose a hypothetical Solana feed begins with 2,400 pairs. A hypothetical maximum age of 24 hours leaves 360 pairs, and a hypothetical $25,000 minimum-liquidity floor reduces that set to 54. The combined hypothetical screen therefore retains 54 of 2,400 pairs, or 2.25%, and excludes 2,346. Sorting those 54 pairs by age changes their order, not the final count.

That calculation measures how aggressively the screen narrows its universe. It does not turn either boundary into a quality score. If too few pairs remain, loosen one condition and compare the new count before changing the other.

Chain and venue selection changes the threshold's meaning

Chain selection defines the universe in which an age or liquidity threshold operates. Ethereum uses chain ID 1, Base uses 8453, Arbitrum One uses 42161, BNB Smart Chain uses 56, and Polygon PoS uses 137; Dexscreener keeps their pair feeds separate.

The same dollar floor produces different candidate sets across those networks because pools, quote assets, and decentralized exchanges differ. Uniswap markets span Ethereum, Base, and Arbitrum, PancakeSwap is prominent on BNB Smart Chain, and Raydium, Orca, and Meteora serve distinct Solana pool designs. A threshold does not normalize transaction costs, pool concentration, or venue mechanics.

Quote assets also affect how a survivor should be read. USDC and USDT pairs express value through stablecoin reserves, while WETH, WBNB, or SOL pairs inherit movements from the quote asset as well as the base token. The USD liquidity filter makes these markets comparable at the screening stage, but it does not make their reserve structures interchangeable.

Read activity only after age and liquidity have qualified the pair

The filtered pair list still needs activity context before one market is prioritized over another. Dexscreener shows volume, transaction counts, traders, buys, sells, and price changes across the same 5-minute, 1-hour, 6-hour, and 24-hour windows.

Buys and sells form 2 transaction directions, but their counts do not reveal order size. High volume with few transactions describes a different flow from many transactions with modest volume. Trader count adds another dimension by distinguishing repeated activity from participation spread across more addresses, subject to the way each chain's transactions are indexed.

Age and liquidity should remain visible while those faster metrics are read. A 5-minute burst has different significance in a 20-minute pool than in a 20-day pool. Sorting by ascending age emphasizes the earliest qualifying markets; sorting by descending liquidity emphasizes depth. Neither sort alters the boundaries imposed by Dexscreener filters.

From screen settings to repeatable pair research

The Dexscreener API exposes pair creation and liquidity fields for repeatable research on known tokens or pools. Pair records include an integer pairCreatedAt value plus USD, base-token, and quote-token liquidity values, allowing the browser's two-filter logic to be reproduced outside the visual feed.

The public pair endpoints are not a bulk replacement for the interactive New Pairs screener. A research process first obtains known pair records, calculates age from pairCreatedAt, and tests liquidity.usd against its chosen boundary. The token-address endpoint accepts up to 30 comma-separated addresses and is limited to 300 requests per minute. Separate profile, advertisement, boost, and order endpoints use a 60-request-per-minute limit.

Either way, Dexscreener automatically indexes a token after it has been added to a liquidity pool and the pool has recorded at least 1 transaction. Search accepts 4 useful identifier types: token name, symbol, token address, and pair address. Address-based matching is the precise route when several assets share a ticker or one token has multiple pools. The browser remains efficient for live triage, while structured pair records support consistent, repeatable filtering.