DEV Community: Dexra

One wallet paid for six of the first fifteen buyers: tracing launch funding on Solana

Dexra — Wed, 28 Oct 2026 10:17:48 +0000

A launch with fifteen eager buyers in its first seconds looks like demand. Sometimes it is fifteen wallets controlled by one person. On Solana you can often tell the difference before you buy, because fresh wallets have to get their first SOL from somewhere, and that first transaction stays on chain.

This post walks through the check with plain RPC calls on a real launch from today, then shows the one-call version, and ends with what the signal is actually worth, because it is less than it looks.

The launch

PumpSwap pool 2oFcPB4htz6Rua9meUNpUJ7uRJP6ZNF9nNoijyBhLGMr for the pump.fun mint EdK8J369Aktt4s8JhygFjdNEWF8KBU1F1ekkzkRDpump was created at 11:14:43 UTC on 2026-10-27, in slot 462049744. Its SOL reserve peaked at 217 SOL. By 11:29:59 UTC it held 1.8 SOL.

The question for a bot is not what happened afterwards. It is what was visible on chain at the moment of the launch.

Step 1: find the first buyers

A pool's first buyers are the first wallets whose balance of the launched token went up in the pool's transactions. Walk the pool's signature history back to the start, then read the token balance changes of the earliest transactions:

getSignaturesForAddress(pool) returns at most 1,000 signatures per page, newest first. Page backwards with before until a page comes back short; the last signature is the pool's creation.
For each of the first 40 successful transactions, getTransaction with jsonParsed gives preTokenBalances and postTokenBalances. Any owner (other than the pool) whose balance of the mint went up is a buyer.

Busy pools fill pages fast. By the time I ran this, about an hour after launch, this pool already had 15,908 signatures, so reaching its first transaction took 16 pages.

Step 2: find who funded each buyer

For each buyer, fetch its oldest transaction and see who set it up:

If that transaction has a System Program transfer into the wallet, the sender is the funder.
If not, take the fee payer. This matters more than it sounds. Here, five of the buyers got no transfer at all: one transaction, paid for by someone else, set up all five in a single go.

A wallet with more than a page of history is too busy to trace this way (its oldest transaction is too far back). Mark it as unknown rather than guessing.

Then group the buyers by funder. Two or more first buyers with the same funder is a cluster.

The code

Standard library only, Python 3.9+. It makes about 80 RPC calls and took about two minutes on the public endpoint, which rate-limits hard; pass your own RPC URL as the third argument if you have one.

"""Who funded a launch's first buyers? Plain Solana RPC, standard library only.

usage: python3 first_buyers.py <pool address> <mint> [rpc url]
"""
import json
import sys
import time
import urllib.request
from collections import defaultdict

RPC = sys.argv[3] if len(sys.argv) > 3 else "https://api.mainnet-beta.solana.com"
FIRST_TXS = 40      # transactions after pool creation to scan for buyers
FIRST_BUYERS = 15   # buyers whose funding we trace
PAGE = 1000         # getSignaturesForAddress maximum


def rpc(method, *params):
    body = json.dumps({"jsonrpc": "2.0", "id": 1, "method": method, "params": list(params)})
    error = None
    for attempt in range(6):
        time.sleep(0.25)  # stay under the public endpoint's rate limit
        req = urllib.request.Request(RPC, body.encode(), {"Content-Type": "application/json"})
        try:
            with urllib.request.urlopen(req, timeout=30) as resp:
                out = json.load(resp)
            if "error" in out:
                raise RuntimeError(f"{method}: {out['error']['message']}")
            return out["result"]
        except OSError as e:  # HTTP 429 and network errors are worth a retry
            error = e
        time.sleep(2 ** attempt)  # rate limited or flaky: back off and retry
    raise RuntimeError(f"{method}: {error}")


def tx(signature):
    return rpc("getTransaction", signature,
               {"encoding": "jsonParsed", "maxSupportedTransactionVersion": 1})


