One hop back. When 'this dev is new' really means 'this funder is the same.'

A new deployer wallet costs roughly nothing. Solana keypairs are free, the funding hop is a single transfer, and a fresh address shows up on chain with no history attached. If "this dev is new" is your filter, every rug operator on Solana clears it. They have to. Their old wallet is on a list.

The wallet that funded the new dev, though, is harder to throw away. Funding a fresh address requires SOL, and SOL has to come from somewhere a few hops back. Most teams don't burn the funding wallet every cycle. It's the same wallet sending priority fees, paying for pool creation, topping up bundler accounts. The funder survives the dev's death and gets used again on the next launch.

In the rug anatomy piece we said 93.8% of resolved +24h downside outcomes filed under "manufactured distribution." Bundlers vs snipers covered one half of that pattern, the cap-table half. This is the other half: the funder graph, one hop back from the deployer.

Why one hop, not zero, not two

The deployer is hop zero. The funder is hop one. The funder's funder is hop two. Why does the scanner look at hop one specifically?

Hop zero is too thin. A brand-new deployer wallet has no on-chain history beyond the launch itself. Reading the deployer's own behavior catches almost nothing on a fresh launch because there's almost nothing to read. The rule engine does read the deployer's prior tokens, but for a wallet that's a few hours old, the history field is empty.

Hop two is too wide. Walk one more hop back and the funder graph fans out. A typical funder wallet was itself funded by a CEX hot wallet, a Marinade or Jito staking wallet, a Kamino routing wallet, or a Jupiter aggregator. Those are infrastructure, not signal. Following the graph past hop one bleeds into wallets that handled millions of unrelated transactions, and per-wallet history at hop two stops separating anything. We tried it during early development; it was net-noisy.

Hop one is the sweet spot. Far enough that we have history to read (funder wallets have usually been around for weeks or months). Close enough that the wallet's behavior is still directly attributable to the people behind the launch. Hop one is where the deployer's identity stops being disposable.

This isn't a discovery. It's a structural fact about Solana cap tables. The deployer is the disposable layer of the operation. The funder isn't.

What we read at hop one

For every deployer we see, we identify the funder (the wallet that sent the first SOL to the deployer, ignoring known routers and CEX hot wallets), then pull a precomputed profile from cache. The profile holds:

• Funder age. When did this wallet first show up on chain?
• Funded-deployer count. How many distinct deployers has it seeded? A funder that has bankrolled 40 deployers in 60 days is doing one thing. A funder that has bankrolled two is doing something else.
• Downstream outcome history. For the deployers this funder has seeded, how have their tokens performed at the +24h horizon?
• Active timeframe. How concentrated in time is the funder's activity? 30 deployers in a week is a rug factory. 30 deployers over 18 months is something else.
• Co-funded wallet overlap. Are the new token's top holders also wallets this funder seeded? This is where the funder graph meets the cap-table graph.

That profile is the input. Each piece of evidence has its own weight, and the rule fires at medium or high severity depending on which combinations are lit up.

The three rules that actually fire

There are three distinct rules in the rule set that read the funder graph. They're separable on purpose; calibration weights them independently.

Familiar funder. The funder wallet has seeded multiple deployers whose tokens resolved downside. Threshold is a count plus a hit rate, not just a count. Six deployers, five rugged, fires. Six deployers, five tradeable, doesn't. The rule fingerprints a pattern, not a wallet.

Funder-cluster overlap. The token's top holders include other wallets seeded by the same funder. This is the "one team in five trench coats" pattern. The cap table looks like 20 strangers; one hop back, three or four of them are the same operator's pieces. Strongest single composite signal in the rule set.

Deployer prior rugs. The deployer wallet itself has prior tokens with downside outcomes. Reads hop zero, not hop one, so only fires on deployers with a history. When it fires it fires hard.

The three rules can fire independently and they often fire together. A typical "manufactured distribution" token at +24h fires all three: familiar funder, top-holder overlap with the funder's other downstream wallets, and a dirty deployer history. Compound signals like that are why the cope score moves quickly into the RUG tier on the worst launches.

What "rug funder" looks like in numbers

The most predictive funders share a narrower profile than people expect. Age in the weeks-to-months range. Funded-deployer count in the high single digits to low dozens over the rolling window (above that the wallet looks like a service, below it the sample is too small). Activity tightly concentrated in time, not spread across a year. Downstream hit rate well above the cohort base rate.

That profile catches a specific operator persona. A wallet someone uses to keep launching tokens until one sticks, or until they get bored and start a new funder. When the pattern matches, the scanner flags it on the next launch.

False positives and how we exclude them

The biggest design problem with the funder graph isn't catching rugs. It's not catching infrastructure as rugs. Solana is full of high-throughput wallets that move SOL for legitimate reasons: CEX hot wallets, MEV bot wallets, staking routers, Jupiter aggregators, OTC desks, MM operations.

If we treated all of those as funders, the scanner would flag every legitimate launch funded through a Jupiter swap. The exclusion logic lives in src/lib/funder-labels.ts and a few sibling files. It works in layers:

