Manufactured pumps on pump.fun: detection, anatomy, and why there is no exit

LaunchWatch research note · data through 2026-10-17 UTC · live numbers update every minute

Summary

A recurring class of pump.fun tokens is pushed up by bots in an almost perfectly straight line and then emptied in a single block. Since 2026-09-05 we have automatically flagged 2,536 such tokens; of the resolved cases, 85% ended in a collapse, a median 31 minutes after detection (quartiles 13–71 min, fastest -1473 min). Reconstructing four collapses second by second from the chain shows the price going from “normal” to −99% inside one second, executed by dozens of wallets in the same block. No sell rule reacting to price can escape it; the expected value of holding these tokens for any duration is negative. This page documents the data, the method, the evidence, and its limits.

1. Data and method

• Observation. A single observer node streams pump.fun token creations and trades from Solana (via an RPC provider), builds 1-minute candles (open/high/low/close, SOL volume, buy and sell counts), and keeps tracking tokens that stay active about an hour after launch with a meaningful reserve (“promoted” tokens). Everything below is derived from that data.
• Detection (“manufactured”). Shortly after tracking starts, at least 8 consecutive 1-minute bars rise at a near-constant slope (linear fit R² ≥ 0.98, typically +0.2…+0.5% per minute). Organic price series essentially never look like this. Detection therefore lags the start of the pattern by at least 8 minutes.
• Collapse. A 1-minute bar whose low is below 40% of the previous close. This isolates the single-block dump from ordinary declines.
• Resolution. A detection is “resolved” when it collapsed, when tracking ended, or 6 hours after detection. Unresolved cases are excluded from rates.

2. Prevalence and fate

2,536 detections so far; 2,150 collapsed; 384 resolved without a single-block collapse (they faded or stayed flat).

3. Anatomy of a collapse (on-chain reconstruction, as of 2026-09-06)

We fetched every transaction around the collapse minute for four tokens and computed each trade’s price from the signer’s SOL and token balance changes.

CRC FacSteJw… — 2026-09-04 21:42:37 UTC

ARROW NsMRYw7g… — 2026-09-04 17:25:23 UTC

Aster LGkXjkFp… — 2026-09-04 14:47:34 UTC

WOTF JbrFD1MT… — 2026-09-05 02:16:17 UTC

Two of the four show exactly 44 selling wallets in the same block — the signature of one bundled tool. The third is a large holder selling in a few steps (−81% in the first second). The fourth moved −98% on only 5 SOL of sells: the liquidity was withdrawn.

4. The painted chart

During the climb, the tape is dominated by tiny, evenly spaced trades. In the CRC case: about 2 buys and ~80 sells per minute, ~70 SOL/min of volume, price +0.3%/min with almost no variance. Buys are the operator’s own; the many small sells are wash trades that keep the token on “active” lists. Three minutes before the ARROW dump the sell count jumped to ~1,000/min while price kept rising — a warning sign in hindsight, but not one that holds reliably across cases.

What the fingerprint looks like, on real data (1-minute candles from the detector's example files):

5. Why holding has negative expected value (analysis as of 2026-09-06, n=557)

Suppose you buy at detection and sell after a fixed time. The climb yields a median +0.42%/min; a round trip costs ~1.2% (measured on 45 real trades); a collapse costs ~98%. Using the empirical collapse probabilities:

Every holding period loses. The per-minute gain (0.4%) is smaller than the per-minute expected loss from collapse (0.5–0.9%). Trailing stops, volume-climax rules or “sell on first red candle” do not help: the drop is inside one block.

6. Operator economics (upper bound)

The SOL pulled out in the collapse second was ~1,011 SOL (CRC), ~2,208 SOL (ARROW) and ~350 SOL (Aster). Part of that is the operator’s own SOL used to paint the chart, so it is an upper bound on profit; the operator’s true profit equals the net inflow from outsiders — mostly momentum bots attracted by the straight line. Failed attempts (no outside buyers) extract almost nothing, which is why the same operators relaunch the same tickers dozens of times.

7. Reused names (live)

8. Limitations

• Detection needs ≥8 minutes of pattern; buyers who enter in the first minutes are not warned in time.
• About 15% of resolved detections did not collapse in a single block (they faded). Not every flagged token is dumped; every flagged token is manufactured.
• Only tokens that reach our tracking criteria are observed; a token absent from the list is not known to be safe.
• Single observer, 1-minute resolution, one RPC provider. Timestamps are UTC.

9. What we are building next

1. Instant public alerts (X / Telegram) at the moment of detection, with the mint and chart.
2. Operator fingerprints: publish the wallets that dumped in the same block and the deployer wallets, so a relaunch can be flagged at creation instead of 8 minutes later.
3. A machine-readable feed (already at /data/orchestrated.json) offered to wallets, scanners and aggregators. The detector is open source (launchwatch-detector, MIT; mirror on GitLab) so others can verify and reuse the method.

Reproducibility & contact

Live dashboard: launchwatch.dev. Feed: /data/orchestrated.json. Source code: launchwatch/launchwatch-detector (MIT; mirror: GitLab; PyPI: pip install launchwatch-detector). Contact: [email protected] · X @launchwatchdev · GitHub launchwatch.