Swap size and distribution: the parameter that is chosen against depth

Swap size is chosen against pool depth. Not against the budget, not against a target trade count, and not against whatever the last run used. Depth decides how much a trade can move price against itself, and that single relationship sets both ends of the usable range: below it fees dominate the trade, above it impact does. The budget then decides how long the run lasts at that size, which is a separate question with a separate answer.

The input that should not decide this

The common derivation is budget divided by a trade count that feels right. Forty SOL over a hundred trades gives 0.4 SOL per trade, and the number looks reasonable because it came out of arithmetic. What that arithmetic never consulted is the pool. The same 0.4 SOL is trivial against deep liquidity and conspicuous against a thin pool, and the plan has no way of knowing which situation it is in because the depth never entered the calculation.

Inverting the order fixes it. Look at depth, set the band, then let the budget tell you how many trades that band buys and how long the window can be. If the answer is fewer trades than the pacing curve wanted, that is information: either the window shortens, the budget rises, or the objective changes. All three are better outcomes than silently trading at a size the pool cannot absorb.

This also stops a subtle circularity. If the budget sets the size and the size sets the trade count and the trade count sets the wallet count, then every downstream parameter is ultimately derived from an accounting figure. Nothing in that chain ever touched the market the run is about to enter.

Depth is the actual constraint

Depth is how much can be traded before the price moves by a given amount. It is a property of the pool at the moment of the trade, it differs between venues holding the same pair, and it changes across a run because the run itself is part of what changes it. A plan that reads depth once and treats it as fixed for ten hours is assuming something it has not checked.

Read it at the source. Pool reserves and program state are on chain and readable directly rather than through a summary card, and the account model that exposes them is described in the Solana developer documentation. Aggregator displays are convenient and they are downstream of the state that actually decides execution.

Different pool designs behave differently at the same nominal depth. A constant-product pool and a concentrated-liquidity pool with the same headline number will absorb an identical trade very differently, because in one case the liquidity is spread across the whole curve and in the other it is placed in a band that the trade may or may not sit inside. The plan should name the venue and the design, not just a depth figure.

The floor: where fees dominate

Below a certain size, the fixed costs of executing a trade become a large fraction of the trade itself. There is the base transaction fee, there is whatever priority fee the run is paying to land reliably, and there is the pool's own fee taken from the swap. None of these scale down with the trade, so shrinking the size raises their share monotonically.

The practical consequence is that a run of very small trades converts budget into cost rather than into recorded turnover. It still executes, the transaction count looks healthy, and the cost per unit of turnover is poor in a way that only shows up when someone divides one by the other at the close. That division belongs in the plan, before the run, as a check on the proposed band.

The floor is not a fixed number because priority fees are not fixed. During congestion the floor rises, and a band that was comfortably above it in planning can sit on top of it during execution. Where budget and fee behaviour dominate the decision, the arithmetic behind Solana volume bot cost is the same arithmetic that sets this floor, and it is worth computing at both a calm and a congested fee assumption before committing.

The ceiling: where impact dominates

Above a certain size relative to depth, each trade moves the price against itself enough that a meaningful share of the trade value is lost to impact rather than recorded as clean turnover. The loss is not linear: doubling the size more than doubles the impact, which is why the ceiling behaves like a wall rather than a slope.

There is a second cost at the ceiling that plans routinely miss. If the run is round-tripping, the return leg pays impact again, in the opposite direction, on a price the first leg already moved. A size that looked acceptable as a one-way trade can be substantially worse as a pair, and the pair is what the run is actually doing.

The ceiling is also where a run becomes conspicuous for structural rather than statistical reasons. A trade large enough to visibly step the price leaves a mark in the record that does not require any pattern analysis to notice. That is a design consequence of the size choice, not an accident.

Working between floor and ceiling

The usable range sits between the two. The plan's job is to name it, not to find a single optimal point inside it, because there is no such point independent of the objective.

Every row accepts a cost. That is the shape of every parameter decision in this section: the question is never which value is right, it is which failure the objective can afford.

Worked arithmetic for a size band

The figures below are illustrative arithmetic chosen to show the structure of the calculation. They describe no real pool and no real run.

