How to check a pump.fun dev wallet before you buy

Charts, holder counts and bundle percentages all describe a token after the fact. The one signal that exists before the first candle is the wallet that created the token. Serial devs launch dozens — sometimes tens of thousands — of tokens with the same playbook, and their track record is the single best predictor of what your launch will do. This guide shows how to check a pump.fun dev wallet before you buy: pull the full creator dossier from the Raiden API, read the score and the flags, answer "has this dev rugged before?", and wire the check into your buy path as a hard gate.

The dev is the heaviest signal in the trust score

Raiden's own risk engine puts a number on this claim. GET /tokens/{mint}/trust blends five weighted signals into a live 0–100 score (higher = safer; verdict clean ≥65, caution 40–64, likely_rug <40) — and dev reputation carries weight 0.35, more than known rug-dumpers in the token (0.25), bundled supply (0.15), wash trading (0.15) or dev exit (0.10):

{
  "mint": "9xQm…pump",
  "score": 45,
  "verdict": "caution",
  "signals": {
    "dev_score": { "value": 0, "comp": 8.4, "known": true },
    …
  },
  "weights": { "dev": 0.35, "offenders": 0.25, "bundle": 0.15, "exit": 0.10, "wash": 0.15 }
}

The same signal is pre-annotated across the API: every screener row from /tokens carries dev_score, dev_flags and dev_funder inline, so a feed of new launches arrives already labeled. But when one specific token is about to get your SOL, you want the full dossier — that is what the creator endpoints are for.

Pull the pump.fun creator history in one call

Read creator from GET /tokens/{mint}, then ask for everything Raiden knows about that wallet:

curl -H "X-API-Key: $RAIDEN_KEY" \
  "https://terminal.raiden.wtf/api/creators/5Q5q…Funr"

{
  "creator": "5Q5q…Funr",
  "stats": {
    "dev_score": 38,
    "flags": [
      { "id": "dev_dump",     "name": "Dev dumped after launch",   "category": "dev-rug" },
      { "id": "fresh_wallet", "name": "Throwaway creator wallet",  "category": "sybil" }
    ],
    "token_count": 27, "tokens_30d": 14, "tokens_per_day_30d": 0.47,
    "max_burst_10m": 3, "median_gap_s": 5400,
    "graduated_count": 1, "grad_rate": 0.037,
    "dead_count": 18, "doa_count": 9, "survival_rate": 0.11, "median_lifespan_s": 21600,
    "dev_dump_count": 4, "full_exit_count": 2, "held_clean_count": 3, "rug_events": 4,
    "bundled_launch_count": 5, "dev_in_bundle_count": 2,
    "wallet_age_days": 1.8,
    "funder": "Gm4w…9xZ2", "funder_kind": "exchange", "funder_label": "Coinbase",
    "shared_funder_degree": 31, "sibling_creators": 12, "rotation_count_30d": 3,
    "first_created_at": "2026-05-02T14:08:31Z", "last_active_at": "2026-06-26T22:13:05Z"
  },
  "funding": {
    "funder": "Gm4w…9xZ2", "funder_label": "Coinbase", "funder_kind": "exchange",
    "funded_at": "2026-05-02T13:55:12Z", "funded_lamports": 488888889
  },
  "tokens": [
    { "mint": "9xQm…pump", "symbol": "WAGMI", "status": "bonding",
      "created_at": "2026-06-26T18:42:09Z", "dev_hold_pct": 2.35,
      "dev_realized_pnl": "1284500000", "dumped": true, "ath": "0.00000311" }
  ]
}

Three blocks: the stats card (also available standalone at GET /creators/{addr}/stats), the funding origin, and the per-token tape of every launch. Amount fields like dev_realized_pnl are strings in lamports (1 SOL = 1e9).

Reading the card

No single number condemns a dev. A grad_rate of 0.037 with 27 launches is a lottery-ticket printer; the same rate with 2 launches is just a new dev. The score weighs these together — but the raw fields let you set your own policy.

Has this dev rugged before?

Four counters answer it directly. rug_events totals the launches the dev bailed on — the sum of the dump and full-exit counters that follow. dev_dump_count counts tokens the dev dumped after launch; full_exit_count, tokens where the dev sold its entire position; held_clean_count is the honest column — launches where the dev held. The flags array names the tripped patterns with an id, a human-readable name and a category (dev-rug, sybil, launch…): dev_dump ("Dev dumped after launch"), fresh_wallet ("Throwaway creator wallet"), bundle_dev ("Dev in launch bundle").

Then read the tape. Each entry in tokens[] carries dev_hold_pct (what the dev still holds), dev_realized_pnl (what the dev has already taken out, net of fees), and a per-token dumped flag. A dev showing dumped: true on its last four launches does not need interpretation. For the token-side view of the same story — which wallets dump alongside the dev in the same slot — see the full pump.fun rug check guide.

Gate your buys on the dev

