How volume bots work, explained simply
One trade, followed from the funding wallet to the block it lands in. The six parts of the machine, the reasons attempts fail, what the retry loop is really deciding, and how to read a run log without a manual.
In one sentence
A volume bot funds a set of wallets, sends them a schedule of small buys and sells through a DEX, and retries the ones that fail.
The short answer
A volume bot funds a group of wallets from one master wallet, gives them a schedule of small buys and sells, builds each trade as a Solana transaction routed through a pool, sends it to the network through an RPC endpoint, and retries the ones that fail. There is no artificial intelligence in it and no market prediction. It is a queue, a signer and a retry loop.
The reason it still takes a page to explain is that each of those six words hides a decision, and the decisions are where cost, failure rate and appearance are actually determined. This page walks the whole path once at a normal pace, then goes back over the parts that beginners find genuinely confusing.
The six parts of the machine
1. The funding wallet
One wallet holds the SOL for the whole run. It is sometimes called the master or parent wallet. Nothing about it is special technically; it is an ordinary keypair that happens to hold the budget. Everything the run spends is drawn from here, either directly or by first passing through a worker.
2. The worker wallets
The program generates additional keypairs and sends each a small amount of SOL. Each worker needs enough for the trades it will make, plus fees, plus a small permanent reserve. That reserve is not optional: on Solana an account that holds a token needs a token account, and a token account must hold about 0.002 SOL to be rent exempt. Multiply that by the number of workers and it becomes a real line in the budget rather than a footnote.
3. The schedule
The schedule is the plan: how many trades, what size, how far apart, how the buys and sells alternate, and when the run ends. This is the part an operator actually controls, and almost every visible property of a campaign comes from here rather than from the software being clever.
4. The route
Each trade has to be aimed somewhere. Either the program targets one pool directly, or it asks a routing service which path gives the best output and builds the transaction that service returns. Direct targeting is predictable and simple; routing through an aggregator such as Jupiter can find better prices but adds a dependency and sometimes extra accounts to the transaction.
5. The RPC connection
Nothing reaches the network by magic. The program talks to an RPC node, which is a server running Solana that accepts transactions and answers questions about state. Public endpoints are rate limited and will drop work under load, which is why anybody running more than a toy uses a paid endpoint. A great deal of what beginners experience as the bot being broken is really the endpoint refusing them.
6. The retry loop
Transactions fail routinely on Solana for reasons unrelated to bugs. The loop watches for confirmation, decides whether a failure is worth another attempt, rebuilds the transaction if it is, and gives up when it should. Section five of this page is about that decision, because it is the part that separates software that works from software that merely runs.
Following one trade end to end
Here is a single buy, from the moment the scheduler picks it to the moment it appears in a block. Nine steps, in order. Nothing here is specific to any product; this is what any program doing this must do.
- The scheduler chooses. It picks worker number 41, a size of 0.05 SOL, and a direction of buy, because the plan said so.
- The program asks for a quote. Either it reads the pool state directly and calculates the output, or it asks a router what 0.05 SOL would buy right now.
- It applies the slippage tolerance. The quote is turned into a minimum acceptable output. If the swap would deliver less than that, the transaction is written so it fails rather than executing at a worse price.
- It fetches a recent blockhash. Every Solana transaction references a recent block. That reference expires after 150 blocks, which is roughly a minute, and an expired transaction is simply not accepted.
- It builds the instruction list. Create the token account if the worker does not have one, set the compute budget, set the priority fee, then the swap itself.
- It signs. Worker 41's private key signs the transaction. Each signature costs 5,000 lamports, a protocol constant, and a transaction can carry more than one.
- It sends. The signed transaction goes to the RPC endpoint, which forwards it toward the validators scheduled to produce the next blocks.
- It waits for confirmation. The program polls for the signature, or subscribes to updates, until the transaction is confirmed, failed or the blockhash expires.
- It records the outcome. Landed, failed with a reason, or expired. That record is the run log, and it is the only honest measurement of what a campaign did.
Once you have seen those nine steps, most of the vocabulary in this subject stops floating free. Priority fee is step five. Slippage is step three. RPC problems are step seven. Landing rate is steps eight and nine.
Why attempts fail
New operators are often shocked by the failure rate. A run where every attempt lands is unusual, not standard. The causes are ordinary and mostly not the fault of whoever wrote the software.
| Cause | What happened | Usually fixed by |
|---|---|---|
| Blockhash expired | The transaction sat too long before reaching a leader and its reference block aged out | Faster submission, fresher blockhash, better endpoint |
| Slippage exceeded | The pool moved between quote and execution, so the output fell below the minimum you set | A wider tolerance, a smaller trade, or accepting the failure |
| Insufficient funds | The worker could not cover the trade plus fees plus its rent reserve | Better funding arithmetic before the run |
| Dropped by the endpoint | The RPC provider rate limited or discarded the request | A paid endpoint, or slowing the schedule down |
| Compute budget exceeded | The transaction needed more compute units than were requested for it | Raising the requested limit for that route |
| Account not created | The worker had no token account for that mint and the instruction to create one was missing | Including the create instruction in the same transaction |
Notice how many of those are environmental. A failure rate is partly a statement about your infrastructure and the state of the network, not only about your configuration. That is the honest version, and it is why any figure quoted as a guaranteed success rate should be treated as decoration.
What the retry loop decides
A retry is not free. Each attempt pays a base fee whether or not the swap succeeds, because the network charges for processing the transaction, and a rejected transaction still consumed a slot in somebody's queue. So the loop is making an economic decision every time, and a well written one makes it explicitly.
The three questions it should answer are: is this failure the kind that would succeed on a second try, has the underlying reason changed since the last attempt, and has this trade already cost more in retries than the trade itself is worth. An expired blockhash is worth retrying immediately because a fresh one may land. A slippage failure is worth retrying only if you change something, otherwise you are paying to be told the same thing again.
The habit worth forming
When a tool reports a run, read the failure column before the success column. Successes tell you the plan executed. Failures tell you whether the plan was realistic. A campaign with a third of its attempts failing on slippage is not a broken bot; it is a tolerance set too tight for the depth of that pool.
What changes with more wallets
Wallet count is the setting beginners misjudge most, usually because it sounds free. It is not. Each worker carries a one-off cost and a share of the operational risk, and the benefit it buys is a matter of appearance rather than throughput.
Take an illustrative comparison. The rent reserve for a token account is about 0.002 SOL, and assume each worker also needs a small SOL float of 0.01 to cover fees comfortably over the run. The numbers below are arithmetic on those two assumptions and nothing more.
| Workers | Rent reserves | Floats | Setup total |
|---|---|---|---|
| 25 | 0.050 SOL | 0.250 SOL | 0.300 SOL |
| 100 | 0.200 SOL | 1.000 SOL | 1.200 SOL |
| 400 | 0.800 SOL | 4.000 SOL | 4.800 SOL |
Four hundred wallets cost sixteen times what twenty-five cost before a single trade happens, and the trades themselves are priced separately. Some of the rent is recoverable if the token accounts are closed afterwards, but only if the software actually does that and only if the tokens are gone first. Assume it is spent until you have watched it come back.
What extra wallets genuinely buy is dispersion: activity attributed to many addresses rather than a few. Whether that matters depends entirely on what is reading the chain and what filters it applies, which is a question nobody can answer with certainty for you. Treat it as a spectrum with a price attached rather than a setting that is simply better when turned up.
Timing, spacing and patterns
Solana produces a slot roughly every four hundred milliseconds, so a schedule can in principle place trades very close together. That does not mean it should. Trades at a mechanically fixed interval and a mechanically fixed size are the most legible pattern on a chain, and anybody scrolling the transaction list will see it without needing any tooling.
Most tools therefore randomise both interval and size within a band. This is not a clever trick and it does not make anything invisible; the addresses were funded from one place, and that funding is public. It mainly avoids producing a chart that looks like a metronome. Understanding that limit early prevents a whole family of disappointed expectations later.
An automated Solana volume bot generally exposes these as two ranges and one duration: a size band, an interval band, and how long to keep going. Those three settings, plus the wallet count, produce almost every property of a run that anyone will notice.
What the operator can see
Less than people expect. The operator sees the run log, wallet balances, and whatever the aggregator sites show afterwards. They cannot see who else is trading, whether an index counted their activity, or whether a trending list applied a filter. Anyone claiming visibility into those is describing an inference, not a measurement.
They also cannot see the future state of the pool. A quote at step two of the trade sequence is a statement about the pool as it was, and by the time the transaction lands another trade may have moved it. That gap is what the slippage tolerance exists to bound, and it is why a tighter tolerance produces more failures rather than better prices.
Where the venue changes after a launch migrates from a curve to an ordinary automated market maker, the shape of the whole run changes with it, because pool depth and fee structure are different. Anyone reading about a Raydium volume bot rather than a curve tool is really reading about that second phase, where trades meet a two-sided pool and price impact depends on the depth somebody deposited.
Reading a run log
The log is the only part of this whole subject that is unambiguous, so learn to read one. Five columns tell you everything worth knowing, and every honest tool exposes them in some form.
- Signature. Paste it into an explorer. Either it is on chain or it is not, and that settles most disputes immediately.
- Outcome. Landed, failed or expired. Three different things, often collapsed into one word by tools that would rather not discuss it.
- Reason. For failures, the specific error. Slippage, funds, compute and expiry each mean a different fix.
- Fee paid. Including on failures, because those are the ones people forget to add up.
- Timestamp. Which tells you whether the schedule executed at the pace you set or drifted under retries.
If you keep only one habit from this page, keep the one where you take a signature out of the log and look it up yourself on an explorer. A tool that tells you a trade landed and an explorer that has never heard of the signature is the clearest possible signal, and it takes twenty seconds to check.
Where this leaves you
The machine is now fully described: fund, distribute, schedule, quote, sign, send, confirm, retry, record. Nothing in that list requires trust in anybody's cleverness, and every step produces evidence you can inspect afterwards. That is a much better starting position than treating the whole thing as an opaque product.
The two questions this page deliberately left open are where the trade actually lands and what it costs when it gets there. The first is the pools explainer, which covers automated market makers, bonding curves and why depth decides everything. The second is the fees explainer, which prices a single swap down to the lamport.
Written by The Plain Solana Desk. Protocol behaviour described here comes from public documentation and from things anyone can check on a block explorer; any figure in an example is arithmetic chosen to make a point and describes no real account. The way this desk decides what to publish is set out in how we explain things, and every term used above has a short entry in the word list.