Running a curve campaign one phase at a time

Plan a curve campaign as four documents, not one. A launchpad token prices trades against a reserve that grows as the curve fills, so the same swap size that barely registers at the start can move the quote noticeably later, and the same interval that looked busy in the first hour looks thin once the reserve has multiplied. The parameter block has to be re-derived at each depth, and the handover between depths has to be written down before it happens.

Why a curve campaign is not one campaign

On a bonding curve, price is a function of what the program is holding rather than of what other traders are willing to post. The exact shape of that curve belongs to the launchpad implementing it - the launchpad publishes its own current behaviour, and this desk does not reprint constants that differ between programs and versions. Every fill changes the reserve, and the next quote reflects the change immediately. That single property is what makes a curve campaign different from a campaign on an established pair: the campaign is trading against a mechanism whose state it is itself modifying, and the state at hour nine is not the state the plan was written against at hour one.

The practical consequence is that a configuration ages. A size band derived when the reserve was small will produce far less movement once the reserve has grown several times over, and an operator watching only the chart will read that as the campaign losing effect. Nothing lost effect. The instrument changed underneath the settings while the settings stayed still.

Treating the run as four planned states fixes the ageing problem by making it explicit. Each block is derived against the depth it will actually execute in, each one has its own allocation, and the moment one ends and the next begins is a written decision rather than a drift. It also makes the campaign markable afterwards, because the close can compare four short records against four short intentions instead of one long record against one vague one.

The four depths, defined by what they change

The four phases in this plan are not named after time. They are named after the state of the mechanism, because time is not what changes the arithmetic. A token can sit at the bottom of its curve for a day or clear it in twenty minutes, and in both cases the early-curve block applies for exactly as long as the early-curve state does.

Reading down a column gives you one phase whole. Reading across a row shows how a single decision changes as the token fills its curve, which is the more useful direction the first time through. The size band and the interval are the two fields that move furthest, and they move in opposite directions: the band widens as depth grows, while the interval usually has to shorten to keep a comparable presence in any observation window.

The document: one parameter block per depth

A phase block is short on purpose. Eight fields, each with a value and a one-line reason that refers back to the objective or to the state of the curve. If a block takes more than half a page, the fields have started describing the tool rather than the campaign, and nobody will re-derive it when the curve moves.

The eight fields are the size band, the interval and its jitter, the wallet count and per-wallet ceiling, the buy and sell mix, the allocation for the phase, the priority fee policy, the venue, and the condition that ends the phase. The full sheet with the failure at each end of each range is on the parameter section, and the phase notes fill it in one depth at a time.

What makes it a plan rather than a settings dump is the reason column. A number without a reason cannot be checked at the close, and it cannot be re-derived when the state changes, because nobody remembers what it was answering. A number with one line of reasoning attached survives both.

Deriving a phase block in six moves

The order matters, because each move constrains the one after it. Running the sequence backwards, which usually means picking a budget and dividing it by an hour count, produces a block whose fields have no relationship to the mechanism they will execute against.

1. Describe the depth in one sentenceNot the price and not the market cap: the reserve currently sitting in front of a trade, and roughly what share of it a single trade at your intended size would represent.
2. Derive the size bandThe floor is where costs stop being a rounding error against the trade. The ceiling is where the quote moves enough that the campaign is paying its own slippage twice per round trip. Both ends are functions of the depth you just described.
3. Choose the pacing patternFlat, front-loaded, back-loaded or event-driven. The pattern is a decision about what a reader sees in an observation window, and it belongs to the objective rather than to the tool.
4. Derive the intervalPhase allocation divided by average size gives trade count; trade count divided by the phase length gives the base interval. Jitter is then added deliberately, not left at whatever the default happened to be.
5. Ring-fence the allocationWrite the phase budget as a number the later phases cannot borrow from. A campaign that spends its migration allocation during the mid curve has made the most expensive mistake available to it.
6. Write the exit conditionOne sentence, checkable by someone else, agreed before the phase starts. It ends the phase either because the state changed or because the allocation ran out, and it says which of those two it is.

Six moves, four times. The repetition is the point: the second and third passes take minutes because the objective and the wallet policy are already fixed, and only the depth-dependent fields have to move.

Worked arithmetic: one budget, two depths

The figures below are illustrative arithmetic. They are chosen to show how a derivation chains together, and they describe no real token, curve or run.

Same budget, same window, same objective, and the block is unrecognisable. The trade count fell by nearly three quarters and the gap between fills stretched from under two minutes to nearly seven. An operator who carried the early block forward would be executing four times as many trades as the depth calls for, paying four times the fee count for it, and producing a cadence that has no relationship to anything the plan intended.

The reverse error is quieter and more expensive. Carrying a late block backwards into a shallow reserve means every trade is oversized for the depth in front of it, and the campaign spends its allocation moving the quote against its own next fill. That failure does not look like a failure on a chart, which is exactly why it has to be caught in the derivation rather than in the record.

The transitions, which are where damage happens

