Volume Tools on a Launchpad: What They Do and What They Cost

A volume tool executes repeated buys and sells of a token across wallets it controls, so that the token shows trading activity instead of a flat line. The trades are real swaps that settle on chain and pay real fees. What a buyer gets is activity in the chart, the trade feed and any interface that sorts by recent volume. What a buyer does not get is liquidity, holders or price support, and the gap between those two lists is where most of the disappointment in this class comes from.

This page treats the class the way a buyer should: as a service with a per-unit cost, a set of venue dependencies and a short list of things it structurally cannot do. There are no product names, no prices and no benchmark tables here, because prices change weekly and any benchmark would be an unverifiable claim dressed as a measurement.

What the class produces

The output of a volume run is ordinary trade data. Each leg is a swap between one of the operator's wallets and the pool or curve the token trades against, recorded like any other swap and readable by anyone. That is what separates this class from comment and visibility tooling: nothing is fabricated, and the record does not claim anything that did not happen. The trades occurred; they occurred between wallets one party funded.

That distinction matters for how a buyer should think about the purchase. You are not buying an impression that could be exposed as false. You are buying activity in a public record, along with the accurate interpretation that anyone can make of it. The honest framing is promotional: the token becomes visible in places that sort by activity, and the reason it became visible is that somebody paid for the trades.

The second thing the class produces is a fee bill, which is the part sales material treats as a footnote. Every leg pays a venue fee, moves price against itself through the pool, and costs a small amount of network fee. None of that comes back. The arithmetic below is the most useful thing on this page, because it converts a vague budget into a number of legs.

The problem it addresses

The real situation this class is bought for is narrow and recognisable. A token exists, the pair is live, and the trade feed shows nothing. Interfaces that rank by activity therefore do not show it at all, and a visitor who does find the page sees a chart that looks abandoned. That is a genuine problem, and it is a presentation problem rather than a demand problem.

Confusing the two is the standard error. A token with no trades and no interested buyers has two problems, and this class addresses exactly one of them. Teams who buy volume expecting the second problem to resolve itself end up running longer campaigns at rising cost and concluding that the tool failed, when the tool did precisely what the class does.

The productive way to frame the purchase is as a floor rather than a strategy: the token should not look dead while the things that might actually attract holders are happening. If nothing else is happening, the floor is all you are buying, and it is worth being honest with yourself about that before signing up for a month.

The cost of one round trip

Here is illustrative arithmetic with invented round figures. It is not a price list, not a measurement of any product, and not a claim about any venue's current fees. Substitute the real numbers from your own quote and the structure holds.

Define a round trip as one buy and one matching sell, each of 0.2 SOL notional. Assume the venue charges 1 per cent per side, that moving through the pool costs 0.3 per cent per side in spread and slippage, and that each transaction carries a priority fee of 0.0002 SOL on top of the protocol base fee of 5,000 lamports per signature.

• VENUE FEE1 per cent of 0.2 SOL, twice: 0.004 SOL
• SPREAD0.3 per cent of 0.2 SOL, twice: 0.0012 SOL
• PRIORITY0.0002 SOL on each of two transactions: 0.0004 SOL
• BASE FEE0.000005 SOL per signature, twice: 0.00001 SOL
• COSTAbout 0.0056 SOL consumed per round trip
• DISPLAYED0.4 SOL of reported volume, since both legs are counted by most interfaces
• RATIORoughly 1.4 per cent of displayed volume disappears as cost, before the seller charges anything

The ratio is the number to carry away, not the individual figures. Everything in this class scales linearly with it, which means a buyer can evaluate any quote by asking one question: what percentage of displayed volume is consumed by fees, spread and the service charge combined. If a seller cannot produce that number, they are quoting a price without knowing their own product.

Scaling that to a budget

Continuing the same illustration: to display 100 SOL of volume at 0.4 SOL per round trip takes 250 round trips, consuming about 1.4 SOL in fees and spread. Add an illustrative service fee of 2 per cent of displayed volume, and the total cost of showing 100 SOL of activity is roughly 3.4 SOL, or a little over 3 per cent.

Two properties follow that surprise first-time buyers. The first is that working capital and cost are different numbers. The 0.2 SOL notional recycles, so a small balance can produce a large amount of displayed volume over time; what actually gets consumed is the fee ratio. The second is that larger trade sizes do not improve the ratio much, because venue fees and spread are both proportional. Bigger legs mean fewer transactions and slightly less priority fee, and that is all.

A buyer comparing quotes should therefore normalise everything to cost per unit of displayed volume, and should ask whether the quoted service fee is charged on displayed volume, on capital deployed or per transaction. Those three produce very different bills for the same run, and the difference is much larger than the difference between sellers. Any page setting out what a Solana volume bot cost is made of is worth reading before you accept a headline figure from anyone.

Curve against pool

