Launchpad Red Flags: Sniping, Wash Trading and Deployer Farms

Introduction

A wash trade shows up in 8.26% of pump.fun coins under the most conservative test run against the platform's full transaction history, and a sniper buys inside the first five blocks on 84% of sampled launches — numbers no price chart alone reveals. Both figures come from public transaction data anyone can read before buying, not from guessing, and every other figure in this article carries the same kind of sourcing. This breakdown covers six checkable signals — deployer wallet history, name collisions, fee-to-volume ratios, holder concentration, liquidity lock-versus-burn status, and sniper activity — and the specific free tool each one runs on. It also lands the point most guides skip: a burned liquidity pool blocks exactly one attack, pool withdrawal, and does nothing about the other five.

How Do You Check a Deployer Wallet's History Before You Buy?

A deployer wallet's launch history is public, and checking it takes under a minute on a block explorer. That address carries every prior token it created — dead, abandoned or still trading. One in three tokens flagged as rugs trace back to a deployer with 20 or more previous launches (DeFade "State of Solana Rugs" report, 2026).

Serial Minters and Repeat Deployer Addresses

A single wallet address can create dozens of tokens in sequence, and every one stays attached to that address permanently on the chain. Researchers who studied pump.fun's full 15.2-million-coin history grouped creator wallets by shared funding source and found the picture concentrates further: the top 1% of funding groups created 58.6% of all coins on the platform (arXiv 2609.10246, 2026-09-09). A wallet that looks new can still belong to a funding cluster with a long, documented history under other addresses. Pasting a token's mint address into a block explorer surfaces the creator wallet directly, and from there the explorer's transaction history lists every other token that same address deployed, each with its own timestamp.

What a Public Deployer-Reputation Scan Actually Returns

Free scanners built for this specific check return three numbers, not a single verdict. A deploy velocity above roughly five tokens a day signals a factory operation rather than a project (jpatching/daybreak documentation, 2026). A rug rate reports what share of a wallet's past launches are now dead — no liquidity, no trading, abandoned. A funding-cluster size counts how many other deployer wallets trace back to the same source of SOL. One published example scan returned a wallet with 194 total launches, 157 of them dead, an 80.9% rug rate and a five-wallet funding cluster (jpatching/daybreak, 2026). None of the three numbers alone proves intent; together, on a wallet with no trading history to hide behind, they come close.

A clean deployer history says nothing about a token's name, which carries its own tell.

What Does a Name Collision Inside a Short Launch Window Signal?

A name or ticker that already exists is not a coincidence at scale. Broad matching against pump.fun's full launch history finds 5.4 million coins — 36% of all 15.2 million ever created — sharing the exact same name and ticker as an earlier coin (arXiv 2609.10246, 2026-09-09). A collision alone proves nothing; one inside a short window against a rising token is the pattern worth checking.

Same Name, Same Ticker, Multiple Times Over

Copycat launches ride an existing coin's attention by reusing its exact name and ticker, betting a fast-moving buyer pastes the wrong contract address. The same 15.2-million-coin study measured this with methods of increasing breadth: the narrowest, matching name and description together, catches roughly 10% of all coins; the broadest, matching name and ticker alone, catches 36% (arXiv 2609.10246, 2026-09-09). That spread matters — a broad match includes coincidental reuse of an already-common meme name, not only deliberate copies. The signal worth acting on is not the match itself but whether the newer launch appeared inside the same day or hour the original coin started drawing volume.

Checking a Token's Name Against Prior Launches Yourself

Searching a token's exact name and ticker on the launchpad's own search bar, or an aggregator indexing historical launches, surfaces every prior coin that used the same pair. The creation timestamp on each result shows the gap between launches — minutes apart reads as a copy riding attention, months apart reads as unrelated reuse of a common meme name. Comparing the contract address in a social post against the address a search actually returns closes the more direct trap, where a bad actor pairs a legitimate-looking name with a different mint. Neither search needs an account, and a mismatch between the address people discuss and the address returned is the fastest disqualifier here.

A name collision is free to check and instant to resolve. A fee-to-volume ratio takes one more step, and it catches a manipulation a name search cannot.

How Do Fee-to-Volume Ratios Expose Wash Trading on a New Token?

Reported trading volume can be manufactured; the fee paid on it cannot, because it costs real money on every leg of the trade. Dividing fees paid over 24 hours by reported volume over the same period produces a ratio a wash trader cannot fake without paying for it (dev.to, 2026).

Computing the Ratio From Public Trade Data

