Free volume bot scripts, and what they really cost

What is actually out there

Search for a free Solana volume bot and you will find real repositories with real code. Some are competent implementations by people who understood the problem. Others are abandoned, written against venue interfaces that have since changed, or forks of something else with modifications you would need to read the diff to notice.

Quality is genuinely bimodal, and the README tells you almost nothing about which half you are in. The signals that actually correlate are boring: recent commits, an issue tracker with answered issues, and code that handles the cases you would expect it to handle rather than only the happy path.

None of this is an argument against self-hosting. It is an argument for evaluating the specific repository rather than the category, because "free volume bot" describes a range from a well-maintained tool to a liability.

The five costs that are not zero

The RPC line surprises people most. A volume campaign sends a great many transactions in a short period, which is exactly the traffic pattern public endpoints exist to throttle. Running against a free endpoint produces dropped transactions, which look like failures, which look like the bot not working.

The venue fee line is the largest in almost every configuration and is identical whether you self-host or not, because it belongs to the pool rather than to the tooling. That is worth internalising before comparing prices: a meaningful share of any quoted service fee is a cost you would also pay running it yourself.

There is one more line that belongs in the table and never makes it into anyone's spreadsheet: the cost of a campaign that runs badly because nobody was watching it. A service that gets this wrong is answerable. A script you wrote that routed everything into one pool at three in the morning is not, and the money is equally gone either way. Whether that matters depends entirely on whether someone on your side will actually be reading the transaction log while it runs.

The key handling problem

This is the part that deserves more attention than it usually gets, and it is not really about trust in the author.

A volume bot needs to control a fleet of wallets, which means it generates or holds their private keys. That is unavoidable and fine in itself. What matters is where those keys go, what the script does with them, and whether anything in the code path sends them anywhere. A single line in a dependency is enough, and the fleet wallets are funded, which is the whole point of them.

Practical precautions if you self-host: read the key generation and signing code specifically rather than skimming the whole repository, pin dependencies rather than pulling latest, fund the fleet from a wallet that holds nothing else, and never let the script anywhere near the wallet holding your token supply or your treasury. The custody guide covers the same question from the other direction, which is what to ask a service that offers to do this for you.

Failure rates are where self-hosted budgets die

The single biggest gap between a competent implementation and a naive one is not features. It is the share of transactions that actually confirm.

A naive script sends every swap into the deepest pool with a fixed slippage setting and a fixed priority fee. All three of those decisions cost you. One pool means maximum price impact per swap, which means your own trades trigger your own slippage failures. A fixed tolerance cannot adapt when the network gets busy. A fixed priority fee is either wasteful when it is quiet or too low when it is not.

The result is a campaign that sends a thousand transactions and books the volume of six hundred, with the difference disappearing into fees paid for nothing. Because the failures are silent, the operator usually concludes the volume figure is wrong rather than that a third of the run never landed. The failure guide covers how to read which error you are actually hitting, and our weekly measurements show how far apart venues sit on this.

When self-hosting is genuinely the right call

There is a real case for it and it is worth stating plainly, because the answer is not always "buy".

• You run campaigns regularly. Setup cost amortises. One-off campaigns never recover it.
• You have engineering time. Not "can follow a README", but can debug a failed transaction and adapt when a venue changes.
• You want control over the shape. Custom timing, custom size distributions, integration with your own release schedule.
• You are comfortable with key management. Genuinely comfortable, with a funding wallet that is isolated.
• Your volumes are large. A percentage fee on a big campaign is a real number; at that scale building starts to pay.

A useful way to settle it is to price your own time honestly. Estimate the hours for initial setup, first-run debugging, and the repair work when a venue changes under you, then multiply by what an hour of your engineering time is worth. Compare that against the fee on the campaigns you actually intend to run this quarter, not the campaigns you imagine running. For most teams running one or two campaigns around a launch, the hours dominate by a wide margin. For a team running weekly, the fee dominates instead and building starts to make sense on the second or third month.

When it is not

The inverse cases are equally clear. A single campaign around one launch will spend more in setup hours than the fee it avoided. A team without anyone comfortable reading Rust or TypeScript will end up trusting a README, which is the risky version of self-hosting rather than the cheap one. And anyone whose main constraint is that the pool is too thin is solving the wrong problem in either direction, which the liquidity guide covers.

The honest summary is that free scripts are free to download and cost roughly what a service costs to run properly, with the difference being whose time absorbs the operational work and who holds the keys. Anyone telling you the choice is obvious in either direction is selling something.