Who bought a pump.fun token first? Snipers, insiders and real holders

The chart tells you what already happened. The first buyers tell you what happens next: a launch whose first 30 fills are dev-funded wallets and serial rug dumpers plays out very differently from one where smart money walks in and holds. This is the forensic guide to answering "who bought this pump.fun token?" — who was literally first, who paid to be first, who they are, and where they are now — with six calls to the Raiden API.

"First" is a chain fact, not a timestamp

On a hot launch, dozens of fills land in the same second — timestamps cannot order them. The chain can: every fill has a slot (~400ms) and a block_index, its exact position inside that slot's block. Sorting by (slot, block_index) is the ground truth of who bought first, second, third. Everything below is built on that ordering.

The launch tape: /tokens/{mint}/launch

Start with the launch analysis. It takes the token's earliest swaps and groups the same-slot, back-to-back rows into bundles — buys submitted together as one atomic package, usually alongside the create transaction itself. The response tells you how much supply the bundles took and which one contains the dev:

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

{
  "mint": "9xQm…pump",
  "creator": "5Q5q…Funr",
  "bundled_pct_supply": 4.88,
  "dev_bundle_pct_supply": 4.88,
  "bundle_count": 1,
  "bundles": [
    { "slot": 348812907, "start_index": 412, "size": 2,
      "is_bundle": true, "has_dev": true,
      "wallets": ["5Q5q…Funr", "8psN…VRtf"],
      "sol_total": "488888889", "tokens_bought": "48888888900000",
      "pct_supply": 4.88,
      "swaps": [
        { "trader": "5Q5q…Funr", "is_buy": true, "sol_amount": "300000000",
          "slot": 348812907, "block_index": 412, "bundled": true, … },
        { "trader": "8psN…VRtf", "is_buy": true, "sol_amount": "188888889",
          "slot": 348812907, "block_index": 413, "bundled": true, … }
      ] }
  ]
}

Read it as: has_dev: true means the creator's own buy travels inside this bundle — the wallets next to it were positioned at creation, before any outside buyer could physically react. start_index is where the bundle begins inside the block; pct_supply is what it captured. A launch where bundles take a large slice of supply is a different game from a clean one — the full methodology is in the bundle checker guide.

The full tape: /tokens/{mint}/swaps?order=asc

The launch endpoint answers "was it bundled?". For the complete first 100 buyers of a pump.fun token — bundled or not — walk the swap tape from fill #1:

curl -H "X-API-Key: $RAIDEN_KEY" \
  "https://terminal.raiden.wtf/api/tokens/9xQm…pump/swaps?order=asc&limit=200"

{
  "data": [
    { "time": "2026-06-21T09:41:14Z", "trader": "8psN…VRtf", "is_buy": true,
      "sol_amount": "488888889", "tip": "1000000", "tip_wallet": "Cb3f…g9rE",
      "cu_price": "120000", "cu_limit": "200000", "priority_fee": "24000",
      "slot": 348812909, "block_index": 41, "bundled": false,
      "router": "BSfD…bot", "sig": "4Fr4…ULFK", … }
  ],
  "next_cursor": "2026-06-21T09:41:14Z"
}

Every row answers three separate questions about a first buyer:

• Who was literally first — slot and block_index, the exact execution order. Compare against the token's created_slot (from GET /tokens/{mint}) and you get each buyer's distance from creation in slots: 0–1 slots behind is bot territory, nobody clicks that fast.
• Who paid to be first — the tip (out-of-band payment to a submission provider, with the tip_wallet it went to) and the priority_fee (cu_price in micro-lamports × cu_limit, the in-protocol auction). A wallet landing in the creation slot with a fat tip knew the launch was coming or runs always-on sniping infra. How that race is actually won is its own article: comparing wallet landing head-to-head.
• Which bot they used — router, the top-level program that orchestrated the swap (Trojan, BullX, Photon, GMGN, a custom contract…); absent means a direct call to pump.fun. Recorded for swaps after 2026-07-06. Ten first buyers all routing through the same custom program is one operator, not ten traders.

