Duration and pacing: giving the budget a shape instead of a rate

Pacing is the shape of the spend across the window, and it is a separate decision from the rate. A budget divided by an hour count gives you a rate; a pacing curve tells you which hours get more than that rate, which get less, what happens in the first hour, and what happens in the last. Most plans specify the rate, inherit a flat curve by default, and discover their edges only when reading the record afterwards.

A rate is not a shape

Take a forty SOL budget and a ten hour window. The rate is four SOL an hour. That much is arithmetic and it is not a plan decision, because there was no choice involved. The plan decision is whether hour one carries four SOL, or eight, or one, and whether hour ten carries anything at all.

The distinction matters because the objective almost never applies uniformly across a window. An objective tied to no empty hours cares about the minimum, not the mean. An objective tied to a concentration around an event cares about a specific slice. An objective about total turnover across the window is genuinely indifferent to the shape, which is worth knowing because it means the shape can then be chosen for other reasons.

Writing the curve out as a table of per-hour allocations takes two minutes and converts pacing from an assumption into an artefact. It also makes reconciliation at the close trivial: the record either matches the table or it does not, hour by hour, and where it does not there is a specific hour to ask about.

Duration is decided before the division

Duration belongs in the constraint block, not in the parameter block, because it is usually handed to you rather than chosen. The honest input is not how long you would like the run to be, it is how long you will actually be available to supervise it, plus whatever external timing the campaign is pinned to.

Plans routinely overstate this. A seventy-two hour window with three gates that require a person to look at a record is a plan that will have unattended gates, and an unattended gate is not a control, it is a comment. Either shorten the window to the supervised hours or convert the gates into automatic conditions that can fire without anyone present, and say in the plan which one you did.

Once duration is fixed and the budget is fixed, the rate follows, and only then does the shape become a question. Doing it the other way around, choosing an appealing shape and stretching the window until the budget fits it, produces a run whose length was decided by a curve nobody defended.

Four pacing curves and what each serves

Four shapes cover almost every plan. The differences between them are not cosmetic; each one accepts a different cost and satisfies a different objective.

The staged curve is the one most often produced by accident and least often chosen on purpose. A run that stalls because a wallet emptied and resumes when it is topped up has produced a staged curve without meaning to, and the resulting gaps are indistinguishable from designed ones except in the plan document.

Interval, jitter and the cadence problem

Interval is the gap between trades and it is derived, not chosen: the hourly allocation divided by the average swap size gives trades per hour, and the hour divided by that gives the mean interval. What is chosen is the variance around that mean.

A fixed interval is the most describable timing pattern a run can produce. It requires no analysis to notice; a reader scanning timestamps sees the regularity immediately. Adding jitter costs nothing and removes that particular signature, but jitter has its own shape. Drawing every gap uniformly from a band around the mean is less regular than a fixed gap and is still a distribution with a recognisable form.

There is a floor on how tight an interval can usefully get, and it is set by the network rather than by the plan. Solana produces blocks on a short target interval, and transactions land in slots rather than continuously; the scheduling and confirmation behaviour is described in the Anza validator documentation. Planning intervals shorter than confirmation behaviour supports produces queued trades that arrive in bursts, which is a shape the plan did not choose.

Worked arithmetic for a pacing table

The figures below are illustrative arithmetic. They show how a curve becomes a table and they describe no real run.

That last line is the reason the table exists. Under a flat curve the coverage requirement passed comfortably everywhere. Under the front-loaded curve it passes at hour ten by a single trade, which means one failed transaction in the final hour breaks the objective. The plan can now respond deliberately: flatten the tail weights, raise the budget, or lower the coverage threshold. What it cannot do is discover the problem at the close.

Notice too that the weights sum to the hour count. Keeping that constraint explicit means the curve can be reshaped freely without accidentally changing the total, and any weight change immediately shows which hour lost what.

The edges: the first hour and the last

