Dexscreener filters are liquidity-first controls for new-pair screening

Dexscreener filters are pair-screening controls that set a minimum liquidity value, then narrow new listings by chain, pair age, transaction activity, volume, and valuation. A useful screen begins with the planned order size: convert that amount into an order-to-liquidity ratio, set the floor, and only then add activity gates. This sequence removes pools that are too thin for the intended research case before short-window momentum numbers influence the shortlist.

Current New Pairs controls make the queue usable

The New Pairs screen places Age, Txns, Volume, Traders, Liquidity, and MCAP beside each pair. Its Customize control turns those visible fields into a layered research queue. The current Dexscreener filters also sit beside ranking controls, chain selection, and the 5-minute, 1-hour, 6-hour, and 24-hour activity windows, which is walked through in Dexscreener alerts.

Eligibility and ranking perform separate jobs. A minimum-liquidity setting decides whether a pair enters the result set. Rank by Volume or Txns decides where an eligible pair appears. Sorting alone leaves thin pools in view, while a filter removes rows below the chosen boundary.

Fix the network before defining thresholds. Ethereum, Solana, Base, and BNB Chain differ in pool designs, quote assets, transaction costs, and launch patterns. Mixing them in one queue makes equal dollar thresholds look more comparable than the underlying markets are. Start with one chain and, where the research requires it, one decentralized exchange.

Size the liquidity floor from the planned order

A liquidity floor should be derived from the planned order rather than copied from another screen. Choose an order-to-liquidity ceiling as the intake rule. At 1%, minimum displayed liquidity equals 100 times the order. A 0.5% ceiling requires 200 times the order. These ratios measure pool capacity for screening; they do not predict execution slippage.

Displayed liquidity is the reported USD value of assets assigned to the pair. A Dexscreener row presents 2 token sides: base and quote. Actual execution also reflects the pool curve, fee tier, active price range, and order direction. Uniswap v2 uses a constant-product design. Uniswap v3, Raydium CLMM, and Orca Whirlpools concentrate liquidity within selected ranges.

Meteora DLMM distributes liquidity through price bins, so equal headline liquidity does not imply equal depth near the current price. Raydium CPMM behaves differently again. Keep the floor as a coarse capacity gate, then open each surviving pool and inspect its quoted route. Add a maximum only when the research mandate targets a defined pool-size band. Pair age becomes the next gate.

Align pair age with the measurement window

Pair age determines whether an activity window contains a complete observation. A 20-minute-old pool supplies a completed 5-minute interval, but it cannot supply full 1-hour, 6-hour, or 24-hour histories. Comparing its partial day with a pool that traded for the entire day distorts the ranking.

Set minimum age at least equal to the activity period when the task requires like-for-like evidence. A 1-hour volume screen works cleanly with a minimum age of 1 hour. Apply the same rule at 6 hours and 24 hours. When early discovery is the objective, use a maximum age instead and treat longer-window totals as incomplete observations.

Age also changes the meaning of zeroes. No sells during a short launch interval is a different state from no sells across a complete day. Keep the time basis visible while reviewing rows. Once age and measurement windows match, transaction activity becomes comparable.

Separate volume, transactions, and trader participation

Volume, Txns, and Traders describe different parts of pair activity. Volume measures the notional value swapped during the selected interval. Txns combines 2 directional buckets: buys and sells. Traders represents unique maker addresses rather than another dollar total.

A high-volume row with few transactions reflects larger average trades. Numerous transactions with modest volume reflect smaller average trades. A high transaction count with limited trader participation indicates repeated activity from a narrower address set. None of these states is interchangeable, so one threshold should not stand in for the other two.

Match all activity filters to the same interval. A 5-minute transaction condition paired with 24-hour volume answers two separate questions and produces a hard-to-interpret shortlist. Build the screen with aligned windows, then review buys and sells separately when directional balance matters. Valuation fields should enter only after liquidity and activity have passed their gates.

Use MCAP and FDV as valuation bands, not depth measures

MCAP and FDV narrow the economic size of a token; neither measures the depth of one pool. Market capitalization applies the pool price to circulating supply when that supply is available. Fully diluted valuation applies the price to total supply minus burned supply. One token can therefore show similar valuation across several pools while each pool carries different liquidity.

Decimal precision does not make two quote assets equivalent, but it explains their raw on-chain units. USDC uses 6 decimal places on Ethereum and Solana. WETH uses 18 decimal places on Ethereum. Dexscreener normalizes those units before displaying USD liquidity, volume, and valuation, so filter inputs use the displayed values rather than raw integer balances.

Apply a minimum MCAP or FDV only when the research mandate defines a valuation band. A valuation floor without a liquidity floor admits tokens whose headline size is large relative to their active pool. A maximum valuation can isolate smaller launches, yet it still says nothing about executable depth. Chain identity and pair identity complete the context.

Indexed pair records explain every filter result

An indexed pair record supplies the fields compared by the filter engine. Dexscreener parses blockchain logs and stores the chain ID, decentralized-exchange ID, pair address, base token, quote token, transaction buckets, volume, price change, liquidity, FDV, market capitalization, and pair creation time. The screen compares those records with the selected minimums and maximums.

Dexscreener lists a token automatically after it enters a liquidity pool and the pool records at least 1 transaction. That rule explains why the New Pairs queue is a pool-level feed rather than a curated token directory. Multiple pools for the same token remain separate rows because their pair addresses, quote assets, liquidity, and activity differ (more on this in Dexscreener explained ).

Identity checks need the full address. Ethereum, Base, and BNB Chain use 20-byte EVM addresses, displayed as 40 hexadecimal characters after the 0x prefix. A Solana public key is 32 bytes and appears in base58 text. ERC-20 contracts, SPL Token mints, and Token-2022 mints therefore require chain-appropriate identifiers. Etherscan, Basescan, and Solscan provide the corresponding record views.

Run the screen, verify the pair, and maintain the thresholds

A repeatable Dexscreener filter run records its conditions, verifies each surviving pair, and revisits thresholds when the research case changes. Use this decision checklist before saving a shortlist:

• Fix 1 chain and, when necessary, 1 decentralized exchange before applying value thresholds.
• Set minimum liquidity from the largest planned order and the recorded order-to-liquidity ratio.
• Require pair age to cover the chosen activity window unless incomplete launch data is intentional.
• Align Volume, Txns, Traders, buys, and sells to the same 5-minute, 1-hour, 6-hour, or 24-hour period.
• Confirm the chain, pair address, base asset, and quote asset before retaining a row.

Record the ranking field separately from the filters. A result sorted by volume differs operationally from the same eligible set sorted by age. Re-run the screen because live liquidity and activity cross fixed boundaries. Change the floor when order size or research scope changes, not merely to restore a preferred number of results.

Automated maintenance requires client-side criteria. The documented token-address endpoint accepts up to 30 comma-separated addresses per request. Pair and search routes allow 300 requests per minute, while profile-style routes allow 60. Store the threshold set, observation time, and selected window beside the returned records so later reviews can reproduce the same screen logic.

Dexscreener filters questions worth asking

Published on 6 August 2026