All SOL amounts are strings in lamports (1 SOL = 1e9). Add failed=1 and the tape also interleaves the attempts that landed and reverted — the snipers who raced for the same entry and lost, flagged with "failed": true.

Who are they? Three watchlists

So far you have an ordered list of addresses. The question that predicts anything — who sniped this token, and on whose behalf — takes three more calls.

1 · Dev-funded insiders — /tokens/{mint}/funding-clusters. Early buyers grouped by the wallet that originally funded them. Several first buyers sharing one origin funder is one operator behind many wallets; when that funder is the dev itself, the cluster is flagged:

{
  "early_buyers": 500,
  "clustered": 14,
  "clusters": [
    { "funder": "5Q5q…Funr", "funder_label": "Dev wallet", "count": 6,
      "is_dev": true,
      "wallets": ["8psN…VRtf", "Cb3f…g9rE", "Gm4w…9xZ2"] }
  ]
}

An is_dev: true cluster inside the first buyers means the creator financed their own "demand". The full detection method — and why funding trails are so hard to launder — is in the insider wallets guide.

2 · Known rug offenders — /tokens/{mint}/repeat-offenders. Wallets in this token that took part in previous rug dumps — they sold in the dev's dump slot (same_slot = bundled with the dev) or within a few slots after, on earlier tokens. Buyers are victims and never counted:

{
  "mint": "9xQm…pump",
  "flagged": 8,
  "data": [
    { "wallet": "6hh9…Nfew", "rug_count": 1670, "same_slot_count": 595,
      "as_operator": 0, "as_sniper": 1274, "sol_extracted": 14.21,
      "seen_in": ["$Gentlemen", "$Mosquito", "$Groundhog"],
      "seen_in_more": 15, "last_seen": "2026-07-21T13:05:11Z" }
  ]
}

rug_count is how many rugged tokens the wallet dumped in; same_slot_count how often it was bundled into the exact dump slot — the smoking gun of coordination (sol_extracted here is in SOL, not lamports). A first-buyer list studded with these wallets is a crew reassembling, and it pairs with the token-level verdict from the rug check.

3 · Smart money — /tokens/{mint}/smart. Profitable, proven wallets holding or trading this token, returned as full position objects (sol_invested, realized_pnl, token_balance…). Smart money among the first buyers is the one mix that historically deserves the word "signal" — and you can follow those wallets live.

What each mix predicts

Where are they NOW: /tokens/{mint}/holders

The last question is the one that invalidates half of all "early wallets are loaded" threads: do the first buyers still hold? The holders endpoint returns the top holders as position objects — balance, SOL in and out, realized PnL:

{
  "data": [
    { "trader": "8psN…VRtf", "token_balance": "1284000000000",
      "sol_invested": "4500000000", "sol_received": "1200000000",
      "realized_pnl": "-180000000", "avg_cost": "0.003",
      "first_trade_at": "2026-06-21T09:41:14Z", "trade_count": 7, … }
  ]
}

Join your first-buyer list against it. A first buyer absent from the holders — or with positive realized_pnl and a dusted balance — already took profit and left; their early entry is history, not overhang. First buyers still sitting on a large token_balance are the live risk (or the live conviction, if they came from the smart list).

Python: the annotated first-buyers table

One script, six endpoints, and every wallet in the first 100 buys gets its labels:

import requests

BASE = "https://terminal.raiden.wtf/api"
H = {"X-API-Key": "YOUR_KEY"}
MINT = "9xQm…pump"
N = 100

# 0 · token card — creation slot (the zero point) + the dev wallet
tok = requests.get(f"{BASE}/tokens/{MINT}", headers=H).json()
created, dev = tok["created_slot"], tok["creator"]

