How to find insider wallets and funding clusters on Solana

A token launches. Within a few slots, twenty wallets buy in — every one of them brand new, no history, nothing shared on the surface. A holder list can't tell you whether that is twenty independent snipers or one operator with twenty masks. The funding graph can: fresh wallets are cheap, but the SOL inside them had to come from somewhere, and that origin is the one thing a sybil operation cannot randomize cheaply. This guide is a practical connected wallets checker for Solana: how to find insider wallets on a token, group them into funding clusters, and chase the operator behind them with the Raiden API.

Fresh wallets are the disguise; funding is the fingerprint

The detection logic is three conditions stacked:

• Fresh wallets — created recently, little or no trading history. Cheap to make, and precisely why insiders rotate to them.
• Wallets funded by the same wallet — each wallet's first incoming SOL transfer traces to one origin. A CEX hot wallet first-funds thousands of strangers, so a shared exchange origin means little; a shared unlabeled origin means a lot.
• Buying the same launch in the first slots — independent wallets do not coincidentally share both an origin and a same-slot entry on the same brand-new mint.

Any one condition alone is noise. All three together is one operator running a distribution play: split the stake, buy early from many addresses to fake organic demand, exit as one. Solana wallet cluster analysis is the process of testing those conditions from chain data — and every step below is a single API call.

Step 1 — one call on the token: /tokens/{mint}/funding-clusters

Given a suspicious mint, this endpoint does the whole first pass: it takes the token's early buyers and groups them by shared origin funder — the first wallet that sent each of them SOL:

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

{
  "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"]
    }
  ]
}

Read it as a ratio first: 14 of 500 early buyers share an origin. Then read the clusters. is_dev: true is the strongest possible flag — those buyers were funded by the dev wallet itself: the creator seeded fresh wallets and bought their own launch with them. That supply belongs to the dev no matter what the holder list says. A large cluster behind a non-dev funder is the other classic shape: an insider ring or a professional bundling crew, which behaves the same way at exit. Funding clusters and bundle detection are complementary views of the same play — bundling is when they bought (same block, adjacent positions), clustering is who paid for the wallets that bought.

Step 2 — walk the money backwards: /wallets/{addr}/funding-chain

Every cluster gives you a funder address. The next question is who that is. The funding chain walks first-funders back, hop by hop, until it reaches an exchange or a known entity:

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; each next row climbs one hop. Two endings matter. A chain that roots at a funder_type of "Centralized Exchange" is ambiguous on its own — everyone's SOL starts at an exchange eventually. A chain that dead-ends at an unlabeled wallet, or stacks several fresh intermediaries before the exchange, is deliberate distance: layers exist to break exactly the analysis you are running. For a quick single-call version, GET /wallets/{addr}/funding returns the origin funder plus the same-funder sibling cluster in one shot — useful when you are checking one wallet, not mapping a token. The same walk is the backbone of vetting a dev wallet before you buy: serial devs rotate addresses, but their funding roots repeat.

Step 3 — fan out from the funder: /aggregates/funded-by

The chain looks backwards; this looks forward. Given the funder you just unmasked, /aggregates/funded-by lists every wallet it first-funded in a time range — the full extent of the operation, not just the members that touched your token:

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

{
  "funder": "5tzF…uAi9",
  "funder_label": "Binance", "funder_kind": "exchange",
  "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"
}

It is keyset-paginated on (first_time, wallet) — pass next_cursor back until it comes back empty. first_lamports is the size of the first funding as a string in lamports (1 SOL = 1e9), and when the funder is a known entity, funder_label and funder_kind tell you immediately that you have hit an exchange and the trail is cold. The interesting case is the opposite: an unlabeled wallet that first-funded thirty fresh wallets in a week, several of which show up as early buyers across multiple launches. That is an operator's distribution hub, mapped.

Step 4 — confirm coordination: /related and /transfers

Shared funding says the wallets share an origin. Two more calls test whether they share behavior:

• GET /wallets/{addr}/related — wallets that trade the same token in the same slot as the target, with how many times (count) and across how many tokens (tokens). Same-slot co-entry across many mints is not something independent traders produce by accident: it is scripted coordination.
• GET /wallets/{addr}/transfers — the wallet's native SOL counterparties over the last 30 days, split into in and out, with per-counterparty totals and label/kind when the address is known (exchange, tip provider…). Cluster members that also pass SOL directly between each other, or drain to the same collection wallet, close the loop.

Python: build the cluster map for a mint

The whole pipeline — cluster the early buyers, widen each cluster to everything its funder seeded, root the funder, and spot-check same-slot coordination:

import requests

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

# 1 · group the token's early buyers by origin funder
fc = requests.get(f"{BASE}/tokens/{MINT}/funding-clusters", headers=H).json()
print(f"{fc['clustered']} of {fc['early_buyers']} early buyers share an origin funder")

cluster_map = {}
for c in fc["clusters"]:
    tag = "DEV-FUNDED" if c["is_dev"] else (c.get("funder_label") or "unlabeled")
    members = set(c["wallets"])

    # 2 · widen: every wallet the same funder FIRST-funded in the last week
    params = {"funder": c["funder"], "from": "2026-07-17T00:00:00Z", "limit": 100}
    while True:
        page = requests.get(f"{BASE}/aggregates/funded-by", params=params, headers=H).json()
        members |= {r["wallet"] for r in page["data"]}
        if not page.get("next_cursor"): break
        params["cursor"] = page["next_cursor"]

    # 3 · root the funder itself: exchange, known entity, or dead end?
    chain = requests.get(f"{BASE}/wallets/{c['funder']}/funding-chain", headers=H).json()["data"]
    root = chain[-1]["funder_name"] if chain and chain[-1].get("funder_name") else "unknown"

    cluster_map[c["funder"]] = members
    print(f"{c['funder'][:6]}  [{tag}]  {c['count']} in this token, "
          f"{len(members)} wallets seeded total, root: {root}")

# 4 · behavioral check on the biggest cluster: same-slot co-trading
biggest = max(cluster_map.values(), key=len)
probe = next(iter(biggest))
rel = requests.get(f"{BASE}/wallets/{probe}/related", headers=H).json()["data"]
hits = [r for r in rel if r["wallet"] in biggest]
for r in hits:
    print(f"{probe[:6]} ↔ {r['wallet'][:6]}: same-slot {r['count']}× across {r['tokens']} tokens")

A cluster whose funder seeded far more wallets than appear in this one token is the tell to remember: the rest of those wallets are the operator's inventory for the next launch. Save the list and you have an early-warning feed.

The shortcut: pair it with the Trust score

You do not have to run the pipeline by hand on every token. GET /tokens/{mint}/trust compresses the adjacent risk signals into a live 0–100 score (higher = safer): bundled/insider supply at launch feeds the bundled_pct signal, and same-slot coordination history powers the offender signals — ring_holding (members of serial co-dump rings currently in the token) and dumpers_holding/dumpers_sold (wallets seen in previous rug dumps). Hard signals do not just lower the score, they cap it, with capped and cap_reason telling you which one fired. Funding-cluster analysis stays its own signal, outside the score — which is exactly why GET /tokens/{mint}/pack is the practical shortcut: one call returns trust and funding_clusters side by side, with the rest of the token dossier. The full breakdown of the scoring lives in the pump.fun rug-check guide.

Every endpoint here — funding-clusters, funding-chain, funded-by, related, transfers, trust, pack — is documented with full request and response shapes in the API reference, and the Raiden API landing page covers keys and access. If the cluster you unmask traces back to the token's creator, the next read is checking the dev wallet before you buy; if it bought in the launch block itself, run the bundle checker on the same mint.