Planning a volume campaign: the document that comes before the configuration

A volume campaign plan is a one-page document with six blocks, written in a fixed order: objective, constraints, parameters, pacing, stage gates and stop rule. The order is the whole point. Each block narrows the choices available to the block below it, so a plan written top to bottom produces values that can be defended, while a plan assembled from whichever field the interface asked about first produces values that can only be explained.

What a campaign plan actually is

The plan is not a strategy document and it is not a forecast. It is a record of decisions taken while the answer was still unknown. That is its only real property, and it is the property that makes the closing report worth reading. A number written down before the run can be compared with the run. A number written down afterwards is a description of the run wearing the costume of a target.

Most operators already hold this document in their head. The cost of writing it out is fifteen minutes, and the return is that the campaign becomes markable. When the window closes, there is a sentence to check against, a set of values to blame or credit, and a stop condition that either fired or did not. Without the document, the only available verdict is a feeling about a chart.

The second reason to write it is division of labour. A plan that a second person can execute is a plan that survives the operator being unavailable, distracted or wrong. If the document only makes sense to the person who wrote it, the campaign has a single point of failure that has nothing to do with the chain.

The six blocks, in order

Work down the list. Do not skip ahead to the parameter block because it is the one the interface is asking about, and do not fill in the objective last because it is the one that requires thought. The sequence below is the entire method, and the rest of this note is one section per block.

1. ObjectiveOne sentence describing what the run is for, written so that a reader who was not present can decide afterwards whether it happened. If the sentence contains the word "more" without a reference point, it is not finished.
2. ConstraintsWhat was handed to you rather than chosen: the total budget, the wall-clock window, the venues that actually hold the pair, and any timing you do not control.
3. ParametersWallet count, swap size band, interval, and the split across venues. Each value carries a one-line reason that refers back to the objective.
4. PacingThe shape the budget takes across the window, drawn as a curve or written as a table of per-hour allocations, including an explicit decision about the final hour.
5. GatesThe points where the run pauses and continuing becomes a decision. Each gate names the observation it needs and the action taken if the observation is absent.
6. Stop ruleThe written condition that ends the run early, agreed before anybody has an opinion about how the run is going.

A seventh item exists but belongs to a separate note: the report template, drafted before the run and filled in at the close. It is separate because it is the one part of the plan that is written for the future rather than for the console.

Block one: the objective sentence

An objective is testable when three things are true: it names an observable measure, it names the surface that measure is read on, and it names the window it applies to. "Show sustained activity" fails all three. "Produce a readable, non-spiky turnover record on the primary pool across a twelve-hour window" passes all three, and can therefore be marked wrong.

The most common failure is stacking. An objective that says the run should raise turnover, tighten the spread, widen the holder set and hold a listing position at the same time is four objectives sharing one budget. Each of them implies a different swap size, a different wallet count and a different pacing curve, so the parameters end up as a compromise that serves none of them well. Pick one primary and demote the rest to things you will observe but not optimise for.

The second most common failure is an objective phrased as an action rather than a result. "Run the bot for six hours" is a schedule. It cannot fail, which means it also cannot succeed, and a plan built on it will produce a report with nothing to say. Sizing questions of this kind, including how much volume a token needs before a measure moves at all, belong in this block rather than in the parameter block, because they change what the run is for rather than how it is executed.

Block two: the constraints you did not choose

Constraints are the facts the plan has to route around. Budget is the obvious one, but it is rarely the binding one. The window is usually tighter: an operator who has twelve hours of attention available cannot honestly plan a seventy-two hour run with gates that require a human to look at something. Write the window you will actually be awake for.

Venue availability is the third constraint and the one most often assumed rather than checked. Which pools actually hold the pair, what depth each one carries, and whether the routing you intend to use will in practice pick the pool you named. The state of an account and the programs that own it are readable directly from the network, and the account model that makes that possible is documented in the Solana developer documentation. Read the actual pool state rather than the aggregator card describing it.

Fee behaviour is a constraint too. Base transaction fees on Solana are small and predictable; priority fees are neither, because they respond to congestion you do not control. A plan that assumes a fixed cost per transaction across a long window is assuming something about network conditions, and that assumption belongs in the constraint block where it can be checked, not buried in an arithmetic step.

Block three: the parameter block

The parameter block is a short table with a value and a reason on every line. The reason is what makes it a plan. A value without a reason is a default, and a default is the thing the plan exists to replace.

Notice that none of the reasons refer to the budget. The budget constrains how long the parameters can run, not what the parameters should be. Choosing a swap size by dividing the budget by the number of trades you would like is the single most common way a plan inverts itself, because it lets an accounting figure decide a market-structure question.

Block four: the pacing curve