def oldest_signatures(address, max_pages=30):
    """Walk an address's history back to its first transaction; newest first per page."""
    before, sigs = None, []
    for _ in range(max_pages):
        opts = {"limit": PAGE, **({"before": before} if before else {})}
        page = rpc("getSignaturesForAddress", address, opts)
        sigs += page
        if len(page) < PAGE:
            return list(reversed(sigs)), True
        before = page[-1]["signature"]
    return list(reversed(sigs)), False  # too busy to reach the start


def first_buyers(pool, mint):
    sigs, complete = oldest_signatures(pool)
    if not complete:
        sys.exit("pool too busy to find its first buyers")
    buyers, seen = [], set()
    for s in [s for s in sigs if s["err"] is None][:FIRST_TXS]:
        t = tx(s["signature"])
        meta = t["meta"]
        before = {b["owner"]: int(b["uiTokenAmount"]["amount"])
                  for b in meta["preTokenBalances"] if b["mint"] == mint}
        gains = []
        for b in meta["postTokenBalances"]:
            if b["mint"] != mint or b["owner"] == pool:
                continue
            delta = int(b["uiTokenAmount"]["amount"]) - before.get(b["owner"], 0)
            if delta > 0:
                gains.append((delta, b["owner"]))
        for delta, owner in sorted(gains, reverse=True):
            if owner not in seen:
                seen.add(owner)
                buyers.append((owner, t["slot"]))
    return buyers[:FIRST_BUYERS]


def funder(wallet):
    """Who set this wallet up: the sender of SOL in its oldest transaction, else its fee payer."""
    sigs, complete = oldest_signatures(wallet, max_pages=1)
    if not complete:
        return None, "too_active"  # a busy wallet's first transaction is too far back
    ok = [s for s in sigs if s["err"] is None]
    if not ok:
        return None, "no_history"
    t = tx(ok[0]["signature"])
    for ix in t["transaction"]["message"]["instructions"] + [
        i for inner in t["meta"]["innerInstructions"] for i in inner["instructions"]
    ]:
        parsed = ix.get("parsed")
        info = parsed.get("info", {}) if isinstance(parsed, dict) else {}
        if ix.get("program") == "system" and info.get("destination") == wallet \
                and info.get("source") != wallet:
            return info["source"], "found"
    payer = t["transaction"]["message"]["accountKeys"][0]["pubkey"]
    return (payer, "found") if payer != wallet else (None, "not_found")


if __name__ == "__main__":
    pool, mint = sys.argv[1], sys.argv[2]
    clusters = defaultdict(list)
    for rank, (wallet, slot) in enumerate(first_buyers(pool, mint), 1):
        source, status = funder(wallet)
        print(f"{rank:>2} {wallet}  slot {slot}  funder {source or '-'} ({status})")
        if source:
            clusters[source].append(wallet)
    for source, wallets in sorted(clusters.items(), key=lambda kv: -len(kv[1])):
        if len(wallets) >= 2:
            print(f"{len(wallets)} first buyers funded by {source}")

Run it on the launch:

python3 first_buyers.py 2oFcPB4htz6Rua9meUNpUJ7uRJP6ZNF9nNoijyBhLGMr EdK8J369Aktt4s8JhygFjdNEWF8KBU1F1ekkzkRDpump

Output, trimmed:

 1 9mz2oaVdWnBwG2f6mWyg3vvwUoEtHp71uYipZoDyt4pK  slot 462049744  funder Ehd5Z2t5qF1hdpHiZYiB7YTWZbH7mRiz7q4SPdpcrXYs (found)
 2 9KBzzVeLNwAmkcijEDVd3QeLcXTWr5TNnHtdccu3K4rd  slot 462049744  funder Ehd5Z2t5qF1hdpHiZYiB7YTWZbH7mRiz7q4SPdpcrXYs (found)
 3 26KdQvPqHhuqfBXXdDCjoSXe6aogaRxuTNr1U6KPZ8X4  slot 462049744  funder Ehd5Z2t5qF1hdpHiZYiB7YTWZbH7mRiz7q4SPdpcrXYs (found)
 4 7zvXppkae4MKqjtLpS1XgUzWgigBGgWvgyMZ531SU4w  slot 462049744  funder Ehd5Z2t5qF1hdpHiZYiB7YTWZbH7mRiz7q4SPdpcrXYs (found)
 5 DSAuppab5NNiVaJ9yDa8nQhBQuYTFbhZYGRn3XLewKVJ  slot 462049744  funder Ehd5Z2t5qF1hdpHiZYiB7YTWZbH7mRiz7q4SPdpcrXYs (found)
 6 27HFmP7ccLadGswvQfvea4o3juLw75cPF4V6jWpHM3MX  slot 462049745  funder - (too_active)
 ...
