What pump.fun shipped
In January 2026 pump.fun released creator fee sharing. The announcement listed three capabilities: split fees across up to 10 wallets, transfer coin ownership, and revoke update authority. All three can be applied after a token launches, by the creator or by a Community Takeover admin, from the web and mobile apps.
Fee splitting is an economic change. Ownership transfer is not — it changes identity, and identity is what a deployer check is built on.
The assumption it breaks
Almost every Solana scanner answers "who made this token?" by reading a field. On pump.fun the natural candidates are the bonding curve's creator (offset 49) and, after graduation, the pump-amm pool's coin_creator (offset 211).
An ownership transfer rewrites both. They are not a record of who deployed the token; they are a record of who owns it now. For the overwhelming majority of tokens those are the same wallet, which is exactly why the assumption survived so long.
The consequence: a transferee wallet is usually brand new. It has launched nothing. So a token whose real deployer has launched dozens of tokens can present as "first-time creator, no history" — the single most reassuring thing a rug checker can say.
What we measured
Two cohorts of graduated pump.fun tokens. For each, we compared the wallet named by the on-chain creator field against the fee payer of the token's actual Create transaction — the immutable record of who deployed it.
| Cohort | n | Median age | Ownership transferred |
|---|---|---|---|
| Fresh graduations (minutes old) | 20 | < 1 hour | 0 (0%) |
| Aged graduations | 38 | 47 days | 8 (21%) |
It is an age effect. Transferring ownership is a deliberate act that takes days, so a sample of fresh tokens shows nothing and closes the question wrongly. Ours did exactly that on the first pass — the fresh cohort was the first thing we ran, and it said 0%.
What it does to a verdict
On three of those eight tokens the original deployer had 28, 25 and 5 prior launches. Each new owner had none. One token's real deployer has since been measured at 42 launches, 100% of the sampled ones dead — while the wallet named by the creator field had launched nothing at all.
How to check it yourself
This is the whole method. It needs a Solana RPC endpoint and nothing else.
# 1. Derive the bonding-curve PDA for the mint seeds = ["bonding-curve", mint_pubkey] program = 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P # 2. Read the CURRENT owner from the account (offset 49, 32 bytes) getAccountInfo(curve_pda) -> data[49:81] # 3. Walk the curve's signatures to the OLDEST one getSignaturesForAddress(curve_pda, before=...) # paginate to the end # 4. Confirm that tx is the launch, then take its fee payer getTransaction(oldest) -> logs contain "Instruction: Create" -> accountKeys[0] is the DEPLOYER # If step 2 and step 4 disagree, ownership was transferred.
Step 4's check is not optional. If your RPC's history does not reach the launch, the oldest signature you can reach is an early trade, and its fee payer is a random buyer. Skip the Create confirmation and you will manufacture "transfers" on precisely the oldest tokens — which is the same shape as the real finding. We validated all 38 tokens this way before believing any of it.
Walk the bonding curve, not the mint. The curve stops receiving transactions at graduation, so it stays shallow; the mint keeps accruing AMM trades forever and will blow a sensible page limit on exactly the old tokens where transfers are most likely.
We had this bug too
This is not a competitor takedown. Cabal-Hunter resolved graduated pump.fun tokens through creator → coin_creator — the current owner — and counted that wallet's launch history. On the eight transferred tokens we were reporting the transferee, exactly like everyone else.
We now resolve the deployer from the create transaction, cache it permanently (the deployer is immutable, so it never needs re-resolving), and surface ownership transfer as its own field. Fixing it also turned up a non-existent program ID sitting in our own constants that had silently disabled a whole code path — a plausible-looking base58 string that shared its first eleven characters with the real program.
A transfer is a mechanism, not an accusation. Community takeovers are legitimate and common — a founder handing a project to its community does exactly this. We report the transfer as data and never score it. The problem was never that transfers happen; it is that reading a mutable field and calling it "the deployer" produces a confident, wrong answer.
What this does and doesn't tell you
- Sample size is small. 38 aged and 20 fresh tokens, sampled from our own scan history. Treat 21% as an order of magnitude, not a precise rate.
- It is one window. Measured 5–6 August 2026. pump.fun ships quickly and this could change.
- It says nothing about intent. We did not attempt to determine why any ownership moved, and neither should a scanner.
- Fee splitting is untested here. We measured ownership transfer only. Splitting fees across 10 wallets does not change who deployed a token, so it cannot corrupt a deployer verdict — but we have not measured how common it is.
The practical takeaway
If you are building a bot, an agent, or a scanner that gates on deployer history: do not read the creator field. Resolve the deployer from the create transaction and cache it. It costs one signature walk per token, once, forever — and it is the difference between "first-time creator" and "42 launches, all dead."
If you are trading: a "first-time dev" verdict on a pump.fun token more than a few weeks old is worth a second look. It may be true. It may also be a field that was rewritten.