Pump.fun Bots Explained: The Five Classes on the Shelf

A Pump.fun bot is a program that acts on a launchpad in your place, and nearly every product sold under that name belongs to one of five classes: bundlers, snipers, volume tools, comment and visibility bots, and wallet set tooling. Those five buy different things, fail differently, and take money out of your budget in different shapes. Identifying the class is the first useful move a buyer can make.

This page is the map of the shelf. It describes each class from the position of somebody about to pay for it, not from the position of somebody building it. There is no ranking here, no product names and no prices, because prices move weekly and a ranking would be an opinion wearing the costume of a measurement.

What a bot means here

On a launchpad, a bot is simply software holding a key and sending transactions. There is no technical boundary between a person clicking a button and a program submitting the same instruction; the chain records the instruction either way. That is worth internalising early, because it means the interesting differences between these tools are not about capability. They are about timing, scale, custody and what gets left behind.

The venue matters for the vocabulary. On Pump.fun a token begins its life trading against a bonding curve and later migrates to a standard automated market maker pool, and several of these classes behave differently on either side of that line. A tool that made sense during the curve phase may have nothing to do afterwards, and a seller who never mentions migration has told you something about how carefully they think.

Also worth setting straight: none of these tools has privileged access. They interact with the same public programs anyone else does, and their output is readable by anyone who wants to read it. What a good tool actually sells is reliability, scale and convenience, three things that are genuinely hard and genuinely worth money. What a bad tool sells is the impression of an advantage that does not exist.

The five classes at a glance

Before the detail, here is the whole shelf in one grid. The columns are deliberately chosen to be answerable: what the class produces, what it takes out of a budget, and the thing it visibly leaves behind. Nothing here is a score, and the timing of each class is dealt with further down.

Bundlers

A bundler groups several transactions so they are included together rather than one at a time. On a launch that usually means the creation of the token and a set of buys arriving in the same moment, before anyone outside the operation has a chance to act. What you are buying is ordering: a position in the queue at the only moment where the queue is decisive.

What that produces is a supply position. After the bundle, a set of wallets you control holds a share of the token, bought at the lowest part of the curve. That is the entire product. It is not a chart, not attention and not liquidity, and if the reason you wanted a bundler was any of those three, you have picked the wrong class.

The property most sellers skip is that the result is permanently legible. Holder distribution, funding paths and the timing of those first buys sit in the public record, and readers of a new token routinely check exactly that. Anyone can pull the same data from a public interface such as the Solana explorer, which means the question is not whether a bundle is detectable but how a launch team plans to talk about it.

Snipers

A sniper watches for new tokens and tries to buy in the earliest moments, usually on tokens the operator did not create. This is the one class on the shelf that is a trading strategy rather than a launch service, and it is bought by traders rather than by launch teams. It sits here because it shares infrastructure with the others and because sellers cross-sell it constantly.

The economics are unforgiving in a specific way: you pay for attempts, not for results. Transactions that fail to land still consume a fee, and the base cost of a signature on Solana is a fixed 5,000 lamports, which is 0.000005 SOL, before any priority fee added to compete for inclusion. A tool making many attempts per day is spending money continuously whether or not any attempt is profitable.

The honest version of this class advertises a failure rate. The dishonest version advertises a win screenshot. A buyer's question here is not "how fast is it" but "what proportion of attempts land, what do the failures cost per day, and who is paying for the infrastructure that makes the difference". A seller who has run the thing at scale can answer all three without hesitating.

Volume tools

A volume tool runs repeated buys and sells across a set of wallets so that a token's chart and trade feed show activity. Unlike the comment class, its output is real: every leg is an executed swap that settles on chain and is visible to anyone. That is both the strength and the limit of the class. The trades are genuine, and they are trades between wallets the operator funded.

Where the money goes is the part worth understanding before buying. Each leg pays a network fee, a venue fee, and the spread and slippage of moving through a pool, and none of that comes back. On a launchpad curve the fee behaviour differs from a migrated pool, which is why a Pump.fun volume bot and the same tool pointed at an AMM pair produce different arithmetic for the same budget. Ask for the fee model in writing and do the multiplication yourself.

What the class cannot do is more important than what it can. Volume does not create holders. It does not hold a price up, because the sells are as real as the buys. It does not survive being examined by someone who reads the wallet paths. What it does is put a token into the parts of an interface that sort by activity, and make a live pair look live rather than abandoned, which is a real and limited thing to want.

Comment and visibility bots

This class posts messages, replies and reactions from many accounts so that a token's feed looks busy. It is on the shelf because buyers meet it constantly, and it is the one class this desk does not treat as a neutral tactic. The messages are written to be read as other people's opinions, and they are not other people's opinions. That is deception aimed at readers, not a growth channel.

The practical consequence, separate from the ethics, is that it works poorly and fails loudly. Manufactured feeds have a texture: interchangeable phrasing, arrival in clusters, accounts with no history, enthusiasm that does not respond to anything actually said. Experienced readers spot it in seconds, and the discovery converts an ordinary launch into a launch with a credibility problem.

The class note for this one carries no operating guidance, no seller checklist and no advice on making the output convincing, which is a deliberate gap rather than an oversight. What it does carry is a description of how readers detect it and what the alternatives cost.

