A Helius webhook watches three Solana pool programs (Raydium AMM v4, Raydium CPMM, PumpSwap). The instant a new liquidity pool is created, it posts here. In practice almost everything is a pump.fun migration.
Each new mint waits 60 seconds (so the data providers have indexed it), then gets measured. That first measurement is the entry snapshot — the moment every "would this filter have worked?" question is asked against.
Every token is stored, pass or fail. Failed ones are the negative samples — without them you cannot tell whether a filter means anything.
Snapshots repeat at t+10m, t+1h, t+6h and t+24h. On top of that, every token is polled on a two-speed cadence for its first hour — every 20 seconds for the first 10 minutes, then every minute to the hour — recording price, liquidity and buy/sell counts. The first minutes get the fine resolution because that is where the decision would be made and where most peaks begin. That path is what separates a coin that ran 4x at minute 12 and died by minute 40 from one that never moved: identical in snapshots alone.
Safety (hard fails, any one stops the token): mint authority revoked, freeze authority revoked, LP burned or locked, RugCheck score under 3000.
Quality (all recorded, none blocking): liquidity ≥ $30k, holders ≥ 100, top-10 concentration ≤ 30%, volume ≥ $50k, volume/liquidity ≥ 0.5.
The data says these filters are, at this timing, inverted: tokens that look clean 60 seconds after launch perform worse, because instant polish is the fingerprint of a scripted launch. Only 3.6% of the best performers passed the safety filters, versus 11% of everything else. The filters are kept unchanged so the dataset keeps measuring them honestly — they are not a recommendation.
A multiple is the price at a horizon divided by the entry price. Two rules matter:
Multiples above 100x are treated as data errors and excluded. In the coin table below,
peak is the best price seen during the first hour — a peak you could only have
captured by exiting at exactly the right minute.
Across ~16,800 tokens: the median token is worth 0x an hour after launch, the average is 0.46x, and 96.8% are a near-total loss by 24 hours. About 37.9% touch 2x at some point in their first hour while still tradeable — the opportunities are real — but the median token then hands back 100% of its run, and only a quarter keep even half their peak.
Ten exit rules were simulated over 11,347 fully-tracked hours, charging a round-trip cost and requiring real pool depth to sell into. Every rule loses money, in every segment: best overall is 0.67x, and the most promising slice (liquidity $10–20k with unlocked LP) tops out at 0.96x. Waiting five minutes and judging a coin on its own early momentum, liquidity growth and buy pressure does not rescue it either — tested with a time-based train/test split, that returns 0.65x on the training half and 0.64x on unseen later tokens.
The strongest signal remains the twin flag: coins whose entry metrics duplicate another recent launch (8.7% of all coins) average 0.06x and are a near-total loss 98.5% of the time. It is a good exclusion rule; it is not, on its own, a strategy.
Two corrections worth knowing about, because both once pointed the other way: settling a trade at the last price seen before a pool died — instead of holding to the end of the window — turned a 0.64x result into a fake 1.18x. And requiring tokens to have stayed liquid to qualify for the sample turned a losing set of rules into an apparently profitable one. Survivorship and hindsight both flatter results here; every number above is computed the strict way.
Every strategy in the simulation section is replayed over the recorded first-hour price paths, coin by coin, in the order they launched. The rules are strict on purpose:
The chart line is the running answer to "if the experiment stopped today, what would my €100 be worth?" — €100 spread evenly across every coin traded so far. The perfect foresight row sells every coin at its exact liquid peak; it is impossible to trade, and is shown only to prove the opportunities exist even though no rule captures them.
You can restrict the simulation to coins meeting entry criteria — liquidity, market cap, holders, LP status, trade count, twins. Everything filterable is measured at t+60s, so it is all knowable before buying; nothing uses information from the future.
Searching for a filter that makes a strategy profitable is the single easiest way to fool yourself. Test enough combinations and one will look excellent purely by luck. Three defences run on every criterion, and a result must pass all three:
The count of combinations searched is displayed with the results, because "the best of 220" is a far weaker claim than "beat the baseline".
The Find the best filter button runs an optimizer over thresholds (liquidity, market cap, holders, trade count), categorical choices (LP status, safety, twins, deployer history) and all ten exit rules. It uses random restarts followed by hill-climbing: repeatedly change one setting at a time and keep the change if the score improves.
By default it maximises a cautious objective — the average minus one standard error — rather than the raw return. Maximising the raw return rewards filters that keep only a few dozen coins, where one lucky coin decides everything. The cautious objective makes shrinking the sample cost score, so a solid result beats a spectacular fragile one. You can switch to the raw objective to see that effect for yourself.
The important part. An optimizer over millions of filters will always return something profitable-looking — that is what searching does, and it is true even when the data contains no signal whatsoever. So the search is run twice: once on the real data, and again on data whose outcomes have been shuffled between coins, destroying any real relationship between what a coin looked like and how it did. Whatever the optimizer scores on the shuffled version is what this much searching manufactures out of nothing. A discovered filter is only interesting if it beats that, and holds up on the half of the coins the search never saw, and has an error bar clear of €100.
The card reports all of it: the training score, the held-out score, the gap between them (the optimism — how much was fitted to noise), the same exit rule with no filter at all (what the filter actually added), and the shuffled-data distribution.
Every coin is deployed by a wallet, and that wallet often launches more than one. For each coin we record its deployer, then ask what that wallet's earlier coins did — whether it has launched before, whether all its previous coins died, whether one ever reached 2x.
The rule that makes this honest: a coin's deployer features are built only from launches detected before that coin was. A wallet's later launches are invisible to its earlier ones. Using the wallet's full record would be buying on information that did not exist yet, and would invent an edge out of nothing.
Two limits to keep in mind when reading these rows:
deployer known at all row: that is the fair
baseline for every deployer criterion. Coins whose wallet is unknown are left out of deployer
criteria entirely — "we don't know who deployed this" is not the same claim as "this wallet
has no history", and the two are never merged.This is one market period, and correlation only. Nothing here is a trading recommendation; the scanner holds no keys and places no trades — the €100 is simulated.
Restrict the simulation to coins matching these entry criteria — everything here is measured at t+60s, so it is all knowable before buying. Thresholds are in USD (the data's unit); the stake is €100.
Searches thousands of combinations of thresholds and exit rules for the one that performs best — using only the earlier half of the coins, then scoring it on the later half it never saw. It also runs the identical search on shuffled outcomes, where any relationship between a coin's entry data and its result has been destroyed on purpose. That tells you what this much searching finds in data with nothing in it — the number the discovered filter has to beat before it means anything.
Each strategy gets €100, spread evenly over … coins with a fully-tracked first hour: buy every coin at t+60s, exit by the rule. Every trade pays a 3% round-trip cost and can only sell while the pool still holds ≥ $2,000 — a price quoted by a drained pool settles at €0. The line marks getting your €100 back; red bars fall short of it.
Each line reads "what my €100 would be worth if the experiment had stopped that day". Flat lines well below €100 mean the result is not one unlucky stretch — it was the same answer on day one. Four representative strategies; hover for values. Only days that actually collected appear, spaced evenly, so a gap in collection is not shown as elapsed time.
Win rate is the share of coins that returned more than the stake. "~total loss" is the share that came back worth under a tenth of it. Train and test split the coins by time: the earlier half and the later half. A strategy that only works on one of them is fitted to noise.
Every criterion below is scored honestly: its best exit rule is chosen using only the earlier half of the coins, then scored on the later half it has never seen. Read the test column, not the train one. Three checks must all pass before a criterion means anything — it must beat €100 out of sample, still beat it with its single luckiest coin deleted, and have an error bar that does not touch €100. The last column runs a fourth check automatically: comparing the criterion inside matched bands of liquidity and market cap. A criterion that only separates outcomes across size bands is describing launch size, not adding anything — which is precisely how the deployer-history signal fell apart despite a perfect gradient.
Median multiple per group. Bars right of the line beat break-even (1x); red bars lost money. Last 7 days, groups under 5 tokens hidden. Trade-count rows only cover tokens collected since buy/sell capture was added.
Realizable multiple vs entry: a pool below the tradability floor settles at 0x even when a price is still quoted, because nobody can sell into it.
Share of tokens still trading (liquidity above $500) at each checkpoint. Log-spaced time axis.
Last 24 hours, by price multiple vs entry.
Outcomes are realizable — a drained pool settles at 0x however it is still quoted. Blank means the snapshot has not been taken yet.
Gaps mean the scanner was not collecting.