Staging a campaign so that continuing is always a decision

Staging cuts a run into four parts with a written gate between each pair: a baseline that records what the pair looked like before anything happened, a probe that tests the plan's assumptions cheaply, a main stage that carries most of the budget, and a close that ends the run on purpose. The point is not ceremony. A single-stage run contains exactly one decision, taken before anything was known, and staging adds three more taken after something was.

Why one stage is one decision

An unstaged run commits the entire budget to a set of assumptions: that trades will land at the venue named in the plan, at roughly the cost the arithmetic assumed, at a size the pool absorbs as expected, and that the objective's threshold is reachable at the planned rate. Every one of those is checkable within a few minutes of trading, and an unstaged plan checks none of them until the run is over.

The cost of checking is small and specific: a slice of budget spent producing information instead of output. The return is that the main stage executes against confirmed facts rather than assumptions, and that a plan which was wrong gets stopped while most of the budget is still available.

There is a second, less obvious return. Stages create natural places to write things down. A run with three gates produces three timestamped observations, and those observations are what make the closing report an account rather than a summary. Runs without seams tend to produce reports that describe the total and nothing else.

Stage one: the baseline nobody captures

The baseline is a record of the pair before the campaign touched it. It is the cheapest stage, it consumes no budget, and it is the one most often skipped, which is why so many closing reports compare a run against nothing.

Capture whatever the objective's measure is, on the surface the objective named, for a period comparable to the run window. If the objective is turnover on a named pool across ten hours, the baseline is turnover on that pool across a comparable ten hours immediately before. If the objective is hours containing activity, the baseline is the count of such hours in the prior period.

Capture it as a stored figure with a timestamp, not as a screenshot impression. Transaction-level history is public and readable from an explorer such as the Solana explorer, so the baseline can be reconstructed later, but reconstructing it after the fact invites the same selection problem that unwritten objectives invite. Record it before the run, and record the method used so the closing figure is computed the same way.

One more line belongs in the baseline: a note of anything unusual already happening. A pair that was already active for reasons unrelated to the campaign will produce a closing comparison that flatters or damns the run for reasons the run did not cause, and the only defence is having written down that the condition existed.

Stage two: the probe

The probe is a short run whose objective is not turnover but information. It executes a small number of trades at the planned size band, on the planned venue, through the planned routing, and its success condition is that three assumptions turn out to be true.

1. RoutingDid the trades execute at the venue the plan named, or did routing send them somewhere else? This is the assumption most often wrong and the easiest to check.
2. CostWhat did a trade actually cost, all in, including the pool fee, transaction fee and priority fee at current conditions? Compare it against the figure the plan's arithmetic used.
3. Size behaviourDid a trade at the top of the size band execute within the impact tolerance the plan wrote down, or did the pool behave differently from the reading the band was derived from?

A probe is deliberately too small to matter as output. That is a feature and it is also why probes get cut from plans under time pressure: the stage produces nothing anyone can point at. The correct framing is that the probe is not part of the campaign, it is part of the plan, and skipping it means the main stage is the probe with the budget attached.

Size the probe by what the measurement needs. Enough trades to see a cost distribution rather than a single sample, spread over enough time to catch more than one network condition, and at least one trade at each end of the size band. That is usually a small number of trades and a short window, and it is not a fixed percentage of anything.

Stage three: the main stage

The main stage carries most of the budget and executes the pacing curve. If the gate after the probe passed, this stage is mechanical: the parameter block is confirmed, the curve is written, and the work is to execute it without improvising.

The discipline that matters here is refusing mid-stage changes that are not written down. Adjusting the size band because an hour looked quiet, or raising the rate because the record seemed thin, are the two most common ways a staged plan turns back into an unstaged one. If a change is genuinely warranted, it belongs at a gate, with a timestamp and a reason, so the closing report can attribute the two halves separately.

The main stage is also where execution quality becomes a monitoring question rather than a planning question. Landed versus attempted trades, actual cost against planned cost, and venue confirmation are the three things worth watching, and all three were already defined during the probe. What counts as landed is a property of the runtime rather than of a dashboard, and the confirmation semantics behind it are set out in the Solana developer documentation. Whether that monitoring comes from a Solana volume bot platform or from reading the chain directly, the figures the plan needs are the same three.

Stage four: the close

The close is the deliberate end of the run, and it is a stage rather than an event because it has its own budget line and its own shape. This is where the taper, the accepted hard stop, or the held reserve from the pacing decision actually happens.