Fee-to-volume ratio equals fees paid over 24 hours divided by volume over the same 24 hours, multiplied by 100 — both figures sit on any decentralized exchange (DEX) aggregator's token page. Documented bands read the result: 0.5% to 2.5% describes ordinary organic trading, 0.1% to 0.5% warrants a closer look, and anything below 0.1% alongside high reported volume reads as very likely wash-traded; zero fees against active volume reads as a probable honeypot (dev.to, 2026). The same 15.2-million-coin study found manipulators prioritize transaction count over volume specifically to minimize fees charged per unit traded, exactly the asymmetry this ratio is built to catch (arXiv 2609.10246, 2026-09-09). A token printing large volume on trivial fees is not evading detection — the fee ledger is the number in that pair it cannot cheaply fake.

Reading Trade Size and Counterparty Patterns Alongside It

Wash trading concentrates in high-activity coins rather than spreading evenly: coins with 10,000 or more transactions carry a wash-trading ratio of 50.31%, against 0.41% for coins with ten transactions or fewer (arXiv 2609.10246, 2026-09-09). A fee ratio that looks suspicious is worth confirming against the transaction list itself — the same handful of wallets appearing on both sides of repeated trades, uniform trade sizes clustering around one or two values, and transactions arriving at mechanically regular intervals all describe an automated loop rather than independent buyers. Stacking a low fee ratio against repeated-wallet trading and flat holder growth over the same window turns a suspicion into something checkable.

Fee ratios and trade patterns describe manipulated activity. Holder concentration describes something activity cannot hide: who actually owns the supply.

Why Does Holder Concentration Matter More Than Early Price Action?

A token's price chart can look healthy while its ownership looks nothing like it. Reading the top-10-holder share alongside price, rather than instead of it, is the check that catches concentration before a sell-off does.

Reading the Top-10-Holder Share on a Block Explorer

Every Solana token's largest holders are public through a single remote procedure call (RPC) — getTokenLargestAccounts — that most free scanners wrap into a readable top-10 or top-20 list. Reading that list means subtracting the liquidity pool address, any burn address, and known exchange wallets first, since none of those represent a person who can decide to sell. Public tools disagree on where concentration turns dangerous: community guidance built into rugchecker.com commonly flags a token once its top 10 holders pass 30% of supply, while the weighted scorer at clearank.com treats 30% to 50% as an elevated-risk band and anything above 50% as a serious, near-fatal flag (rugchecker.com; clearank.com, 2026). The disagreement is real, not sloppy — treat 30% as the point to start paying attention, not as a hard line.

Why Bundled Wallets Hide the Real Concentration Number

A clean top-10 percentage can still understate real concentration when the supply sits in wallets that only look independent. Behavioral trace data across more than 41,000 Solana launchpad launches found coordinated, bundled accounts hold an average of 36.5% of a token's supply — a share invisible to a scanner reading each wallet in isolation (arXiv 2602.13480, 2026). Regrouping bundled wallets by funding source raises the measured top-10 concentration by a median of 24 percentage points on the highest-risk launches, against only 6 points on the lowest-risk ones. A wallet-cluster tool that traces funding origin, not only balance, tells the real concentration from the apparent one.

Concentrated or bundled ownership is a distribution problem. Whether the liquidity itself can be pulled out from under that ownership is a separate question — and the one most guides get wrong.

Does Burned Liquidity Actually Make a Launchpad Token Safe?

Burned liquidity prevents exactly one attack: the deployer withdrawing the pool. It prevents nothing else — not creator selling, not sniping, not wash trading, not a token that never finds a second buyer. Confusing custody safety with price safety is the single most consequential mistake in this entire subject.

What a Liquidity Burn Actually Prevents

Burning liquidity means sending the liquidity-provider (LP) tokens that represent a claim on the pool to an address nobody controls, permanently. Once that transaction confirms, the deployer — or anyone else — cannot withdraw the underlying pool assets, because no wallet holds the claim needed to redeem them (Chainstack docs, 2026). On a bonding-curve launchpad ↗ this happens automatically at graduation: the pool funding the new automated market maker (AMM) is burned in the same transaction that creates it, with no separate step and no discretion involved. That single guarantee — the pool cannot be drained — is the entire content of "liquidity is burned." It says nothing about who holds the tokens trading against that pool, or what they do next.

Why a Lock Has an Expiry and a Burn Does Not

A time-locked pool and a burned pool look identical on a price chart, and read very differently on-chain. A lock deposits the LP tokens into a smart contract that releases them back to a specified wallet on a set date — the liquidity is protected only until that date arrives, and public scanners report exactly when (rug.tools, 2026). A burn carries no release date, because no wallet exists on the other end to release the tokens to. Checking which one applies means reading the LP token holder directly: an unspendable burn address means burned, while a program address with an associated unlock timestamp means locked — and that timestamp is the number that actually matters, since a lock expiring in three days protects nothing further out than three days.