The band came out of two tests, not out of a preference. The lower bound is a fee-share tolerance the plan wrote down. The upper bound is an impact tolerance measured against the pool. Anything inside the band is defensible; the objective decides where inside it the distribution centres.

Change the fee assumption and the floor moves. At a per-trade cost of 0.012 SOL under congestion, the 0.20 SOL trade now carries 6 per cent cost and falls out of the band entirely, which means a run planned at the bottom of the band stops being viable exactly when the network is busiest. Writing both fee scenarios into the plan turns that from a surprise into a stated condition.

Why distribution beats the average

Two runs can have the same average swap size and produce completely different records. One draws every trade from a narrow band around the average. The other mixes a small number of large trades with many small ones. The averages match; the shape of the record does not, and the shape is what anyone reading it actually sees.

A narrow distribution is easy to describe. If nearly every trade is within a few per cent of the same value, that regularity is itself the most notable feature of the run, and it is visible without any analysis. Individual transactions are public, and anyone can read a sequence of them in the Solana explorer without special tooling.

A wide distribution costs nothing extra to configure and changes the record substantially. This is the highest-leverage, lowest-cost decision in the whole parameter block: the average stays where the objective wants it, and the shape stops being the first thing a reader notices.

Four distribution shapes compared

The skewed shape is the default worth reaching for when the objective is turnover, because it keeps the mean where the budget arithmetic wants it while spending most trades near the fee-efficient part of the band. The bimodal shape should be chosen deliberately or not at all; it appears by accident when an operator mixes two size settings mid-run and forgets to record the change.

The round trip and what it costs twice

Most volume activity is round trips rather than one-way trades, and the plan should price it that way. Each leg pays a pool fee, each leg pays transaction and priority fees, and each leg pays impact on a price the previous leg helped move. Budgeting a round trip at the cost of one leg understates it by more than a factor of two once impact is included.

Where the two legs are separated in time, the price may have moved for unrelated reasons in between, and that movement is a cost or a benefit the plan did not choose. Longer gaps mean more exposure to it. This is a genuine trade-off against pattern legibility, because tightly paired legs are easier to read as pairs.

Neither routing across several venues nor a multi-DEX Solana volume bot removes the arithmetic. Splitting a round trip across two pools changes where the impact lands, not whether it is paid, and it introduces a second depth figure the band now has to respect.

How size moves every other parameter

Swap size is the parameter with the most downstream reach, which is why it is decided early and revisited whenever anything else changes.

• Trade count is hourly spend divided by average size, so halving size doubles trade count.
• Interval is the window divided by trade count, so a smaller size shortens the gap between trades.
• Wallet count is trade count divided by the per-wallet ceiling, so it moves with size too.
• Total fee load scales with trade count, so smaller sizes raise the fee share of the budget.
• Impact cost scales faster than linearly with size, so larger sizes raise the impact share.
• Venue split has to respect a separate band per venue where depth differs.

The practical rule that falls out of this: whenever the size band changes, recompute the trade count, the interval and the wallet count before treating the plan as finished. Three lines move and a plan that does not move them is internally inconsistent.

The size block checklist

• The band was derived from depth at the named venue, not from budget arithmetic.
• The floor was tested against a fee-share tolerance written in the plan.
• The ceiling was tested against an impact tolerance read from the pool.
• Both a calm and a congested fee assumption were run through the floor test.
• The distribution shape is named, and it is not fixed.
• Round-trip cost is budgeted as two legs plus impact, not as one leg.
• Every venue in the split has its own band if depth differs between them.
• Trade count, interval and wallet count were recomputed after the band was set.

What swap size does not control

Size does not decide whether activity looks organic. It contributes one dimension of variation and leaves timing, participant structure and venue routing untouched. A perfectly shaped size distribution executed on a fixed interval from a small account set still produces a record with an obvious regularity in it, just not in the size column.

It also does not compensate for a pool that cannot support the objective. If depth is thin enough that even the bottom of a viable band produces meaningful impact, the correct conclusion is that the objective needs revising or the venue needs changing, not that the band should be pushed lower until the arithmetic stops complaining.

Finally, size does not determine cost per unit of turnover on its own. Fees, impact, routing and the number of legs all contribute, and they interact. The band is the parameter that gives you a defensible starting point; the cost figure only exists after the whole block is settled and the round trip is priced honestly.

Questions this plan raises