# 1 · first N buys, exact chain order (slot, block_index)
buys, cursor = [], None
while len(buys) < N:
    p = {"order": "asc", "limit": 200}
    if cursor: p["cursor"] = cursor
    r = requests.get(f"{BASE}/tokens/{MINT}/swaps", params=p, headers=H).json()
    buys += [s for s in r["data"] if s["is_buy"]]
    cursor = r.get("next_cursor")
    if not cursor or not r["data"]: break

# 2 · the three watchlists + current holders
fc = requests.get(f"{BASE}/tokens/{MINT}/funding-clusters", headers=H).json()
insiders  = {w: c for c in fc["clusters"] for w in c["wallets"]}
ro = requests.get(f"{BASE}/tokens/{MINT}/repeat-offenders", params={"limit": 50}, headers=H).json()
offenders = {row["wallet"]: row for row in ro["data"]}
sm = requests.get(f"{BASE}/tokens/{MINT}/smart", params={"limit": 40}, headers=H).json()
smart     = {s["trader"] for s in sm["data"]}
ho = requests.get(f"{BASE}/tokens/{MINT}/holders", params={"limit": 200}, headers=H).json()
balance   = {p["trader"]: int(p["token_balance"]) for p in ho["data"]}

# 3 · annotated table: one row per wallet, first appearance only
seen = set()
for i, s in enumerate(buys[:N], 1):
    w = s["trader"]
    if w in seen: continue
    seen.add(w)
    tags = []
    if w == dev: tags.append("DEV")
    if w in insiders:
        c = insiders[w]
        tags.append("DEV-FUNDED" if c["is_dev"] else f"CLUSTER:{c['funder'][:4]}×{c['count']}")
    if w in offenders:
        o = offenders[w]
        tags.append(f"RUG×{o['rug_count']} (same-slot {o['same_slot_count']})")
    if w in smart: tags.append("SMART")
    if balance.get(w, 0) == 0: tags.append("EXITED")
    sol  = int(s["sol_amount"]) / 1e9
    tip  = int(s.get("tip") or 0) / 1e9
    dist = s["slot"] - created
    print(f"#{i:>3}  +{dist:<3} slots  idx {s['block_index']:<4} {w[:6]}  "
          f"{sol:7.3f} SOL  tip {tip:.4f}  {s.get('router','direct')[:8]:<8}  "
          f"{' '.join(tags) or '-'}")

#  1  +0   slots  idx 412  5Q5q…   0.300 SOL  tip 0.0010  direct    DEV
#  2  +0   slots  idx 413  8psN…   0.189 SOL  tip 0.0005  direct    DEV-FUNDED
#  3  +2   slots  idx 41   6hh9…   1.500 SOL  tip 0.0100  BSfD…bot  RUG×1670 (same-slot 595) EXITED
#  4  +5   slots  idx 118  Gm4w…   0.750 SOL  tip 0.0000  direct    SMART

Four lines and the launch reads itself: a dev bundle at +0, a serial rug dumper sniping through a bot at +2 and already gone, and one smart-money wallet still holding. That is more information than any candle will ever carry.

Reading the table honestly

• +0 slots is not skill, it's access. Nobody reacts in 0 slots; creation-slot buyers were either bundled with the create or tipped their way in with foreknowledge. The launch endpoint separates the two.
• Labels compound. A wallet that is both dev-funded and a repeat offender is not two coincidences — it's the operator's dump wallet.
• EXITED changes the story. Insiders who already left are a past crime, not a present risk. Insiders still holding size are the overhang that caps every rally.
• Routers reveal crews. Many "different" first buyers on one custom router, same tip sizes, same distance from creation: one operator, many keys.
• Absence of flags is not innocence — funding clusters only catch trails that exist on-chain, and offender history only covers wallets that dumped before. Weigh the mix, don't binary it.

The same forensics run interactively on every token page of the Terminal — launch tape, funding clusters, offenders and holders side by side. The full endpoint reference is in the API docs; if you want to go from "who bought first" to "how do they keep winning the race", continue with the wallet landing comparison.