It also has a housekeeping component that plans routinely forget to budget: sweeping wallets, closing accounts where that is the policy, and reconciling what was actually spent against what the plan allocated. Those actions cost transactions, and a plan that allocated one hundred per cent of the budget to trading will find the close funded out of nothing.

The last item in the close is filling in the report template. Doing it immediately matters more than doing it well, because the specific observations that make a report useful decay within hours. The template already exists; the close is where its blanks get filled.

The three gates and what each one asks

A gate is two lines long: the observation required to continue, and the action taken if that observation is absent. Both are written before the run. A gate written during a run is a gate the run passes.

Three gates is usually the right number for a single-session run. Longer runs sometimes justify a mid-main gate, but every additional gate dilutes the others, because a plan with seven checkpoints trains its operator to wave things through.

Worked arithmetic for a stage split

The figures below are illustrative arithmetic showing how a budget divides across stages. They describe no real run.

Read what staging actually cost. The hourly rate fell by twenty per cent and the coverage slack fell from five trades to three. That is the price of the probe and the close, stated plainly. In exchange, the main stage runs on a measured cost figure instead of an assumed one, and if the probe had shown routing going to the wrong venue, the entire thirty-two SOL would still be unspent.

If the coverage check had failed, the plan has three honest responses and no dishonest ones: shrink the probe, shorten the window so the same budget fills fewer hours, or lower the coverage threshold in the objective and record that it was lowered. Quietly proceeding and hoping is not on the list.

What happens when a gate fails

A gate that has no failure action is decoration. The action does not have to be dramatic, and in most cases it should not be, but it has to be specific enough that nobody has to invent it under pressure.

• Revise: adjust the parameter block using the observed figures, then re-run the gate check against the revised numbers.
• Reduce: continue at a smaller size and rate, accepting a lower objective threshold that is written down as a revision.
• Redirect: move to a different venue from the constraint block, and repeat the probe against it before committing.
• Stop: end the run, sweep, and write the report against the objective as originally stated.

Note that three of the four keep the run alive. Gates are not primarily abort switches; they are places where the plan gets to use information it did not have when it was written. A plan whose only failure action is stop will be overridden the first time a gate fires for a minor reason.

Stage drift and how plans lose their seams

Drift is the gradual erosion of the boundaries between stages until the run is effectively unstaged. It has three usual causes and all three are procedural rather than technical.

The first is starting the main stage while the probe is still running, because the probe looked fine after five trades. The gate then evaluates a probe that overlapped a stage it was supposed to authorise, and the cost figure it produces is contaminated by the main stage's own activity.

The second is treating the probe as output. Once anyone starts describing probe trades as part of the campaign's results, the probe stops being a measurement and starts being a stage nobody wants to declare a failure. Keep its trades in the record and out of the verdict.

The third is the unrecorded mid-stage change. It is the most damaging because it is invisible at the close: the record shows one continuous main stage, the operator remembers there was an adjustment, and no timestamp exists to split the two. The rule that prevents it is simple and unpopular: a change without a written time and reason is not made.

The staging checklist

• The baseline figure is captured, timestamped, and the method for computing it is recorded.
• Anything unusual already happening on the pair is noted in the baseline.
• The probe has its own objective, expressed as three assumptions to confirm.
• The probe includes at least one trade at each end of the size band.
• Each of the three gates has a required observation and a specific failure action.
• Failure actions include at least one option other than stop.
• The main stage budget is the total minus the probe and the close reserve, not the total.
• The coverage check is re-run against the reduced main-stage rate, not the unstaged rate.
• The close has a budget line for sweeps and account closures.
• Mid-stage changes require a written timestamp and reason before they are made.

What staging does not buy you

Staging does not improve the result. It improves the attribution of the result, which is a different and more durable thing. A staged run that misses its objective produces a report saying which stage it missed it in and what the gate observations were at the time; an unstaged run that misses the same objective produces a report saying it missed.

It also does not protect against a bad objective. Gates check whether execution matches the plan, and a plan built on an untestable objective will pass every gate and still produce a verdict nobody can mark. Staging is downstream of the objective and cannot repair it.

Finally, staging costs budget and time, and on a very small run that cost can exceed the value of the information. The honest version of the trade-off is that below some size, the whole run is a probe, and it should be labelled one: a small run whose purpose is to learn what the pair does is a legitimate campaign, provided the report says so and does not quietly present it as an attempt at output.

Questions this plan raises