14 FdJvuNNNSMEZw5E8kF7qCN1WfX2KC3Ymvsy7Y754ojBt  slot 462049828  funder qyfuh6W2oN9rGtKahyxCsZmDuoZK2RsvkABGf4uq9rH (found)
15 HaTp6JXz7uCMmSHYdh9QtQzWR3C21m9mP1bgUkfcibyY  slot 462049867  funder Ehd5Z2t5qF1hdpHiZYiB7YTWZbH7mRiz7q4SPdpcrXYs (found)
6 first buyers funded by Ehd5Z2t5qF1hdpHiZYiB7YTWZbH7mRiz7q4SPdpcrXYs

Reading the result

Three things stand out.

The five biggest early buys came from one source. Buyers 1 to 5 bought in the pool's creation slot, between 18 and 50 SOL each, and all five were set up by Ehd5…. A sixth wallet set up by the same funder bought 26 seconds later.

The creator came from the same place. Run funder() on the pool creator, 9CbmzfeiM1HYBjkV82BwA1cnWw6HnXSDTy611uiyHfNj, and it also returns Ehd5…, which paid for the creator's first transaction 19 slots before the pool existed. So the "demand" in the first block and the launch itself trace back to one wallet.

It all happened seconds before the launch. The buyers' oldest transaction, 2qumsjHpwXfm9iYoxtEYGkPuxtcvGwsu5XdbdBMjggcGGS1oEHbsei8yYwH9mLX469Hy9QbDWBJgzwxvvV9r7h9X, landed in slot 462049728, 16 slots before the pool. Ehd5… paid for it, it is the first transaction in the history of all five of buyers 1 to 5, and it created wrapped-SOL token accounts for four of them. None of the five received a SOL transfer in it, so a transfer-only check would have missed all of them.

The same mint's pump.fun bonding curve, created in the same slot, shows the pattern even more plainly: 14 of its first 15 buyers were funded by Ehd5….

What this does not show: who sold, or why the liquidity left. I did not trace the exits. The point is what a bot could see before buying.

Where the simple version breaks

Exchanges and hubs. If the funder is an exchange hot wallet or a payout service, a cluster is just "these people use Binance". You need a list of such wallets, or a rule like "ignore funders that have funded many unrelated wallets".
Busy wallets. Eight of these fifteen buyers had too much history to trace with one page. Active trading wallets are like that, so a launch where every early buyer is "too active" tells you nothing either way.
One hop only. A careful operator funds wallets through an intermediate wallet. Following a second hop helps, but costs more calls and more false links.
Speed. Two minutes on a public node is fine for research and too slow for a bot that buys in the first block. This check is for bots that buy after the first block and want to know who was there before them.

The one-call version

Disclosure: I build Dexra, a risk API for Solana launches. It runs this analysis on new launches (first-buyer funding, linked creators, same-block buyers, known snipers) and returns it with a verdict. For a mint you already have:

curl -s -X POST https://api.dexra.dev/new_launches/batch \
  -H "Authorization: Bearer $DEXRA_KEY" -H 'Content-Type: application/json' \
  -d '{"mints":["EdK8J369Aktt4s8JhygFjdNEWF8KBU1F1ekkzkRDpump"]}'

Trimmed response for the PumpSwap pool:

