The critique
Last week we published a measurement showing that pump.fun's ownership transfer rewrites the on-chain creator field, so any tool reading it names the wallet that owns a coin today rather than the one that deployed it. Our fix was to resolve the deployer from the token's Create transaction instead, which is immutable.
Within an hour, a reader on r/solana pointed out the hole in that fix:
"accountKeys[0] on the Create tx is just whoever paid for it, and plenty of launches get signed by a fresh wallet funded from the same source minutes earlier, or by a launchpad relayer. So 'zero prior launches' is cheap to manufacture in that direction as well. What the Create tx gives you is a stable identity rather than a real one unless you go one hop up the funding graph and cluster on the funder."
That is correct, and it matters. A fee payer is an identifier, not an identity. Rotate the signing wallet per launch and every token you deploy presents as a first-time creator — which is the single most reassuring thing a rug checker can say. We said we would build the hop. This is what it found.
What we built
For any deployer wallet, walk its own transaction history back to the oldest signature, take the first inbound SOL transfer, and identify the sender. That sender is the funder — one level above the wallet that signs the launch, and the level a rotation strategy cannot hide behind.
Then classify the funder, because this is where the idea lives or dies:
- Known exchange — a listed CEX hot or withdrawal wallet.
- Infrastructure — program-owned accounts, and any address with exchange-scale throughput (very high volume and a sustained rate no human produces).
- Private wallet — everything else. This is the only case that links anything.
What we measured
Deployers our scanner had classified as FIRST_LAUNCH — the case where the hop is the only possible signal, because there is no launch history to read. Figures below are as of 11 August 2026; the index grows continuously.
| Funder resolved as | n | Share | Links anything? |
|---|---|---|---|
| Exchange / infrastructure | 804 | 85.4% | No |
| Private wallet | 137 | 14.6% | Four of them, now |
| Resolved total | 941 | — | — |
The overwhelming pattern is somebody withdrawing from an exchange and deploying a token — which links them to nobody except every other customer of that exchange.
The private funders are the interesting column, and as of this update they are no longer empty. There are 127 distinct private funders behind those 137 deployers. 123 of them funded exactly one deployer. Four funded more than one — three funded two each, and one funded eight.
That last one is the shape the critique predicted: one wallet, eight separate first-launch deployers, each of which would read as a first-time creator on its own. At n=190 we said this had never occurred and treated its absence as the finding. It occurs.
And we still cannot tell you it means anything. None of those eight deployers has outcome sampling — no dead-token rate, no peak market cap, nothing. Funding eight wallets is what a launch operation looks like; it is also what one person with eight projects looks like, and what a small team looks like. We are not naming the wallet, because a repeat funder with no measured outcome is a structure, not a verdict, and publishing an address on that basis would be an accusation wearing a measurement’s clothes.
The trap, which is the actual finding
One address has funded 151 of the 941 on its own — 16.0% of everything we have resolved. It has the throughput profile of an exchange hot wallet, though it was not on our list of known ones. The next two account for 42 and 30. Across all 941, 26 infrastructure addresses have funded more than one deployer, against four private ones.
If we had clustered naively on "shared funder", those forty unrelated deployers would have become one confident forty-wallet cabal. The finding would have looked exactly like a real one: same funder, many deployers, tight timing. It would have been entirely false — and it would have grown more convincing with every scan.
This is the failure mode that makes funder clustering dangerous rather than merely unhelpful. The hop does not fail by returning nothing — it fails by returning something that looks like evidence. Every wallet that ever withdrew from a large exchange shares a funder with thousands of strangers.
So the classifier is the feature, and the hop is the plumbing. We ship it deliberately silent: when the funder is an exchange or infrastructure, the tool says the check ran and links nothing, rather than manufacturing a cluster.
Why serial launchers never resolve
The walk returns "too deep" on essentially every deployer with a long history. Their wallets accumulate transactions from every launch, so reaching the first funding costs more pages than it is worth.
That sounds like a limitation and mostly is not. A wallet with 25 prior launches has already told you what you need; the funder adds nothing you did not know. The hop matters precisely where the existing signal is absent — first-launch deployers — and those wallets are shallow enough to walk. We only run it there, which also keeps the RPC cost near zero.
How to check it yourself
# 1. Walk the deployer wallet to its OLDEST signature getSignaturesForAddress(deployer, before=...) # paginate to the end # 2. First inbound SOL transfer on that tx = the funder getTransaction(oldest) -> find the account whose balance DECREASED # 3. Classify before you cluster. This step is not optional. known CEX list -> no signal program-owned account -> no signal very high volume AND sustained high rate -> no signal (unlisted exchange or bot) otherwise -> private wallet, and only now is a shared funder meaningful
If you cannot reach the wallet's first transaction, return unknown. A truncated walk hands back whichever counterparty happened to sit at the page limit — a random trading partner, presented with the same confidence as a real funder. That failure is indistinguishable from a genuine finding, which makes it worse than no finding at all.
What this does and doesn't tell you
- Every figure here has moved with sample size, twice. 15 → 190 → 941 resolved deployers; the private share went 0% → 8.4% → 14.6%. Treat these as snapshots with a date attached, not as rates.
- We have almost no outcomes for this population. The hop runs where there is no launch history, so only 58 of 941 resolved deployers have any outcome sampling. Nothing here links a funder pattern to a token dying, because the data to do that does not exist yet.
- It is one venue and one window. pump.fun first-launch deployers, 11 August 2026.
- The critique was right, and the data caught up with it. The attack described — rotating signers funded from one source — is exactly what a repeated private funder looks like, and at n=941 we can see four of them. It remains rare: four funders out of 127. But we no longer get to say we have never seen it.
- The index compounds. Every scan adds a deployer→funder edge. The linking half of this only becomes useful as coverage grows, and it costs nothing to accumulate.
- We make no claim about intent. Withdrawing from an exchange to deploy a token is what most people do. Nothing here identifies anyone as anything.
The practical takeaway
If you are building deployer reputation into a bot or a scanner: resolve the deployer from the Create transaction, and then stop before you cluster on the funder. The hop is worth taking, but the classifier in front of it is what stops it inventing cabals. Without that step you will generate confident false positives on the most ordinary behaviour on the chain.
And the reader who raised it was right about the underlying point, which is why we built it: a stable ID you can cluster on beats a mutable field you cannot. It just turns out that one hop up, almost everyone is standing in the same place.