Budget caps, duration and where a run stops
A run needs a stopping condition decided in advance, because deciding one while a progress bar is moving is how budgets get overshot. These fields are the least interesting on the form and the only ones that can cost you more than you intended.
In one line
A budget cap is the amount the panel is allowed to spend before it stops itself, and duration is the window it spreads the work over; whichever limit binds first ends the run.
The short answer
A budget cap is the amount a panel may spend before it stops itself. A duration is the window it spreads the work across. Set both. Whichever one binds first ends the run, which means a mistake in either is caught by the other. The one question you must answer before trusting a cap is what it counts: the notional value of trades, the SOL actually consumed, or both.
That question is not pedantry. On the run described in the previous field guide, a cap counting notional and a cap counting consumption differ by a factor of roughly fifty, and the same number typed into the same box means two entirely different runs.
The three limits panels expose
Almost every panel offers some subset of these, under various names. Understanding which ones you have is the first step, because a missing limit has to be replaced by you watching the screen.
The spending cap
Named budget, cap, max spend or total. It counts something as the run proceeds and halts when the number is reached. This is the limit that protects your money, provided you know what it counts.
The duration
Named duration, run time, window or schedule length. It halts the run when the window closes, whether or not the spending cap was reached. This is the limit that protects your afternoon, and it also determines pacing.
The per-unit ceiling
Named max per wallet, max swaps, or trade count. It bounds the work rather than the money: this many trades, or this much per wallet, and no more. It is the limit that protects you from a pricing surprise, because it caps the quantity of things that can each cost more than expected.
A panel with all three is a panel you can reason about. A panel with only a duration is one where the cost is whatever the market decides during that window, which is an uncomfortable way to run anything.
What each cap counts and ignores
Read this table against your own panel's help text before a first run. If the help text does not say, treat the cap as counting notional, which is the less protective assumption, and set it low enough that being wrong is cheap.
| Cap type | What it counts | What it does not count |
|---|---|---|
| notional cap | The value of trades executed, buys and sells together | Fees, slippage, rent deposits, retries |
| spend cap | SOL consumed: fees, slippage and the net of the trading | Working capital that circulates and comes back |
| deposit cap | Nothing directly; the run simply stops when funds run out | Any warning before the funds are gone |
| per-wallet cap | The amount any single wallet may trade or spend | The total across wallets, which is count times cap |
| trade count cap | The number of attempts or the number of landed swaps | The cost of each one, which varies with the venue |
The distinction between attempts and landed swaps in the last row is worth pinning down too. A cap on attempts protects the fee budget, because failed attempts still cost fees. A cap on landed swaps protects the turnover target but allows an unbounded number of failures underneath it. On a congested day those are very different bills.
Which limit ends the run
With two or three limits set, the run ends at whichever is reached first. This sounds obvious and is the source of most confusion about why a run stopped early, so it is worth stating as a rule: the binding limit is the one to look at, and the report header should name it.
If the cap binds first
The run stops before the window closes. Either the venue cost more than expected, or the pacing was too fast for the budget. The report's cost breakdown will show which, and the answer is usually slippage rather than fees.
If the duration binds first
The window closed with budget unspent. The schedule was slower than the budget allowed, which is not a failure: it means you can either extend the window or increase the size next time, but not both at once.
A third case exists and is the one to avoid: neither binds, because the funding wallet emptied first. That is not a stopping condition, it is running out. The difference matters because a run that stops on a cap finishes cleanly, sweeps what is left and writes a report, while a run that stops on an empty wallet may leave positions half-completed and workers stranded with tokens they cannot sell for want of fee money.
The interaction, worked
Numbers make this concrete. All figures are illustrative and chosen for arithmetic, not drawn from any real run.
Take a schedule of 300 swaps at 0.05 SOL, spread over two hours, on a venue charging one per cent. Notional is 15 SOL. Assume fees and slippage together come to roughly 1.6 per cent of notional, so consumption is about 0.24 SOL. Now set a cap of 5 SOL and see what happens under each definition.
| Cap definition | Reached after | Result |
|---|---|---|
| notional | 100 swaps, about 40 minutes in | Run ends a third of the way through, having consumed about 0.08 SOL |
| spend | Never, within this schedule | Duration binds instead; the full 300 swaps run and consume about 0.24 SOL |
| per wallet, 20 wallets | Effective total of 100 SOL | No practical limit at this size; the cap is not doing any work |
Three identical numbers, three different runs. The per-wallet row is the one that catches people out most often: a limit of 5 SOL per wallet across twenty wallets is a 100 SOL limit, and it reads as a small number on the form. Whenever a cap is expressed per unit, multiply it by the unit count before deciding whether it is conservative.
Duration is a pacing control
People set duration as if it decides how much work happens. It does not. The work is decided by trade count and size; duration decides how thinly that work is spread. The relationship is one division: trades divided by minutes gives the pace the panel must keep.
Three hundred swaps in two hours is two and a half per minute, which is unremarkable. Three hundred swaps in ten minutes is thirty per minute, which stops being a schedule and becomes a burst. Bursts fail differently: more transactions compete for inclusion at once, retries stack up, and the fee cost per landed swap rises exactly when you are least able to watch it.
The other direction has its own problem. A window far longer than the work leaves long gaps between trades, and a panel that has to keep a connection alive for hours has more chances to lose it. Somewhere in the middle is a pace that lands reliably and does not require anybody to sit and watch, and finding it is the practical reason to keep a first run short.
A pacing sanity check
Divide trades by minutes before you start. If the answer is more than a handful per minute, either lengthen the window or reduce the trade count. If the answer is less than one every few minutes, the window is doing nothing except keeping a session open, and a shorter run repeated later is easier to supervise.
What happens at the moment of stopping
Stopping is not instantaneous, and knowing the sequence prevents the most common panic during a run. Whether the stop was automatic or you pressed the button, the same five things happen in roughly this order.
-
The scheduler stops issuing
No new trades are built. This is immediate and is the part that responds the moment you click.
-
In-flight transactions resolve
Anything already signed and sent is out of the panel's hands. It will land or expire on its own, which is why totals can move slightly after a run shows as stopped.
-
Retries are abandoned
Failed attempts waiting for a retry are dropped rather than sent. A well-built panel marks them as cancelled rather than failed, because the distinction matters when you read the report.
-
Positions are left as they are
A stop is not a sell. If the schedule ended mid-cycle, worker wallets may hold tokens they had not yet sold. Nothing about a stop converts them back, and doing so is a separate action.
-
Sweeping happens, or does not
Some panels return remainders automatically, some offer a button, some do neither. This is the step where a run either finishes tidily or leaves a long tail across every wallet it created.
The fourth step is the one to plan for. If a run stopping early can leave tokens unsold, then the emergency stop is not a full reversal and should not be treated as one. Where a tool offers an option to finish the current cycle before stopping, that option is usually worth the extra minute it costs.
Top-ups, extensions and second runs
Two hours in, the cap binds and the panel offers to continue. This is the moment the fields on this page were set to protect you from, and it deserves a rule decided in advance.
Extending a run mid-flight has one specific hazard: the numbers you are looking at are partial. Costs so far are not necessarily representative, because venue conditions change and the cheap part of a schedule often comes first. A decision made against partial data, with the interface encouraging continuation, is exactly the decision people regret.
The alternative is deliberately clumsy and works better. Let the run end. Read the report. Compare what it actually cost against what you estimated. Then decide, from a stopped state, whether a second run is worth funding. The friction is the feature: it moves the decision from a progress screen to a finished report.
Sizing a cap you can afford
Not the maximum you could spend. The amount whose complete loss would leave you indifferent, because the honest framing of a volume run is that the money is spent when the transactions land, and nothing about the mechanism returns it.
- Start from the consumption estimate, not the notional. The float circulates; fees and slippage are what leave.
- Add a margin for the assumption most likely to be wrong. That is slippage, every time, because it depends on conditions you do not control.
- Set the cap at the total you accepted, not above it. A cap set with headroom for comfort is not a cap, it is an intention.
- Fund the wallet with the cap plus overheads, and nothing else. The wallet balance is the last line of defence when a cap definition turns out to mean something unexpected.
- Write down what you expected before you start. The comparison against the report afterwards is the only way a second run is better informed than the first.
Tools that make this easy tend to show a derived estimate under the fields and a clear statement of what the cap counts, which is a reasonable thing to expect from a professional Solana volume bot and a reasonable thing to walk away from when it is missing. A cap you cannot interpret is not protection; it is a number that makes you feel protected.
The checks before you start
- You know what the cap counts. Notional or consumption. If the documentation does not say, assume notional and set it low.
- Per-unit limits have been multiplied out. Per-wallet caps times wallet count is the real ceiling.
- Trades divided by minutes gives a pace you believe. Not a burst, not a trickle.
- A duration is set even though a cap exists. Two independent stopping conditions, so one mistake is caught by the other.
- The funding wallet holds the cap plus overheads and no more. The balance itself becomes a third limit.
- You know what a stop does to open positions. Whether it sells, whether it sweeps, and whether either is automatic.
Where this leads
The form is now complete. Token, venue, wallet count, swap size, cap and duration are all set, and each one was decided against something real rather than against a default. What remains is the part that tells you whether any of the estimates were right.
The last walkthrough on this site covers the run report: what the header totals mean, what each status in the log is telling you, and how to check the whole thing against a block explorer. It is where the arithmetic on this page either holds up or gets corrected, which makes it the most useful page to read immediately after your first run finishes.
Written by The Setup Desk. Field names and screen layouts differ between tools, so this page describes what a setting is for rather than where a particular build puts it; any figure in an example is arithmetic chosen to show the shape of the calculation and describes no real account. The way these pages are put together is set out in how this desk works, and anything that reads wrong can be sent back as a correction.