{
  "pool": "2oFcPB4htz6Rua9meUNpUJ7uRJP6ZNF9nNoijyBhLGMr",
  "verdict": "avoid",
  "reasons": [
    "liquidity has already collapsed",
    "liquidity is low",
    "first buyers include wallets linked to the creator by funding",
    "first buyers were funded from the same source"
  ],
  "creator": { "funder": "Ehd5Z2t5qF1hdpHiZYiB7YTWZbH7mRiz7q4SPdpcrXYs" },
  "first_buyers": {
    "status": "analyzed",
    "analyzed_wallets": 15,
    "same_block": 5,
    "creator_bots": 6,
    "largest_funder_cluster": 6,
    "funder_clusters": [
      { "funder": "Ehd5Z2t5qF1hdpHiZYiB7YTWZbH7mRiz7q4SPdpcrXYs", "wallets": 6, "linked_to_creator": true }
    ]
  }
}

Same six wallets, same funder, plus the link to the creator. Dexra ignores funders that have funded many wallets or are known exchange wallets, and reports busy wallets as too_active instead of guessing. If first_buyers.status is pending, the analysis is not done yet; treat that as "not yet", not as clean.

What the signal is worth

Dexra publishes how its flags did on past launches at /score_performance (no key needed). A collapse there means the pool's liquidity fell at least 80% from its peak within 24 hours, counted on launches that peaked at 5 SOL or $500 or more. "Survived" only means the liquidity was still there a day later; it says nothing about price.

Over the 7 days of history the report covers so far, 15,069 launches had their first buyers analyzed, and 89.2% of them collapsed. Of the 489 launches flagged with a funding cluster (three or more first buyers sharing a funder), 95.9% collapsed. Of the 484 where first buyers were linked to the creator by funding, 96.3% did.

So when the flag fires, the launch is almost always bad. But on a market where nearly nine in ten launches collapse anyway, that is only a little worse than the base rate. And the flag fires rarely: it catches about 3.5% of all collapses. Most collapses show no funding cluster at all.

That is the honest use of this check: a strong reason to skip, never a reason to buy. A launch with no cluster is not safe. It just did not fail this one test. If you build a bot around it, make it one of several conditions that must all pass, and treat "unknown" as a fail.

Takeaway

Fresh wallets leave a trail: the first transaction shows who paid for them.
Check the fee payer, not just SOL transfers; one setup transaction can create a whole set of buyer wallets.
Ignore exchange and hub funders, and treat untraceable wallets as unknown.
A shared funder is a strong "no" and a weak filter. It belongs inside a buy-only-if-everything-passes gate, not on its own.

The script above is free to copy. If you would rather get the funding graph and a verdict in one call, there are 100 free credits a day with an account, or pay per call in USDC over x402 with no account: dexra.dev/docs.

Whitelist, not blacklist: why a launch bot should buy only what passes

Dexra — Wed, 21 Oct 2026 21:00:12 +0000

Many open-source sniper and copy bots filter the same way: fetch the new launch, run a few checks, and skip it if something looks bad. Mint authority still active, skip. Creator rugged before, skip. Otherwise, buy.

That is a blacklist. It feels safe because every rule you add removes a known bad case. The problem is the base rate. When most launches fail, removing the obviously bad ones barely moves the odds of the ones you keep.

The alternative is a whitelist: buy only when every check positively passes, and treat anything else (a warning, a missing answer, a timeout) as "no".

This post shows the difference on real numbers, then gives you a gate you can drop into a bot and a script to measure your own filter.

The numbers

I build Dexra, a risk API for Solana launches, and it publishes an accuracy report at /score_performance. It scores past launches whose liquidity peaked at 5 SOL or $500 or more (so a collapse is measurable) and that are at least 24 hours old. The outcome it measures:

Collapse: liquidity fell at least 80% from its peak within 24 hours of launch.
Survived: liquidity was still there 24 hours after launch. That says nothing about price. A token can survive and still go to zero for whoever bought it.

The report is public, no key needed:

curl -s https://api.dexra.dev/score_performance | jq '.result | {analyzed_launches, survival_base_rate, filters}'

Over the last 30 days, 5,818 launches had their first buyers analyzed. 5,380 of them collapsed (92.5%). Only 438 kept their liquidity for a day.

Each launch also has a verdict rebuilt from what was known at launch time: ok, caution or avoid. The report then asks what two filters would have done on those same 5,818 launches (trimmed response):