Wallet set tooling

Underneath the four classes above sits an unglamorous one that most buyers never think about separately: software that creates wallets in bulk, funds them from a source, distributes SOL in patterns, sweeps balances back and recovers keys when something goes wrong. Whenever a tool says it operates across fifty wallets, this is the machinery doing it.

It deserves its own attention because it is where custody lives. If the tool generates the keys, somebody other than you may hold them. If the tool holds funded wallets, somebody other than you can move that money. This is the single largest practical risk on the whole shelf, and it is decided by one question with a yes or no answer: can you export every private key, right now, without asking permission.

Cost here is mostly the quiet kind. Every account on Solana must hold a rent-exempt minimum to stay alive, which is a little over 0.002 SOL for a standard token account, and that value is locked rather than spent until the account is closed. Across a large wallet set, plus transfer fees in both directions, the locked capital becomes a real number that nobody quotes in a sales message.

Called bots, not shelved here

Three other things routinely get called bots in this market and are not classes of launchpad tooling in the sense used here. They are worth naming so the shelf stays clean.

• Monitoring and alert bots. Software that watches new launches, wallet activity or price and sends you a message. It only reads. It changes nothing on chain and carries none of the custody risk of the classes above.
• Dashboards and analytics. Interfaces that aggregate on-chain data into charts and holder tables. Useful, occasionally sold at surprising prices, but they are reading tools rather than acting tools.
• Submission and listing helpers. Services that submit a token to aggregators, trackers and directories. Some of this is ordinary administrative work. Where it shades into buying placement in a trending list, it belongs with the visibility class and its problems.

The distinction that matters is simple: does the thing hold a key and send transactions, or does it only read. Read-only tools can waste your money but cannot lose your funds, and that is a large enough difference to keep them in a separate category.

Where the classes overlap

Real products are usually two or three of these classes in one panel, which is fine, and the reason vocabulary gets muddy, which is not. A launch suite may bundle at creation, then run volume for a week, then sweep wallets, all from the same interface, and sell the whole thing under one name. The buyer's job is to price the parts separately.

The most consequential overlap is that four of the five classes need wallet set tooling underneath them, which means that every custody question applies to almost everything on the shelf. When a bundler tells you it manages twenty wallets, you are buying a wallet manager whether or not the word appears on the page. Ask the export question of every product, regardless of its advertised class.

What migration changes

Tokens on a launchpad curve behave differently from tokens trading in a standard pool, and the shelf changes shape at that line. Understanding this stops a buyer paying for something that expired before the invoice arrived.

• Bundlers become irrelevant. Their whole function is the launch moment. After migration there is no such moment to buy.
• Snipers move on. They are hunting new tokens, and yours is no longer new. A sniper subscription is not a thing your token benefits from at any stage.
• Volume tooling keeps working, with different arithmetic. Trading against a pool changes fee structure, slippage behaviour and how much depth a given order size actually moves.
• Comment tooling is unaffected and still deceptive. The feed does not care which venue the token trades on.
• Wallet set tooling is venue-neutral. Wallets are wallets. The rent and fee arithmetic is the same on either side of the line.

Telegram bot, panel or self-hosted

Independent of class, these tools reach you in one of three shapes, and the shape decides more about your risk than the feature list does. It is worth deciding which shape you are willing to accept before you start comparing features at all.

None of the three is correct in general. Self-hosting removes custody risk and replaces it with operational risk, which is a good trade only if somebody on your side can actually operate it. A hosted panel is the reasonable middle if, and only if, it will tell you where the keys live and let you take them with you.

What none of them can do

Every class on this shelf changes something observable. None of them changes the thing most buyers are actually hoping to change, and being clear about that saves more money than any feature comparison.

Which one to buy first

The most common sequencing error is buying a launch tool for a chart problem, or a chart tool for an attention problem. Match the class to the sentence you would actually say about your situation, and the shelf reduces to one or two options rather than a dozen.

1. Write the problem in one sentence, before opening any sales page. "The pair is live and nothing is trading" is a different problem from "I do not want three strangers holding half the supply at minute one".
2. Name the class that addresses that sentence. Supply and ordering means bundler. Empty chart on a live pair means volume. Neither means comments, ever.
3. Price the cost shape, not the headline. Add the seller fee, the network cost per action, and the capital that gets locked rather than spent. Compare that total against the budget you actually have.
4. Ask the custody question regardless of class. Can you export every key. A no here ends the evaluation whatever the rest of the answers looked like.
5. Decide what you will say publicly. Whatever you run is readable afterwards. Deciding the answer in advance is cheaper than improvising it under questioning.

For a live pair with an empty feed, the class you want is the volume class, and the reference point worth using is a console that publishes its venue coverage and fee model rather than an operator quoting a number in a private chat. Reading how a Solana volume bot documents what a run puts on chain gives you a baseline for the questions in the buying checklist, whether or not you buy anything at all.

If none of the five classes matches your sentence, the correct purchase is nothing. That is a real outcome and it happens more often than the market would like. The next page on the shelf goes one level deeper into the class people ask about most, and the buying checklist turns all of this into questions you can send to a seller and hold them to in writing.

Questions buyers ask about this class