What Still Survives a Burned Pool

A burned pool blocks exactly one attack, and every other pattern in this article operates around it, not through it. A creator who bought early can still sell into the first wave of demand — that sale runs through the market the pool provides, not against the pool itself. Sniper wallets funded in the same block as the launch, covered next, profit and exit long before any burn-versus-lock distinction matters to them. Wash trading inflates a coin's apparent volume on an already-burned pool, because the burn fixes the pool's assets in place; it does not touch who trades against them. A token can also fail to attract a second buyer and go to zero with its liquidity fully intact and burned the entire way down. None of these outcomes requires the deployer to touch the pool, which is why a burn confirmation is a verdict on one attack against liquidity — not on the token.

Data current as of October 2026.

Burned liquidity says nothing about who buys first. Sniper bots exist to answer that question before anyone else can.

How Do Sniper Bots Take the Opening Block Before You Can?

Sniper wallets do not react to a launch; they are already positioned for it. They buy in the same block the pool opens. A one-month sample found deployer-funded snipers behind 15,000 SOL in realized profit across 15,000-plus pump.fun launches (Pine Analytics via Bitget News, 2025-04-21).

What Happens in the Pool-Open Moment

A sniper wallet does not compete for the first trade the way a human trader would; the deployer funds it before the launch transaction lands, and it buys inside the same block or one of the next few. An academic study of 6,000 pump.fun coins defines a sniper as a wallet buying within the first five blocks — about two seconds at Solana's block time — and detected that pattern in 84% of sampled coins (SBFC 2025, University of Sydney). A separate one-month sample found 4,600-plus sniper wallets tied to 10,400-plus deployer wallets through a direct, traceable funding transaction, about 1.75% of that month's launch activity and profitable on 87% of the snipes involved (Pine Analytics via Bitget News, 2025-04-21). The funding transaction, not the trade itself, identifies the pattern.

Checking Whether a Wallet Bought Before the Public Could

Sorting a token's transaction history by slot number surfaces every wallet that bought in the launch block or the next few. Tracing each wallet's transfers back one hop shows whether the deployer funded them directly, the same link Pine Analytics used to find its sniper wallets. Exit speed confirms it: 85% of sniper positions closed within five minutes and 90% within one or two trades, faster than any ordinary trader (Pine Analytics via Bitget News, 2025-04-21). A wallet buying at block zero and tracing to the deployer's funding is not a lucky trade — it is the same pattern, one launch at a time.

Sniper activity and wash trading both leave a trace in a token's trading data. Curve position and graduation odds are a different kind of number — they measure momentum, not manipulation.

What Do Curve Position and Graduation Rate Not Tell You About Safety?

A curve reading and a graduation rate both describe a token's progress toward an automated market maker listing. Neither one reads custody, ownership or manipulation, and treating either as a safety signal mixes up two separate questions.

Why a Curve Reading Is Not a Safety Signal

A bonding curve's percentage-to-completion tracks accumulated reserves against a threshold, and that number says nothing about who holds the supply or whether the trading around it is genuine — the mechanics behind the curve, including why it can sit at 99% for hours without completing, are covered in full in What Is a Bonding Curve? ↗. A token can sit at 40% completion with a clean deployer history, or at 95% completion while every signal here is present. Wash-traded coins in the Carnegie Mellon study graduated at roughly double the rate of non-wash-traded ones — 2.0% against 0.90% — because manipulated volume pushes a coin toward the platform's front page and draws more real buyers there (arXiv 2609.10246, 2026-09-09). A rising curve is evidence of activity, not evidence that the activity is clean.

Why a Graduation Rate Is Not a Rug Indicator

Graduation measures how often a curve reaches its migration threshold at all — published rates span a wide range depending on sample size and measurement window, a spread the companion article on graduation numbers ↗ covers in full rather than restating here. Whatever the true rate is, it answers a question about migration odds, not about a token's deployer, holder distribution or trading pattern. A graduated token still carries whatever holder concentration and deployer history it had on the curve; migrating to an AMM changes where it trades, not who controls it. The six checks earlier in this article answer the safety question directly; curve position and graduation odds never do.

Six separate checks only help if they run in the same few minutes it takes to lose an opportunity by waiting too long.

How Do You Run All Six Checks Yourself in Under Five Minutes?

Every check in this article runs on a pasted token or wallet address through a free public tool, in a fixed order that takes under five minutes end to end. The order matters more than any single tool's uptime, because the method outlives whichever scanner happens to be online.

Which Public Tools Show Deployer, Holder and Sniper Data