"filters": [
  { "skips": ["avoid"],
    "taken": 3479, "collapses_avoided_share": 0.422,
    "survivors_skipped_share": 0.151, "collapse_rate_taken": 0.893 },
  { "skips": ["avoid", "caution"],
    "taken": 664, "collapses_avoided_share": 0.922,
    "survivors_skipped_share": 0.438, "collapse_rate_taken": 0.630 }
]

The same thing in a table:

Policy	Launches bought	Collapsed within 24h	Kept liquidity 24h	Collapses avoided	Survivors missed
Buy everything	5,818	92.5%	7.5%	—	—
Blacklist: skip `avoid`	3,479	89.3%	10.7%	42.2%	15.1%
Whitelist: buy only `ok`	664	63.0%	37.0%	92.2%	43.8%

Read the blacklist row again. It removed 42% of the collapses, which sounds good in a changelog. But of what it still buys, 89 in 100 lose most of their liquidity within a day, against 92.5 in 100 with no filter at all. The filter is working; it just cannot beat the base rate.

The whitelist buys far fewer launches, 664 out of 5,818 (11.4%). Of those, 37.0% kept their liquidity for 24 hours (95% confidence interval 33.5% to 40.8%), 4.9 times the 7.5% base. By verdict, launches marked caution survived at 4.5% and avoid at 2.8%, both below the base.

Why the two filters behave so differently

A blacklist removes launches that match a known bad pattern. On a market where nearly everything fails, most failures do not match any single pattern: a fresh creator wallet, first buyers funded a few hops away, a dev who sells at the first pump. So most of them pass through.

A whitelist inverts the burden of proof. A launch has to show that it is clean on every axis you can measure: authorities renounced, no creator history of collapses, first buyers not funded from one wallet, no bot cluster. Anything you could not read yet counts against it.

The cost is real and you should plan for it: in this data the whitelist skipped 192 of the 438 survivors, 43.8%. You will miss launches that would have been fine. A bot that buys 664 times instead of 3,479 also needs position sizing and exits that make sense on fewer trades.

And 37% is not a win rate. Even among the launches the whitelist kept, 63% still collapsed within a day. The check changes the odds you start from; it does not replace stop losses, sizing or exits.

A gate that fails closed

The most common bug in a pre-buy check is not a wrong rule, it is a missing answer treated as a pass. The RPC times out, the holder query errors, the analysis is not done yet, and the code falls through to buy().

Here is a gate that makes "no answer" mean "no". It does not depend on any service; plug in your own checks.

type Outcome = 'pass' | 'fail' | 'unknown'
type Check = { name: string; run: (mint: string) => Promise<Outcome> }

// A whitelist gate: buy only when every check positively passes.
// A timeout, an error or "unknown" counts as "no", never as "probably fine".
export async function allowBuy(mint: string, checks: Check[], timeoutMs = 1500) {
  const timeout = new Promise<Outcome>((resolve) => setTimeout(() => resolve('unknown'), timeoutMs))
  const results = await Promise.all(
    checks.map(async (check) => {
      const outcome = await Promise.race([check.run(mint).catch(() => 'unknown' as const), timeout])
      return { name: check.name, outcome }
    }),
  )
  const blocking = results.filter((r) => r.outcome !== 'pass')
  return { buy: blocking.length === 0, blocking }
}

With one slow check, the gate refuses and tells you why:

{"buy":false,"blocking":[{"name":"first_buyers","outcome":"unknown"}]}

Log blocking on every refusal. After a day you will know which check is slow, which one fires on everything, and which one never fires.

Measure your own filter

You do not need anyone's report to know whether your filter works. Log every launch your bot sees (not only the ones it bought) with the verdict it had at decision time, then mark which ones lost 80% of their liquidity within 24 hours. Then compute the same four numbers:

from collections import Counter

