Solana volume bot settings: configuring your first campaign

Five settings shape a campaign, and they are not independent. Trade size interacts with slippage, interval interacts with wallet count, and priority fee changes what all of them cost. Choosing each in isolation produces a configuration that is individually reasonable and collectively wrong, which is the most common way a campaign ends up costing more and achieving less than the numbers suggested it should.

Volion Research Updated Jul 30, 2026 7 sections

Trade size: the setting everything else follows

Trade size should be large enough that the trade registers with data aggregators and small enough that it leaves the price where it found it. On concentrated liquidity venues there is an additional constraint: stay inside the active range or the swap fails outright rather than merely filling badly.

The instinct to size up is worth resisting, because effect on a chart comes mostly from transaction count and distinct participants rather than from the size of any individual trade. Two hundred small trades and twenty large ones can represent the same notional volume and look completely different to an observer, with the smaller trades also moving the price less and failing less often.

Sizing is venue-dependent in a way that catches people out. A size that is comfortable on a deep constant-product pool can be past the edge of a concentrated pool's active range. The full reasoning is in volume bot trade size, and the venue differences are in which Solana DEX is cheapest.

Interval: pacing, and why it should not be regular

Interval controls how frequently trades are sent. It should vary rather than tick on a fixed clock, because evenly spaced activity is recognisable at a glance regardless of how everything else is configured. Pacing also affects cost, since running through congestion means higher priority fees and more failures at once.

Two separate concerns push in the same direction here. The first is that regular spacing is legible: a chart where trades arrive exactly every thirty seconds for four hours does not resemble anything organic. The second is economic: volatile and congested windows cost more per landed swap on every front simultaneously, so spreading activity across calmer periods is cheaper as well as less obvious.

Interval also interacts with wallet count. A high frequency with few wallets means the same addresses trading repeatedly in quick succession, which is a pattern in itself. Frequency and fleet size need to be chosen together rather than separately.

Wallet count: distinct participants, not just throughput

Wallet count determines how many different addresses the activity appears to come from. It matters because trade count and unique participants are what a chart and its watchers actually register, and because concurrent transactions from a single wallet race each other and fail.

There is a hard technical constraint underneath the cosmetic one. Two transactions in flight from the same wallet compete for the same balance, so one lands and the other fails while still paying its fee. Throughput therefore scales with fleet size, not with how hard you push a single address.

The presentational side matters as much. Activity from a handful of addresses reads differently from activity spread across many, and the funding pattern behind those addresses is visible on chain permanently. Wallets funded in identical amounts from one source minutes before trading form a signature that no amount of careful pacing afterwards can undo.

Sizing the fleet is covered in how many wallets you need, and the funding patterns that give a fleet away are in wallet clustering risk.

Slippage: the setting with two opposite failure modes

Slippage tolerance is the worst price you will accept. Set it too tight and ordinary price movement rejects your transactions, each rejection paying a fee. Set it too wide and you have defined how much someone else can profitably extract from your trade. Both failure modes cost money, in opposite directions.

This is the setting most often left on a default, and defaults are wrong by construction because the correct value depends on how much the specific pair moves between blocks. A tolerance that is comfortable on a liquid pair generates constant failures on a thin one.

The venue changes it too. On a Meteora DLMM pool, tolerance needs to accommodate roughly one bin step plus margin. On a concentrated Raydium or Orca pool, it needs to survive ordinary movement without being wide enough to invite a sandwich. The full derivation is in slippage settings and the extraction risk is in sandwich MEV protection.

Priority fee: bidding for scheduling

The priority fee is a bid for how promptly your transaction gets scheduled. It is paid whether the transaction succeeds or fails, so overbidding is expensive across a whole campaign, while underbidding means transactions sitting unscheduled long enough for the price to move past your slippage limit.

For context on the priority fee setting, our current window puts the network median transaction fee at 5,000 lamports with the 90th percentile at 10,000. The gap between those two is the range you are bidding within.

The right level depends on urgency, and campaigns are mostly not urgent. A bonding curve campaign competing for fills has a genuine reason to bid up. A pool campaign does not, because nobody is racing you for depth, and continuing to bid at curve levels after a token graduates is a pure overpayment that persists for the whole run.

How the fee market behaves and what the percentiles mean is covered in how Solana priority fees work, and current measured distributions are on the measured transaction costs page.

How the settings interact

Larger trades need wider slippage, which increases extraction risk. Higher frequency needs more wallets, or transactions race each other. Tighter slippage needs a higher priority fee, because the transaction must land before the price moves. Changing one setting almost always requires revisiting another.

Three couplings are worth holding in mind while configuring:

Trade size and slippage. Bigger trades move the price more, so they need more tolerance, which widens the window someone can extract from. Smaller trades let you keep tolerance tight, which is the cheaper equilibrium.
Frequency and fleet size. Throughput comes from wallets in parallel, not from pushing one wallet harder. Raising frequency without adding wallets produces self-inflicted failures.
Slippage and priority fee. A tight tolerance is a deadline. Meeting it requires landing quickly, which costs more in priority fee. Loosening tolerance slightly can be cheaper overall than paying to outrun the market.

The configuration that works for most campaigns follows from these: small trades, varied intervals, enough wallets to avoid self-competition, tolerance derived from the pair rather than defaulted, and a priority fee matched to whether you are actually competing for anything.

A sensible starting configuration

Start with trades small enough that quoted price impact is negligible, intervals that vary rather than repeat, a fleet large enough that no wallet has two transactions in flight, slippage derived from the pair's observed movement, and a priority fee near the median rather than the top of the distribution. Then adjust from what the landing rate tells you.

The first hour is diagnostic rather than definitive. If the landing rate is low, slippage is likely too tight or trade size too large for the depth available. If everything lands but nothing organic follows, the settings are fine and the question is whether the campaign is the right tool for this token at all.

All of these are configurable in the dashboard, and the cost of a given configuration can be modelled first with the calculator, which uses current measured rates rather than an assumed average. The end-to-end process, including the decisions that come before any of these settings, is in how to use a Solana volume bot, and the reasoning behind publishing measured inputs at all is on the page for our volume bot for Solana pools.

Questions

What trade size should I use for a volume bot?

Small enough that quoted price impact is negligible against the pool you are trading into, since effect comes from transaction count and distinct participants rather than from the size of any single trade. On concentrated liquidity venues there is an additional limit: stay inside the active range or swaps fail outright.

Should the interval between trades be fixed?

No. Evenly spaced trades are recognisable at a glance no matter how everything else is configured. Varying the interval also lets you avoid congested windows, which cost more in priority fees and produce more failures at the same time.

How many wallets do I need?

Enough that no single wallet has two transactions in flight at once, because concurrent transactions from one address compete for the same balance and one of them fails while still paying its fee. Beyond that technical floor, more wallets mean more distinct participants in the activity.

What slippage should I set?

A value derived from how much the pair actually moves between blocks, not a default. Too tight and ordinary movement rejects transactions that still pay fees; too wide and you have defined how much someone else can extract from each trade.

Do I need a high priority fee?

Only when you are genuinely competing for something, such as fills on a contested bonding curve. In a pool nobody is racing you for depth, so bidding at curve levels is an overpayment repeated on every transaction for the length of the campaign.

Can I change settings while a campaign is running?

Yes, and the first hour should be treated as diagnostic. A low landing rate usually means slippage is too tight or trade size too large for available depth, and both are worth correcting early rather than paying for across the whole run.

How to use a Solana volume bot Volume bot trade size Slippage settings How many wallets you need How priority fees work Measured transaction costs