Why pump.fun tokens dump right after launch — the on-chain answer

You have watched it happen: a token launches on pump.fun, the candle goes vertical for forty seconds, then someone pulls the floor out and the chart never recovers. If you are asking why do pump.fun tokens dump immediately after launch, the answer is not sentiment, luck or "the meta". It is four specific, measurable mechanisms — and every one of them leaves a fingerprint you can query through the Raiden API before you buy.

Dumps are supply events, not mood swings

A token that dumps seconds after launch is not "losing hype". Someone who acquired tokens earlier and cheaper than the public is unloading into the first wave of buyers. The bonding curve makes this brutally efficient: the earliest buys get the lowest prices, so whoever controls the entry slots controls the exit. There are four kinds of "someone" — four dump engines — and they are not mutually exclusive. The worst launches run all four at once.

Engine 1 — bundled supply: the float was captured at creation

The most common engine. An operator funds several wallets, signs their buys together with — or immediately after — the create transaction, and captures the cheapest section of the curve across multiple wallets in the creation slot. To the naked eye the launch looks organic: a burst of different buyers. On-chain it is one hand holding a large share of the float at the lowest possible cost basis, waiting for your buy to be the exit liquidity. The "dump" is simply that supply distributing.

GET /tokens/{mint}/launch reconstructs this directly. It groups the token's first swaps into bundles — same slot, contiguous block positions — and reports bundled_pct_supply (share of supply bought by bundled wallets), dev_bundle_pct_supply (the part bought in the dev's own bundle), and for each bundle its wallet list, SOL total and pct_supply. The has_dev flag tells you whether the creator's wallet is inside the bundle — the single strongest tell that a launch was staged:

curl -H "X-API-Key: $RAIDEN_KEY" \
  "https://terminal.raiden.wtf/api/tokens/9xQm…pump/launch"

{
  "mint": "9xQm…pump",
  "creator": "5Q5q…Funr",
  "bundled_pct_supply": 38.4,
  "dev_bundle_pct_supply": 11.2,
  "bundle_count": 3,
  "bundles": [
    {
      "slot": 348812900,
      "start_index": 4,
      "size": 6,
      "is_bundle": true,
      "has_dev": true,
      "wallets": ["5Q5q…Funr", "8psN…VRtf", "Cb3f…g9rE", …],
      "sol_total": "18500000000",
      "tokens_bought": "112000000000000",
      "pct_supply": 11.2,
      "swaps": [ … ]
    },
    …
  ]
}

Cross-check with GET /tokens/{mint}/holder-stats: if top10 is most of the held supply minutes after launch, the bundle has not distributed yet — the dump is still in front of you, not behind you. The full methodology, including what a normal launch looks like as a baseline, is in the bundle checker guide.

Engine 2 — the dev exit: selling into the first pump

The classic pump.fun dev dump. The creator buys at creation — the cheapest fill the curve will ever print — waits for the first wave of buyers, and sells the position into it. No migration, no roadmap, no second act. Two data sources catch it, one live and one historical.

Live: the token's trust score (GET /tokens/{mint}/trust) carries a dev_exit signal — the share of the creator's position already sold, computed live from the creator's current position rather than a stored verdict. A value of 100.0 means the dev is fully out; when a dump is on record the response also carries dev_dump_slot, the exact slot the creator unloaded in.

Historical: devs repeat. GET /creators/{addr}/stats is the creator's rap sheet across every token they ever launched: dev_dump_count (sold into their own launch), full_exit_count (left with nothing), against held_clean_count — plus wallet_age_days, survival rate and tripped risk flags like dev_dump and fresh_wallet. A creator with 23 dev dumps across 87 tokens is not going to treat token 88 differently. You can screen at scale with GET /creators — paginated over every creator, with min_tokens to cut one-token spam and min_score / max_score filters on the 0–100 dev_score (−1 = not yet scored). The full workflow is in how to check a pump.fun dev wallet.

Engine 3 — sniper rotation: in at the creation slot, out minutes later

Not every early seller is an insider. A layer of professional snipers watches every creation and lands buys within the first slots — then exits minutes later regardless of how the token is doing, because rotation is the strategy: recycle the SOL into the next launch, collect the spread between the curve's floor and the first wave of retail, repeat hundreds of times a day. These are the pump.fun sniper dumps: mechanical, unemotional, and enough on their own to cap a thin launch.