def filter_report(rows, skip):
    """rows: (verdict, collapsed) pairs; skip: verdicts the filter refuses to buy."""
    collapses = sum(1 for _, c in rows if c)
    survivors = len(rows) - collapses
    taken = [(v, c) for v, c in rows if v not in skip]
    skipped = [(v, c) for v, c in rows if v in skip]
    return {
        "skips": sorted(skip),
        "taken": len(taken),
        "collapse_rate_taken": round(sum(c for _, c in taken) / len(taken), 3) if taken else None,
        "collapses_avoided": round(sum(c for _, c in skipped) / collapses, 3) if collapses else None,
        "survivors_skipped": round(sum(not c for _, c in skipped) / survivors, 3) if survivors else None,
    }

# Replace with your own log: one row per launch your bot saw, with the verdict it had at
# decision time and whether liquidity fell 80% from its peak within 24 hours.
rows = [("ok", False), ("ok", True), ("caution", True), ("caution", False),
        ("avoid", True), ("avoid", True), ("caution", True), ("ok", False)]
print(Counter(v for v, _ in rows))
for skip in ({"avoid"}, {"avoid", "caution"}):
    print(filter_report(rows, skip))

The number to watch is collapse_rate_taken: what happens to the launches you actually buy. "Collapses avoided" is the number that looks good in a README; collapse_rate_taken is the one that shows up in your PnL.

Two traps when you build this log:

Use the verdict from decision time. If you recompute it later, a collapse that already happened leaks into the flags and the filter looks better than it was.
Count the launches you skipped. A log of only your buys cannot tell you how many survivors the filter threw away.

The shortcut

If you would rather not build the checks yourself: Dexra's new_launches returns fresh launches with a verdict and the reasons behind it, so the whitelist becomes one filter. Disclosure again: I build it.

type Launch = { mint: string; verdict?: string; reasons?: string[] }

async function okLaunches(key: string): Promise<Launch[]> {
  const res = await fetch('https://api.dexra.dev/new_launches?minutes=10&limit=20', {
    headers: { Authorization: `Bearer ${key}` },
    signal: AbortSignal.timeout(5000),
  })
  if (!res.ok) return [] // fail closed: no answer, no buy
  const body = await res.json()
  const launches: Launch[] = body.result?.launches ?? []
  return launches.filter((l) => l.verdict === 'ok')
}

What a typical answer looks like (one call today, 20 pump.fun launches from the last 30 minutes, trimmed):

{ "mint": "Eb9Q2Jp1gt5CQLUEyzyR9ro7faFNZH3yoz3FmA29pump", "verdict": "avoid",
  "reasons": ["the creator's earlier tokens collapsed", "liquidity is low"] }
{ "mint": "vmxT7NqUzyMnrNiBSn95KDWVDraUzhe6Z1yfmbXpump", "verdict": "caution",
  "reasons": ["liquidity is low", "first buyers are not analyzed yet; ask again shortly"] }
{ "mint": "F9QQge7i9xuygy96eN2uvCQvJ1qCZQsu6aH6h9rZpump", "verdict": "unknown",
  "reasons": ["first buyers are not analyzed yet; ask again shortly"] }

None of the 20 was ok, which is the point: on most calls the right number of buys is zero. unknown means the first buyers or the mint authorities were not read yet. A whitelist treats it as "not yet" and asks again, rather than buying on a partial answer.

Limits worth knowing before you rely on it:

The accuracy report rebuilds each verdict from flags known at launch time by the same rules the live API uses. It is not a log of live answers, and live answers can include more reasons (low liquidity, for one).
The dataset is young: 30 days at most, and the analyzed set is 5,818 launches. The confidence interval above is the honest width of the result.
Coverage is pump.fun, PumpSwap and Raydium pools; some launchpads are not streamed, and the API lists them under coverage.untracked_platforms.
Survival is about liquidity, not price. Nothing here predicts which tokens go up.

Takeaway

On a market where 92.5% of launches lose their liquidity within a day, a blacklist that removes the obvious rugs still leaves you buying mostly collapses.
Buy only what passes every check, and make timeouts and "unknown" count as a fail.
Measure collapse_rate_taken on everything your bot saw, with the verdict it had at the time.

If you want to try the whitelist without writing the checks, there are 100 free credits a day with an account, or pay per call in USDC over x402 with no account: dexra.dev/docs. The live numbers above are at dexra.dev/accuracy and change daily.