How many wallets a volume run needs, and why the number is a trade-off

Wallet count should be derived, not chosen. The pacing curve fixes how many trades the run executes; a per-wallet ceiling decides how many of those trades any single account may contribute; dividing one by the other produces the count. Choosing a round number first and discovering the consequences later is how a run ends up with either a concentrated record it did not want or a fixed overhead it did not budget for.

One number, two decisions

The wallet count line in a configuration looks like a single setting and behaves like two. The first decision is about footprint: how many distinct signing accounts appear in the record, and therefore how concentrated the activity looks to anyone reading it. The second is about overhead: every account has to be created, funded, and left with a balance it cannot spend, and that cost is paid whether or not the account carries meaningful flow.

These two decisions pull in opposite directions, which is why a single number can be simultaneously too high and too low. A run can carry more accounts than the objective needs and still have every trade concentrated in three of them, because the count controls how many accounts exist and not how the flow is distributed across them.

Keeping the two decisions separate on the page is most of the work. Write the footprint requirement as a sentence about the record, write the overhead as a figure in the budget, and only then write the count that satisfies both.

The footprint side of the decision

Footprint is what the participant column of the record looks like. If a ten-hour run executed a hundred trades from four accounts, the record shows four accounts trading twenty-five times each, which is a describable pattern. If the same hundred trades came from forty accounts, the record shows a wider set with lower individual counts, which is a different describable pattern. Neither is inherently better; they answer different objectives.

What matters is that the objective already decided which pattern it wanted. An objective phrased around distinct signing accounts makes footprint primary and the count becomes close to a direct target. An objective phrased around turnover on a pool makes footprint secondary, and the count exists only to stop concentration from becoming the most obvious feature of the record.

Signing accounts and the programs they interact with are visible in any transaction record, and the account model that makes them visible is part of the runtime rather than a property of any particular tool. The Anza validator documentation describes how transactions carry their signers, which is worth reading once if you intend to reason about footprint at all.

The overhead side of the decision

Every account in the set costs something before it trades. There is the transaction that creates it, the token account the runtime requires it to hold if it is going to receive a token balance, and the rent-exempt minimum that account has to keep on deposit for the runtime to preserve it. None of those are large individually. All of them are multiplied by the count.

The rent-exempt minimum is the part most often left out of a budget, because it is not a fee and it does not disappear. It sits in the account, unavailable to the campaign, until the account is closed and the balance reclaimed. The mechanics are specified in the Solana program documentation rather than being a property of any tool, and the practical effect on a plan is that a large wallet set locks up a sum that the pacing curve was quietly assuming it could spend.

Then there is the operational overhead, which does not appear in any fee schedule. Funding a large set takes transactions. Sweeping it afterwards takes more. Every additional account is another thing that can be misfunded, stranded, or forgotten. That cost is real and it grows faster than linearly once the set is large enough that nobody checks each account individually.

Deriving the count instead of choosing it

The derivation is short. Take the trade count implied by the pacing curve and the swap size band. Decide the maximum number of trades any single account should contribute across the window. Divide. Round up. That is the count, and it now has a reason attached to it that refers back to the objective, which is the property that makes a parameter block a plan.

1. Fix the hourly spendFrom the budget and window in the constraint block. This is arithmetic, not a decision.
2. Fix the swap size bandAgainst pool depth. This is a decision, and it belongs to the swap size note rather than to this one.
3. Derive trades per hourHourly spend divided by average swap size. Round to a whole number and keep the remainder in mind.
4. Derive total tradesTrades per hour multiplied by the window length in hours.
5. Set the per-wallet ceilingThe maximum trades one account contributes. This is the only genuinely free decision in the sequence.
6. Divide and round upTotal trades divided by the ceiling. The result is the count, plus a small margin for accounts that fail or get skipped.

The free decision is the per-wallet ceiling, and it is where the footprint requirement enters. A low ceiling widens the set and raises overhead. A high ceiling narrows the set and concentrates the record. Writing the ceiling down as a number with a one-line reason is what stops the count from being a preference.

Worked arithmetic for a wallet set