A token on a launchpad curve and the same token in a standard pool are different trading environments, and a volume tool behaves differently in each. On Pump.fun a token begins against a bonding curve, where price movement follows the curve rather than pool depth, and migrates to an automated market maker once the curve completes.

The buyer-relevant consequences are these. Fee structure differs between the two environments, so the ratio computed above changes at migration. Price impact behaves differently, because a curve and a pool respond to the same order size in different ways. And venue coverage becomes a real question: a tool that only supports one side of the migration stops being useful at exactly the moment a launch is trying to keep momentum.

Ask for venue coverage as a list of named venues, in writing, before buying. A serious operator publishes this, because it is the least controversial thing about the product. A professional Solana volume bot will state which venues it trades on and what happens when a token moves between them, and a seller who answers this with "all of them" has answered a different question.

The wallet set underneath

Every volume tool sits on top of wallet set tooling, so every purchase in this class is also a custody decision. The wallets need to exist, be funded, hold token accounts, and eventually be swept back. Each token account holds a rent-exempt minimum of a little over 0.002 SOL, which is locked rather than spent until the account is closed, and the mechanics of those accounts are documented in the SPL program documentation.

Two practical questions follow. Who holds the keys during the run, and what happens to the residual balances when it ends. A tool that sweeps automatically and reports what it returned is doing the job properly. A tool that leaves dust and rent scattered across fifty accounts has quietly kept a portion of your budget, and the amount is small per wallet and not small in aggregate.

The wallet pattern also determines how the run reads to anyone examining it later. Wallets funded from a single source, trading one token at similar sizes on a regular cadence, are a recognisable structure. No amount of randomisation removes the funding relationship, because the funding transactions are themselves on the chain.

Reading a fee model

Three pricing structures dominate this class, and they are not equivalent for the same run. Work out which one you are being quoted before comparing any two offers.

Whatever the model, the network and venue fees are yours in every case. A quote that appears to include them usually means the seller is estimating them and building a margin into the estimate. That is not dishonest, but it is worth knowing, because it means your effective cost varies with network conditions you are not being shown.

What to specify in a run

Buyers routinely hand over a budget and a token address and let the operator decide everything else, then discover the run did not match what they had in mind. These are the parameters worth agreeing in writing before anything starts.

• Venues. Named, not "all supported". Include what happens at migration if the token is still on a curve.
• Leg size range. Minimum and maximum notional per trade, because this determines how the activity reads to anyone looking at it.
• Duration and cadence. Over how many hours or days, and whether activity is continuous or clustered.
• Wallet count. How many wallets, who funds the rent, and whether they are reused across runs or across clients.
• Sweep policy. What happens to residual SOL, residual tokens and rent when the run ends, and when you get it back.
• Reporting. Whether you receive the transaction signatures, so you can verify the run yourself rather than accept a summary screenshot.
• Stop conditions. What halts a run: your instruction, a budget ceiling, or a price condition, and how quickly a stop takes effect.

The reporting item is the one most often missing and the one that most changes the relationship. A run you can verify transaction by transaction is a service. A run reported as a screenshot of a chart is a story about a service.

What volume does not prove

The honesty position

This desk treats volume tooling as promotion rather than as manipulation of a reader's beliefs, and the distinction rests on one property: the trades are real and the record is accurate. Nobody is being told a false thing. What is being paid for is presence in activity-sorted interfaces, which is closer to advertising than to a fake review.

That is a defence of the class, not an endorsement of every use of it. The same tool used to make a token look like it has organic interest, in a pitch that also claims organic interest exists, becomes part of a false statement made by the person pitching. The tool did not lie; the seller of the token did. Where a launch team is honest about what it paid for, this class sits in ordinary commercial territory. Where it is not, the class is being used to support a claim the record does not make.

The practical version of that position for a buyer: decide now what you would say if a prospective holder asked directly whether the trading activity was paid for. If the answer you would give is untrue, the problem is not the tool and no seller can fix it.

When it is the wrong purchase

There are three situations where this class reliably disappoints, and recognising them in advance is worth more than any comparison of vendors.

1. Nothing else is happening. If there is no product, no audience and no reason for anyone to look, activity in a chart nobody visits is a cost with no counterpart. The class is a floor under other efforts, not a substitute for them.
2. The budget is small enough that fees dominate. Run the ratio. If the fee share of your budget is large relative to the volume it produces, the run is buying very little and the money is better spent elsewhere.
3. The real question was supply or ordering. If what worries you is who holds the token in the first minutes, that is the bundler class and this one cannot help, because the moment it concerns has passed.

If none of those apply and the pair is live with an empty feed, this is the class that matches the situation. Evaluate it on the fee ratio, the venue list, the sweep policy and the reporting, and put the same questions to every seller in writing. The buying checklist on this shelf turns those into twenty-five questions and a way of scoring the answers.

Questions buyers ask about this class