Phases are easy. Transitions are where campaigns quietly break, because a transition is the only moment when the plan and the mechanism can disagree without anyone noticing. Three of them exist in this model, and each needs a written trigger and a written handover.

The third handover is the one that costs real money when it is missed, because it is the only one where the mechanism can change without the campaign doing anything. The first two are consequences of the campaign's own flow and can be anticipated by watching the derivation. Migration is an event, and a route pinned to a venue that no longer holds the liquidity either fails outright or fills somewhere the plan never considered. Tools differ in how they handle this: a Pump.fun volume bot that resolves the venue at execution time behaves very differently from one that resolves it once at configuration time, and knowing which you have is a planning fact, not a preference.

What carries across a transition and what does not

Three things should survive every handover unchanged, and treating them as fixed is what stops the campaign becoming four unrelated runs. The objective is the first: one sentence about what the campaign is for, phrased so a reader who was not present could mark it afterwards. If the objective changes at a phase boundary, the campaign did not transition, it restarted.

The wallet set policy is the second. How many accounts carry the flow, what ceiling any one account is held to, and whether the set is refreshed between phases are decisions about footprint, and footprint is a campaign-level property rather than a phase-level one. Changing the policy mid-campaign produces a record that reads as two different operators, which is rarely what anyone wanted.

The measurement definitions are the third. Which window is being counted, what counts as a trade, and how the close will separate campaign flow from everything else have to be fixed before the first phase, because a definition changed halfway through makes the four phases incomparable. Everything else - size, interval, allocation, venue, mix - is expected to move, and a plan that keeps them still across a handover is not being stable, it is being stale.

Measuring a phase rather than a campaign

A campaign-level number hides the thing you most need to see, which is whether each block behaved the way its derivation predicted. Four short records answer that. One long record does not, because a phase that overperformed and a phase that produced nothing average out into a figure that looks unremarkable and explains nothing.

The minimum per phase is four lines: what the block predicted for trade count, what the record shows, what the phase actually cost including fees and priority fees, and one sentence on whether the exit condition fired or the allocation simply ran out. Those four lines take a minute to write and they are the entire difference between a campaign you can improve and a campaign you can only repeat.

Transaction records for a signing account are public and can be read directly from a block explorer rather than taken from a tool's own summary, and reconciling the two is worth doing at least once per campaign. The Solana block explorer is one way in; any explorer that shows per-account transaction history serves the same purpose. What matters is that the closing numbers came from somewhere a reader could check.

Splitting the budget between phases

The split is a statement about which phase the campaign is actually for, and writing it down forces that statement into the open. A front-loaded split says the launch window matters most. An approach-weighted split says the campaign is about the transition. An even split usually says nobody decided, which is a legitimate thing to discover before the run rather than after it.

Two rules keep the split honest. First, allocations are ring-fenced: a phase that finishes early returns its remainder to a stated place, and a phase that runs out stops rather than borrowing forward. Second, the migration phase is funded before the mid curve is, because the mid curve will always find a use for spare budget and the transition will not get a second chance.

Cost per swap is what turns an allocation into a trade count, and it is not only the swap itself. Network fees, priority fees, the spread the mechanism charges and any platform fee all sit between the allocation and the flow it buys, and the first two are governed by a fee model documented in the Solana documentation rather than by any tool. A campaign that budgets on notional size alone will run short, and the gap widens exactly where trade count is highest. Working through the full cost stack once, as Solana Volume Bot Pro and comparable consoles set it out, is worth doing before the first allocation is written rather than after the third phase comes up short.

The phase plan checklist

• The objective is one sentence and it is identical in all four blocks.
• Each phase has its own size band, derived against the depth that phase will execute in.
• Each phase has a trade count computed from its allocation and average size, not assumed.
• Each interval was derived from trade count and phase length rather than left at a default.
• Every allocation is ring-fenced and the migration phase was funded first.
• Every phase has an exit condition a stranger could check.
• Each of the three handovers names the fields that must change at that boundary.
• The venue is resolved at execution time or the plan states explicitly that it is not.
• Measurement definitions were fixed before phase one and have not moved since.
• Each phase gets four closing lines, and they are written from the record rather than from memory.

What phase planning does not fix

Phase planning makes a campaign legible. It does not make one work. If the objective is unmarkable, splitting it into four unmarkable objectives changes nothing, and the close will be exactly as vague as it would have been. The document is a way of forcing decisions into the open, not a way of making the decisions correct.

It also does not make activity look organic. Cadence, size distribution and the funding structure behind a wallet set are all visible in the record, and a plan that re-derives its numbers cleanly at every depth can still produce a record with an obvious signature. That is a separate problem, and pretending a phase split solves it is how operators end up surprised.

Finally, it does not remove the mechanism risk that sits under everything on a launchpad. A curve can complete faster than any plan anticipated, migration can land in the middle of a phase, and a token can stop being interesting to anyone for reasons no parameter block addresses. The plan's job is to make sure that when those things happen, the campaign stops on a written condition instead of continuing on momentum.

The same questions, asked at this depth