The point of the dossier is to make the decision before the transaction is built. A minimal gate on dev_score and rug_events:

import requests

BASE = "https://terminal.raiden.wtf/api"
H = {"X-API-Key": "YOUR_KEY"}
MIN_SCORE = 55  # your policy — tune against your own fills

def check_dev(mint):
    creator = requests.get(f"{BASE}/tokens/{mint}", headers=H).json()["creator"]
    s = requests.get(f"{BASE}/creators/{creator}/stats", headers=H).json()

    if s["dev_score"] == -1:  # never scored — no history is also a signal
        chain = requests.get(f"{BASE}/wallets/{creator}/funding-chain", headers=H).json()["data"]
        root = chain[-1].get("funder_name") if chain else None
        return ("unknown", f"fresh wallet, root funder: {root or 'unresolved'}")

    if s["rug_events"] > 0 or s["dev_dump_count"] > 0:
        return ("reject", f"{s['rug_events']} rug events, {s['dev_dump_count']} dev dumps")

    flagged = {f["id"] for f in s["flags"]}
    if "fresh_wallet" in flagged and s["token_count"] < 3:
        return ("caution", "throwaway-wallet pattern")

    if s["dev_score"] < MIN_SCORE:
        return ("reject", f"dev_score {s['dev_score']} < {MIN_SCORE}")

    return ("accept", f"score {s['dev_score']}, grad {s['grad_rate']:.1%}, survival {s['survival_rate']:.1%}")

verdict, why = check_dev("9xQm…pump")
print(verdict, "—", why)

The order matters: rug history rejects before the score does, because a dev_score is a blend and a recorded dump is a fact. The thresholds are yours to own — the API gives you the raw counters precisely so you don't have to trust anyone else's cutoff.

A fresh wallet is not a blank slate

The dodge every serial dev uses: rotate to a new wallet, and the history resets to dev_score: -1. The counter is that SOL has to come from somewhere. The funding chain follows the money backwards from the creator wallet to its root:

curl -H "X-API-Key: $RAIDEN_KEY" \
  "https://terminal.raiden.wtf/api/wallets/8psN…VRtf/funding-chain"

{
  "data": [
    { "depth": 0, "wallet": "8psN…VRtf", "funder": "5Q5q…Funr",
      "funder_name": "Binance Hot Wallet", "funder_type": "Centralized Exchange",
      "amount": 488888889, "slot": 287654321,
      "funded_at": "2026-06-21T09:41:14Z", "no_funder": false }
  ]
}

Depth 0 is the direct funder; the chain walks up until it hits a CEX or a known entity. A fresh creator funded straight off an exchange is ambiguous. A fresh creator funded by an unlabeled intermediate wallet is worth one more call — GET /aggregates/funded-by flips the direction and lists every wallet first-funded by that funder in a time range:

curl -H "X-API-Key: $RAIDEN_KEY" \
  "https://terminal.raiden.wtf/api/aggregates/funded-by?funder=Gm4w…9xZ2&from=2026-07-01T00:00:00Z&limit=100"

{
  "funder": "Gm4w…9xZ2",
  "count": 100,
  "data": [
    { "wallet": "Bgb…VnBv", "first_time": "2026-07-20T11:11:55Z",
      "first_lamports": "19000000", "source": "helius" }
  ],
  "next_cursor": "2026-07-20T11:11:46.951127Z|5w2q…HWEz"
}

If that intermediate wallet has first-funded thirty wallets in a week and several of them are creators with rug histories, your "fresh" dev has been unmasked without ever launching a token from the new address. The card's own sybil fields — sibling_creators, shared_funder_degree, rotation_count_30d — are this exact analysis, precomputed.

A pump.fun dev wallet tracker, at scale

The single-dev check generalizes in both directions. To screen, the list endpoint GET /creators pages through every creator with the same card schema — filter with min_tokens to cut one-token spam, bound the score with min_score/max_score, or rank with sort=score|tokens|grads:

curl -H "X-API-Key: $RAIDEN_KEY" \
  "https://terminal.raiden.wtf/api/creators?sort=score&dir=desc&min_tokens=5&limit=50"

For the other tail, GET /aggregates/serial-ruggers ranks repeat-offender devs by damage: sol_extracted (the dev's realized PnL across launches, net of all fees), rug_events, dump and full-exit counts, plus compact pattern flags — spam_rate, serial_count, burst, ticker_recycle, dev_dump, full_exit. To track, put creator wallets in a wallet group and open a WebSocket stream with the creations kind and that group as dev_list_id: every new launch by any of those devs is pushed the moment it lands, with the creator attached and the dev_score when the wallet has one. Omit dev_list_id and you stream every new token on pump.fun, labeled with the dev's score whenever one exists.

The dev check is one leg of a three-legged pre-buy routine: creator history (this guide), bundle analysis of the launch itself, and the live rug check on holders and trust. All of it runs on the same pump.fun API — full endpoint reference in the API docs.