The first hour is where a run establishes whatever texture it is going to have, and it is also where every configuration error is still cheap to fix. Plans that start at full rate spend their most expensive hour on unverified assumptions. A first hour deliberately run below rate, with a gate at the end of it, converts the assumptions into observations before the bulk of the budget is committed.

The last hour is the part most often designed by omission. A run that simply exhausts its budget produces a hard edge: steady activity, then nothing, at a timestamp determined by an accounting event. That edge is the single most legible artefact the campaign generates, and it was produced by not making a decision.

There are three defensible choices and the plan should name one. Taper the final hours so activity decays rather than stopping. Accept the hard stop as a known cost, having decided it does not matter for this objective. Or hold a reserve that is deliberately not spent, so the run ends with budget remaining and the stop is a decision rather than a consequence. All three are fine. Silence is not.

Observation windows and why they set the floor

Whatever surface the objective named aggregates over some period. If activity is sparse enough that many aggregation periods contain no trades, the run is real on chain and invisible on the surface the objective is read on. That mismatch is a pacing failure even though every trade executed correctly.

This gives a hard floor on the interval that has nothing to do with cost. Work out the aggregation period of the named surface, then check that the slowest hour of the pacing table still puts activity into each period with margin. If it does not, either the curve needs flattening or the window needs shortening so the same budget fills a smaller period at a higher rate.

The same reasoning caps the useful duration of a fixed budget. Stretching forty SOL across seventy-two hours produces an hourly rate that may sit below the readable floor for every hour of the run, which is a comprehensive way to spend a budget and record nothing. A shorter window at a higher rate is often the honest answer, and a volume bot for Solana will execute a seventy-two hour plan exactly as faithfully as a ten hour one, so the constraint has to be applied in the plan.

Pacing against conditions you do not control

A pacing table assumes trades land when they are sent. Under congestion they may not, and the run drifts: the hour that was supposed to carry 6.4 SOL carries 4.1, and the shortfall has to go somewhere. Deciding in advance where it goes is a plan decision, and the difference between attempted and landed is readable per hour from the record itself; the transaction lifecycle that produces that difference is described in the Solana developer documentation.

Two policies are common and they behave very differently. Catch-up rolls the shortfall into subsequent hours, which preserves the total and distorts the shape, sometimes producing a burst that no one designed. Drop discards the shortfall, which preserves the shape and leaves the run under budget at the close. Neither is wrong; a plan that has not chosen between them will do whichever the tool defaults to.

The related decision is what happens to priority fees under congestion. Raising them preserves the schedule at a higher cost per trade, which can push the bottom of the size band below the fee-share tolerance. Holding them flat preserves the cost per trade and lets the schedule slip. Write down which one the run does, and at what threshold.

The failure at each end of the range

The pacing block checklist

• Duration came from the constraint block and reflects supervised hours, not preference.
• The curve is named: flat, front-loaded, back-loaded or staged.
• A per-hour allocation table exists and the weights sum to the hour count.
• The slowest hour still clears the objective threshold with stated slack.
• The mean interval is derived from the hourly allocation and the size band, not chosen.
• Jitter is specified as a band rather than left at a default.
• The interval floor was checked against confirmation behaviour, not just against cost.
• The first hour has a gate at the end of it.
• The final hour is an explicit decision: taper, accepted hard stop, or held reserve.
• The shortfall policy under congestion is written: catch-up or drop.

What pacing cannot do

Pacing shapes when the budget is spent. It does not change how much turnover the budget converts into, which is decided by the size band and the fee and impact structure underneath it. A beautifully shaped curve executed at a size below the fee floor produces an elegantly distributed waste of budget.

It also does not make a run unreadable. Every curve is a shape and every shape can be described. What pacing controls is which shape the record has and whether that shape was chosen; it does not offer an option with no shape at all, and plans that pursue one usually end up with the default shape by another route.

Finally, pacing cannot compensate for a window that is wrong for the objective. If the objective is tied to a moment and the window does not contain that moment, no curve fixes it. That failure belongs to the constraint block, and the correct response is to move the window rather than to reshape the spend inside it.

Questions this plan raises