• Known-router exclusion. A maintained list of addresses for the major routers, CEXs, and staking platforms. If the deployer's funding hop goes through one of these, we walk one more hop back. The router never becomes the funder of record.
• Velocity exclusion. Wallets moving SOL through hundreds of distinct addresses per day are infrastructure. We exclude them by behavior, so a new infrastructure wallet not yet on the address list still gets the right treatment.
• Reach exclusion. Wallets that have funded thousands of deployers over a long timeframe are services. The funder rule only fires on dense, concentrated patterns.
• Liquidity-source exclusion. Pool LP wallets sometimes look like funders if their first interaction with a deployer was a SOL transfer. The detection logic excludes the LP-creation transaction itself, so the pool wallet doesn't get mistaken for the funder.

The exclusion only affects rule firing, not display. If a scan was funded through a router, you can still see that in the structural breakdown on the scan page. The rule just doesn't fire on infrastructure.

The cache that makes this real-time

A profile that takes 30 seconds to compute is useless on a scan that needs to return in under five. The rule depends on a precomputed cache, keyed by funder address, refreshed in the background on a rolling cadence with priority for funders showing up in recent scans. At scan time we look up the deployer's funder: fresh entry, use it; missing entry, fetch on the fly within the scan's time budget; stale entry, use it and schedule a refresh.

The funder cache is separate from the per-token enriched cache on purpose. Tokens move in and out of the recent-scans window quickly. Funders persist. Coupling the two would mean re-fetching funder data on every new token, which would be both expensive and noisy.

The bundler-funder overlap

The strongest composite signal we have is when bundler-or-sniper share is high and the bundler/sniper wallets co-fund back through the same funder as the deployer. Bundlers alone are evidence of coordination. The funder co-fund tells you the coordination wasn't "two unrelated bots raced into the same slot." It was the same operator on both sides of the trade.

Fire rate for the composite is low. Most launches with bundler share don't have bundlers co-funded back to the deployer. When the composite does fire, the hit rate at +24h is among the highest in the rule set. Calibration weights it accordingly, and the verdict almost always lands RUG.

If you ever see a scan card with "manufactured distribution" risks listed alongside a funder-cluster overlap flag, you're looking at the cleanest version of the pattern. The cap table has been deliberately distributed across wallets the operator controls, and one hop back the disguise comes off.

Funder rotation

Profiles aren't permanent. When too many of a funder's tokens get flagged, the operator usually abandons it and spins up a new funder. Familiar-funder won't fire on the first few launches from the new wallet. That's the gap that rotation exploits.

Three things keep it small. Co-funded overlap still fires (cap-table coordination doesn't depend on funder history). Deployer-prior-rugs still fires for any deployer that wasn't rotated alongside the funder. Velocity-based detection flags new funders fast: a wallet seeding five deployers in two days, regardless of history, looks like a funder by behavior.

None of this catches every rotated-funder launch. Each layer makes rotation more expensive, and a few of them have to keep cooperating for evasion to work.

What we don't claim

The funder graph catches a lot, and it catches the most operationally important pattern in the cohort. It is not a complete view of insider risk.

• It doesn't see off-chain coordination. If five wallets get funded from five different Coinbase accounts (controlled by one person off chain), the on-chain graph shows five separate funders. We can't read Coinbase.
• It doesn't catch single-launch operators. An operator who has never run a token before and never will again leaves no funder history. The funder rule says nothing.
• It doesn't predict honest projects. The graph is a downside filter. A clean funder doesn't add confidence; it just doesn't add risk.
• It doesn't replace reading the rest of the page. Funder-graph rules are one input to the cope score. We don't promote tokens to RUG on a funder hit alone.

Those limits are why the funder graph is one rule family in a longer list, not the entire scanner.

Reading the funder field

The structural breakdown on a scan card shows two related wallets: the dev wallet (the deployer) and the funder wallet (one hop back, after exclusion). Click either and you can see recent activity.

A few read-tips:

• Clean dev, familiar funder. Still a real flag. The dev is disposable; the funder is persistent. Trust the funder over the dev.
• Familiar dev, clean funder. Unusual. Usually means a known-bad operator using a new funder for this launch. Pay attention to the dev's history regardless.
• Both clean. Baseline. Most fresh launches look like this. The funder rule contributes nothing; the cope score is driven by the rest of the page.

The verdict word doesn't have room to explain which side the signal came from. The breakdown does.

TL;DR

Solana lets you spawn a new deployer for the price of a transfer. The funder doesn't get spawned that easily. One hop back is where the operator's identity stops being disposable, and that's where the scanner reads. Three rules fire from this layer: familiar funder, funder-cluster overlap, deployer prior rugs. Together they catch the bulk of the 93.8% manufactured-distribution pattern. Exclusion logic keeps infrastructure wallets from poisoning the signal. The cache keeps the read fast at scan time.

Scan a token at doomer.wtf and read the funder field. It's the line that tells you whether the deployer's anonymity is real or whether it's a costume the same operator is wearing for the eighth time this month.