The launch tracker tells you the size of your problem in the header. At the time of writing the strip read nine of nine chains active and a displayed count of 100 out of 3,771. A hundred rows is a page you can scroll. Three thousand seven hundred and seventy one is a week of full-time reading, and the tokens at the bottom of it will be dead before you get there.
So the feed is not a list you read. It is a list you cut, and the only interesting question is the order of the cuts. Order matters more than the thresholds do, because a cut applied in the wrong position throws away exactly the rows you were trying to find, and you will never know it happened. What follows is the order I use and, more usefully, the reasoning for why each cut sits where it does.
Cut on chain first, even though it feels arbitrary
The chain filter is the first control on the page for a good reason. It is the only cut that removes rows for a reason that has nothing to do with the quality of the token, which makes it the safest thing to do first.
Nine chains are available, with Solana and the EVM chains including Ethereum, Base, Arbitrum, Optimism and Polygon among them. You are not equally able to trade all nine. You have a wallet funded on some of them and not others, you know the fee behaviour on some and not others, and you have a routing path you trust on some and not others. Cutting to the chains where you can actually execute within a few minutes is not laziness, it is removing rows you were never going to trade.
Watch the displayed count in the header as you do this, because that is the feedback loop. If turning off five chains barely moves the total, the launches are concentrated where you left them switched on and your chain cut did nothing. If it halves the number, you just did fifteen minutes of work in one click.
The one thing not to do here is cut to a single chain out of familiarity. Two or three is the useful range. One chain means you are no longer screening launches, you are screening one chain's launches, and the difference shows up as long stretches where nothing on your shortlist is worth touching.
The liquidity floor is the second cut and the largest
Second cut is a hard floor on pool liquidity, and this is where the bulk of the 3,771 disappears. The ledger scores launches on holders, liquidity, market cap and safety flags, and liquidity is the one number in that set that somebody had to actually deposit. Everything else can be manufactured cheaply.
Pick a floor in dollars, not in percentiles. My reasoning is straightforward. Whatever position size you are willing to put on, the pool needs to be at least a hundred times it, because that is roughly the depth at which a one-shot exit stays near one percent of price impact. If your working size is five hundred dollars, your floor is fifty thousand. If your working size is five thousand, your floor is half a million and your shortlist just got much shorter.
That floor is doing a second job as well. Setting up a pool with real depth costs the deployer real money, and it is money they cannot recover without the withdrawal being visible on chain. It is not proof of anything, plenty of well-funded launches go nowhere, but it is the cheapest available filter on the seriousness of the person who deployed the contract.
Why market cap has to come after liquidity, not before
Here is the ordering mistake that costs the most. Sorting or cutting by market cap early feels natural because it is the number that looks like size. Do it before the liquidity floor and you will systematically keep the worst rows in the feed.
Market cap on a day-old token is supply times last trade price, and both inputs sit with the deployer. A large supply seeded against a small amount of paired asset produces an enormous headline cap on a pool holding almost nothing. So a market cap cut applied first promotes exactly those rows to the top of your list and buries the modest launch with genuine depth behind them. You end up researching arithmetic artifacts.
Applied after the liquidity floor, the same cut becomes useful, because now every surviving row has real money behind it and the cap is telling you something about scale rather than about supply arithmetic. My preference at that point is an upper bound rather than a lower one. Above a certain cap the launch is no longer an early entry in any meaningful sense, and I would rather spend my ten slots on things that have not already been found.
Holders and contract age do the final trim
After chain and liquidity you are usually looking at something in the low hundreds. Two more cuts get to ten.
- A holder floor. Not because a high holder count is good in itself, it is trivially cheap to manufacture, but because a very low count on a token with real pool depth is a specific and bad combination. It says money went in and distribution did not follow.
- An age band. Anything under an hour or two old has not produced enough trading history to read, and anything more than a few days old is not a launch trade any more, it is a small cap trade with worse information. Cutting both ends is more effective than cutting either one.
Then sort by newest and read what is left. Ten to twenty rows is the right size for the last stage, because the last stage is not filtering, it is looking. Safety flags on the row, the shape of the holder number, whether the symbol appears more than once in the ledger, and what the paired asset is. Those checks take a couple of minutes each and there is no honest way to automate them, which is exactly why the four cuts above have to get the list down to something a human can finish.
Rerunning it without redoing it
The whole sequence is maybe fifteen minutes the first time and about three minutes after that, provided you save it. The filters panel sits alongside a templates control, and the reason to use it is not convenience. It is that a screen you rebuild from memory each session is a screen with different thresholds every session, and then you have no idea whether the shortlist changed because the market changed or because you did.
Two habits make the saved version worth more than the manual one. First, write the size assumption into the name, because a fifty thousand dollar liquidity floor is only correct for a five hundred dollar position and you will forget that within a week. Second, when a name from a shortlist works out or blows up, go back and check which cut it would have survived. Most of the time you will find the thresholds were fine and the last stage was rushed, which is an argument for cutting harder in the middle so there is more time at the end, not for adding a sixth filter.