Launch Tape

Blog ยท

Filters people swear by, and how to check them

Bundles, fast curve fills, the dev wallet, time of day. Every bot builder hears filter rules. Here is how to test one against outcomes instead of trusting it.

Spend a day in any memecoin trading chat and you will collect a list of rules. Skip coins that filled their curve too fast, it is a bundle. Skip coins where the dev sold. Do not trade at night. Some of these rules are probably useful. Some are folklore. Most have never been checked.

The good news is that checking one is not hard. You do not need to trust anyone, us included. You need outcomes and a few lines of code.

The common ones

A few filters you will hear a lot:

  • Bundles / fast curve fills: if the bonding curve filled within seconds, a group probably bought it together and will dump on you.
  • Dev wallet still holding: a creator who kept their tokens has a reason to stay; one who already sold does not.
  • Time of day: some hours are "rug hours", others are safer.

Each of these sounds reasonable. That is exactly why they need testing: a rule that sounds reasonable spreads whether or not it works.

Takeaway: a filter is a claim. Treat it like one.

Decide what "bad" means first

Before you test a filter, write down the outcome you are trying to avoid, in a way a computer can count. "Rugs" is not countable. These are:

  • touched -80% within 10 minutes of graduation
  • touched 2x within 10 minutes
  • your actual rule's return a trade, with honest fills

Pick one before you look at the results. If you pick the outcome after seeing which one makes your filter look good, you are not testing the filter any more.

Takeaway: define the outcome before you split the coins.

Split, count, compare

The test itself is simple. Split the coins into two groups by the filter, and compare the outcome rate in each group.

fast = [c for c in coins if c.curve_fill_s < 5]
slow = [c for c in coins if c.curve_fill_s >= 5]

def rate(group, test):
    return sum(test(c) for c in group) / len(group)

touched_80 = lambda c: c.min_drop <= -80
touched_2x = lambda c: c.max_gain >= 100

for name, g in [("fast", fast), ("slow", slow)]:
    print(name, len(g), rate(g, touched_80), rate(g, touched_2x))

Always print the group sizes. A filter that looks great on 12 coins is a coin flip.

Takeaway: a filter only matters if the two groups really differ, on enough coins to mean something.

One we checked: fast curve fills

Here is the "fast fill = bundle = rug" rule, on our own recordings of pump.fun graduates from October 10 to 12, 2026. Coins whose curve filled within 5 seconds of creation (1,384 coins) touched -80% in the first 10 minutes 38.4% of the time. Slower fills (803 coins) did it 37.6% of the time.

That is no real difference. On this outcome, the filter does nothing.

But the slower fills touched 2x much more often, roughly three times as often as the fast ones. So the slow coins were not safer. They were more volatile: they went up a lot more often, and fell about as often.

Takeaway: if you had used this filter as a rug shield, you would have skipped many of the coins that ran, and kept the rug risk.

The honest lesson: filters flag volatility, not just rugs

This pattern is common. A feature that "predicts crashes" often just predicts movement, both directions. If you only look at the downside, it looks like a safety filter. When you look at both sides, it turns out to be a volatility switch.

That is not useless. A volatility switch can be exactly what a strategy needs, depending on what it does with the up moves. But it is a different tool from what the rule promised, and you only find that out by measuring both sides.

Takeaway: always check a filter against the upside too, not just the crash rate.

Check the dev wallet and the clock the same way

The same three steps work for the others. For the dev wallet, split by the creator's share at graduation (say, above or below 5%) and compare touched -80% and touched 2x. For time of day, group coins by hour (in UTC, so you do not mix time zones) and look at the rates per hour, with the count next to each one.

When an hour has few graduates, its rate will jump around. Do not build a rule on one strange hour.

Takeaway: same method, any filter. Split, count, compare both sides, print the sizes.

Then test it in a strategy

A difference in outcome rates is a starting point, not a result. The real test is whether adding the filter improves your strategy's return a trade, with honest fills and fees, on days you did not look at while choosing the filter.

Better filters than the folklore might exist. Some of the rules people swear by may even hold up. Testing them honestly is how you find out which.

If you want to try this on real outcomes, the free graduates CSV has curve fill times, creator holdings and 10-minute outcomes for 105 graduates on one sheet, and a full day ($10) has them for every graduate of that day.