The figures below are illustrative arithmetic. They are chosen to show the shape of the calculation, and they describe no real run.

Now vary one input and watch the count move. Halve the swap size to 0.175 SOL and trades per hour double to 22, total trades double to 220, and at the same ceiling the count roughly doubles to 28 before spares. Nobody touched the wallet field; the swap size decision moved it. That coupling is why the derivation runs in this order and why a wallet count carried over from a previous run is almost always wrong.

Vary the ceiling instead. Raising it from 8 to 20 drops the count from 14 to 6, cutting overhead substantially and concentrating the record just as substantially. Neither version is the correct one. The objective decides which failure is cheaper, and the plan records that choice so the close can argue about the right thing.

Even, weighted or tiered distribution

Count is not the whole story. How the trades are spread across the set changes the record more than the raw number does, and the three usual shapes have distinct signatures.

The weighted shape is usually closest to what a turnover objective actually wants, because it delivers the flow without spending overhead on a long tail of accounts that trade twice. The tiered shape costs more to arrange and produces the most internally varied record. The even shape is the simplest to reason about and the easiest to describe in one sentence, which is worth knowing before choosing it.

The failure at each end of the range

Both ends fail, and they fail differently, which is the reason the parameter cannot be optimised in one direction.

The asymmetry worth noticing is that the too-few failures show up in the record and the too-many failures show up in the budget. Operators who only read the record drift upward over successive runs; operators who only read the budget drift downward. Reading both is the entire defence.

Residue: the SOL you do not get back

Residue is what remains in the set when the window closes: the rent-exempt floor each account holds, plus whatever fraction of its funding it did not spend. It is not lost, but it is not available either, and a plan that treats the whole budget as spendable will overshoot.

Two habits keep it honest. First, put the residue estimate in the constraint block as a line item, so the spendable budget is visibly smaller than the total. Second, decide in advance whether the set will be swept and closed after the run or held for the next one, because that decision changes whether residue is a cost or a carry-forward.

The sweep itself costs transactions, and for a large set that cost is not trivial. Where a wallet set is going to be reused, the arithmetic often favours holding it rather than closing and rebuilding. That is a judgement about run cadence, not about the chain, and an automated Solana volume bot will happily execute either policy, so the decision has to be made in the plan rather than left to the tool.

Reusing a wallet set between runs

Reuse trades setup cost against a different kind of exposure. A set that has run before carries its own history, and that history is part of the record for the next run whether or not the plan mentions it. If the objective is about distinct participants, a reused set is answering a question that was already answered.

The practical middle ground most plans land on is a partial refresh: keep the accounts that carried little flow, retire the ones that carried a lot, and add new accounts to cover the difference. That keeps overhead down without making the second run a copy of the first. Write the refresh policy into the plan as a rule rather than deciding it during setup.

The wallet block checklist

• The count was derived from total trades and a per-wallet ceiling, not chosen first.
• The per-wallet ceiling is written down with a one-line reason referring to the objective.
• The distribution shape is named: even, weighted or tiered.
• Spare accounts are included for failures and skips, and the spare count is stated.
• Residue is a line item in the constraint block, not an afterthought.
• The funding plan and the sweep plan both exist before the first trade.
• The reuse or refresh policy for the set is written as a rule.
• Changing the swap size band triggers a recalculation of the count, not a shrug.

What wallet count does not fix

Wallet count does not make a record look organic. It changes how many accounts appear, and it does nothing about the cadence, the size distribution, or the fact that a large set funded from one source is a large set funded from one source. Operators reaching for a higher count to solve a pattern problem are usually solving the wrong parameter; the pattern lives in the interval and the size band.

It also does not compensate for a swap size chosen against a budget rather than against depth. Spreading a badly sized trade across forty accounts produces forty badly sized trades. The count is downstream of the size decision and cannot repair it.

Finally, it does not remove the concentration that funding creates. Every account in the set was funded from somewhere, and that structure exists regardless of how many accounts there are. Treating wallet count as a way to change the shape of that structure is a category error, and a plan that relies on it is relying on something the parameter does not do.

Questions this plan raises