Pacing is the shape of the spend across the window. Four shapes cover almost everything: flat, front-loaded, back-loaded and staged. Flat spreads the budget evenly and is the easiest to reason about. Front-loaded spends heavily early, which suits an objective tied to an event at the start of the window. Back-loaded holds reserve for a close. Staged deliberately leaves quiet gaps between blocks of activity.

The part of the curve that is most often designed by accident is the last hour. A run that simply exhausts its budget produces a hard edge: activity at a steady rate, then nothing. That edge is the most legible thing the entire campaign generates, and it is generated by not making a decision. Decide what the last hour looks like in the plan, whether that is a taper, an abrupt stop you have accepted, or a reserve you deliberately do not spend.

Block five: stage gates

A gate is a written checkpoint where continuing to the next stage is a decision rather than a default. Each gate has two lines: the observation it requires, and what happens if that observation is absent. Both lines are written before the run, because a gate invented while a run is in progress will always be a gate the run passes.

Useful gates are boring. After the probe stage, did transactions land at the venue named in the plan, at the size band written in the parameter block, at roughly the cost per swap the arithmetic assumed. If any of those three is wrong, the main stage would amplify a mistake rather than execute a plan. Confirmed transaction records are readable from a public explorer such as the Solana explorer, and checking a handful by hand at the first gate costs less than discovering the same problem at the close.

Block six: the stop rule

The stop rule is the condition that ends the run early. It exists because the moment when stopping is correct is also the moment when everyone involved is most invested in continuing. Writing it in advance moves the decision to a time when nobody has an opinion.

A rule that is too loose never fires and is decorative. A rule that is too tight fires on ordinary variance in the first hour, which trains the operator to override it, which is worse than having no rule at all because it converts a control into a formality. The workable middle is usually a rule tied to execution rather than to outcome: stop if cost per swap exceeds the planned band by a stated margin, stop if a stage gate fails twice, stop if the venue the plan named stops receiving the flow.

A worked plan with illustrative arithmetic

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

Read what that arithmetic actually did. The budget and window set the hourly rate. Depth set the swap size. The swap size and hourly rate together set the trade count, and the trade count set the interval. Only then did wallet count appear, as a consequence of trade count and a per-wallet ceiling. At no point did the budget choose the swap size, which is exactly the inversion the block order is designed to prevent.

Change one input and watch the chain move. Halve the window to five hours and the hourly rate doubles, the interval halves, and the wallet count rises because the same trades now compete for the same accounts in less time. That sensitivity is the reason the plan is written as a chain rather than as a list of independent fields.

Three plan archetypes compared

Most plans are a variation on one of three shapes. Naming the shape early stops a plan from drifting between them, which is what produces the compromised parameter blocks described earlier.

The probe archetype is the one most often skipped and the one that most often pays for itself. A short run whose only objective is to confirm that cost, routing and size behave as the plan assumed converts three assumptions into three facts, and the main plan can then be written against facts. The tooling side of this is generic across platforms, and a Solana volume bot is only useful here to the extent that it executes the probe exactly as specified rather than approximately.

The pre-flight checklist

Run this before the first transaction. Every item is a question with a yes or no answer, because an item that requires a judgement is a gate, not a check.

• The objective is one sentence, names an observable measure, a surface and a window.
• The objective could be marked wrong by someone who was not in the room.
• Budget, window and venue list are written as constraints, not as choices.
• Every parameter line has a value and a one-line reason referring back to the objective.
• Swap size was chosen against pool depth and not derived from the budget.
• The pacing curve is written out per hour or per stage, including the final hour.
• Each gate names the observation it needs and the action if that observation is absent.
• The stop rule exists, is specific, and is tied to execution rather than to sentiment.
• The report template exists with its verdict lines blank.
• A second reader could execute the plan without asking a clarifying question.

What a plan cannot do

A plan does not make a campaign work. It makes the campaign legible, which is a smaller and more reliable claim. Two runs with identical plans can produce different records because the market they ran into was different, and no amount of planning removes that. What the plan removes is the second kind of uncertainty: not knowing which part of the outcome was your decision and which part was the environment.

It also does not remove the need to be honest at the close. A plan makes dishonesty harder by fixing the target in advance, but it cannot force anyone to read the result. The habit that closes the loop is writing the report template before the run and filling it in immediately after, while the record is still fresh and the temptation to reinterpret the objective has not yet had time to develop.

Finally, a plan is not transferable between pairs without rework. Depth differs, venue behaviour differs, and the observation surfaces that matter differ. Copying a previous plan and changing the token is the fastest route to a parameter block whose reasons no longer refer to anything true. Keep the structure, rewrite the values.

Questions this plan raises