Three categories of free public tool cover everything in this article's six checks. A deployer-reputation scanner traces a mint address back to its creator wallet and returns that wallet's full launch history, rug rate and funding cluster (jpatching/daybreak, 2026). A holder-concentration tool reads a token's top holders directly from the chain, and a wallet-cluster tool groups those holders by shared funding origin to expose bundling a simple balance read misses. A block explorer covers the rest — fees and volume for the ratio check, the exact slot number of the launch transaction for the sniper check, and the raw list of prior tokens sharing a name for the collision check. None of the three requires an account, a wallet connection or payment, and every figure this article cites came from exactly this tier of tool.

Building a Five-Minute Pre-Buy Sequence

Running the checks in a fixed order avoids wasting time on a token that fails early. Start with the deployer scan — a wallet with a high rug rate or a five-figure launch count ends the check immediately, before the other five matter. Next, search the name and ticker against prior launches, then read the top-10 holder share with pool and burn addresses excluded. Compute the fee-to-volume ratio fourth — it needs a few minutes of trading history to mean anything on a brand-new coin. Confirm liquidity status — locked with an expiry date, or burned — fifth, and check the launch-block buyer list last, since sniper wallets are already visible by then. The table below summarizes all six signals with the specific check and tool type behind each one.

Data current as of October 2026.

FAQ

?Are memecoin red flags illegal for the platform to allow, or only risky for the buyer?

Most of the patterns in this article are not illegal for a launchpad to allow — bonding-curve platforms are permissionless by design, and a platform cannot pre-screen every deployer or every trade before it happens. Regulatory attention to date has centered on specific fraud and unlicensed money-transmission conduct by named actors, not on the bonding-curve mechanism itself. For a buyer, every signal in this article describes a risk to price and custody, not proof that the activity breaks any law — the two questions are separate, and this article only answers the second one.

?Do these on-chain checks work the same way on Ethereum-based launches, or only on Solana?

The method transfers; the specific tool does not. Ethereum tokens use a different RPC call and different scanners — contract-security and Etherscan-based tools instead of Solana-native ones — but the same six questions apply: who deployed it, has the name appeared before, what the fee-to-volume ratio shows, how concentrated real holders are, whether liquidity is locked or burned, and whether a funded wallet bought first. The block-based sniper definition changes too, since Ethereum's block time runs far slower than Solana's roughly 0.4 seconds.

?How is checking a bonding-curve launch different from checking a token already listed on a centralized exchange?

A centralized exchange listing already screens for some of this — the exchange verifies the team, requires disclosed liquidity, and can delist a token that misbehaves. A bonding-curve launch has none of that: anyone deploys permissionlessly, no listing team reviews it, and the six checks in this article are the closest substitute for that missing screening step. The trade-off is speed and access in exchange for due diligence that used to be someone else's job.

?Is a "verified" or "audited" smart contract the same thing as a safe token?

No. A verified contract means its source code is publicly readable and matches what is deployed; an audit means a third party reviewed that code for specific bug classes. Neither check reads deployer history, holder concentration, funding clusters or trading patterns — the entire subject of this article. A bonding-curve token can carry an identical, unmodifiable contract to every other token on the same platform and still fail every signal covered here, because the risk lives in wallets and behavior, not in the code.

?Can a deployer wallet keep collecting trading fees on a token even after abandoning it?

On platforms that route a creator-fee share to a dedicated vault address, yes — that fee accrues from ongoing trading regardless of whether the deployer still participates, and it can be claimed on demand with no waiting period. A deployer who walks away from a token can still collect from it passively as long as trading continues, a separate income stream from any initial token sale that most buyers never think to check.

?Do any of these checks require a paid scanner subscription to run?

No. Every figure in this article came from a free tier: a public RPC call for holder data, a launchpad's own search for name collisions, a DEX aggregator's published fee and volume figures, and a free deployer-reputation scanner for wallet history. Paid tiers on some of these tools add convenience — a fuller holder table, a saved scan history — but nothing in the six-check sequence requires payment to run once.

?Does a large number of holders by itself rule out concentration risk?

No — holder count and holder concentration measure different things. A token can show several thousand holders while a handful of bundled, coordinated wallets still control most of the actual supply, since a high count only means many addresses hold some balance, not that the balances are evenly sized or independently controlled. The top-10 share, read after excluding pool, burn and exchange addresses, is the number that answers the concentration question; total holder count does not.

?If every check on this list comes back clean, does that guarantee the token will not still fail?

No. These six checks screen out specific, documented manipulation patterns — they do not evaluate whether the project attracts real demand, whether the team keeps building, or whether the broader market for its category holds up. A token can pass every signal here, carry real distribution and a permanently burned pool, and still go to zero because no second wave of buyers ever arrives. Clean checks reduce one category of risk; they do not remove risk itself.

References / Sources