You can identify the type from both ends. From the token side, the earliest rows of /tokens/{mint}/launch show who filled in the creation slot and the slots right after — slot and block_index on every swap. From the wallet side, GET /wallets/{addr}/stats profiles the behavior over the wallet's whole history:

When the first ten buyers of a launch all profile like that row, the first red candle is already scheduled — they were never going to hold. How these wallets win the entry race in the first place (tips, priority fees, slot leaders) is its own story: comparing wallet landing head-to-head.

Engine 4 — repeat-offender rings: dumping in the dev's exact slot

The darkest engine, and the least visible from a chart. Across confirmed rugs, the same wallets keep selling inside the dev's dump window — the dev's exact slot, or the two slots (~800ms) right after. Selling in the same slot as the dev is not reaction speed; at ~400ms per slot it means the exit was signed together with the dev's dump. These wallets form reusable rings that move from rug to rug, and their presence in a fresh token is one of the strongest forward-looking dump signals that exists.

GET /tokens/{mint}/repeat-offenders answers the only question that matters: are any of them in this token? The response carries a this_token block (rugged, dev_dump_slot, co_dumpers, same_slot) and one row per flagged wallet: rug_count and same_slot_count across its history, the as_operator / as_sniper split (rugs it ran as the creator itself vs rugs it entered sniping the first slots of the launch), sol_extracted (in SOL), and seen_in — sample tokens it dumped before. Buyers are victims and are never counted. For any single wallet, GET /wallets/{addr}/dumps is the full paginated rap sheet — every rugged token it took part in, filterable with same_slot=1, with an all-time summary on the first page. How this feeds a complete pre-buy safety check is covered in the pump.fun rug check guide.

How to pre-read a launch in 30 seconds

You do not need a research desk to avoid the obvious dumps. Three data points cover all four engines:

• 1 · The trust verdict. GET /tokens/{mint}/trust is a live 0–100 risk score (higher = safer) blending five weighted signals: dev reputation, known rug-dumpers currently in the token, bundled/insider supply, dev exit and wash trading. verdict is clean (score ≥65), caution (40–64) or likely_rug (<40), and capped/cap_reason tell you when one hard signal forced the ceiling down.
• 2 · The bundle %. bundled_pct_supply and has_dev from /tokens/{mint}/launch — engine 1 in two numbers.
• 3 · The dev card. dev_score, dev_dump_count, full_exit_count and wallet_age_days from /creators/{addr}/stats — engine 2 before it happens.

curl -H "X-API-Key: $RAIDEN_KEY" \
  "https://terminal.raiden.wtf/api/tokens/9xQm…pump/trust"

{
  "mint": "9xQm…pump",
  "score": 31,
  "verdict": "likely_rug",
  "capped": true,
  "cap_reason": "bundled",
  "rugged": false,
  "signals": {
    "dev_score":       { "value": 12,    "comp": 9.1,  "known": true },
    "dumpers_holding": { "value": 4,     "comp": 12.5, "known": true },
    "dumpers_sold":    { "value": 2,     "comp": 8.0,  "known": true },
    "ring_holding":    { "value": 1,     "comp": 15.0, "known": true },
    "bundled_pct":     { "value": 38.4,  "comp": 3.2,  "known": true },
    "dev_exit":        { "value": 100.0, "comp": 6.1,  "known": true },
    "wash_pct":        { "value": 9.4,   "comp": 1.1,  "known": true }
  },
  "dev_dump_slot": 434305434,
  "weights": { "dev": 0.35, "offenders": 0.25, "bundle": 0.15, "exit": 0.10, "wash": 0.15 }
}

Every signal reports its raw value and its contribution (comp) to the score, so you always know why a token scored the way it did. And the two token-side calls collapse into one: GET /tokens/{mint}/pack returns the token, launch, holder_stats, trust and repeat_offenders (plus activity, smart money, wash traders and funding clusters) in a single response — the whole token dossier assembled server-side. Only the dev card stays its own call.

The four engines are not exotic edge cases — on pump.fun they are the default, and "why did it dump" almost always decomposes into some mix of them. The difference between guessing and knowing is a couple of API calls. The exact request and response for every endpoint above is in the API reference; keys are issued through the Raiden pump.fun API page. To go deeper on each engine: the bundle checker, the dev wallet check and the full rug check guides pick up where this one stops.