What Budget Does a Volume Run Actually Need?

The honest answer to the budget question

There is no publishable minimum. A run needs enough to cover four separate things: the software charge, the on-chain cost of every transaction it signs, the rent-exempt deposits its wallets open, and the working capital those wallets hold while trading. The first two are gone once spent; the last two are largely returnable. Size the run against the pair you are trading, not against a figure from a group chat.

Any number offered as a universal floor is wrong before it is typed, because it moves with the venue, the depth of the pair, the wallet count, the order size per leg and the number of round trips. A figure adequate on a deep pool is invisible on a thin one, and the same figure on a thin pool buys an obvious footprint.

What transfers between runs is the method rather than the total. Below is the cost stack broken into lines, a worksheet you can copy into a spreadsheet, and a way to derive the smallest run whose outcome you could still read. Every figure here is either a protocol constant, which does not move with market conditions, or arithmetic sitting inside a block marked illustrative, whose assumptions you should replace with your own measurements before any of it informs a decision.

Spent money and parked money

The most common budgeting error is adding up wallet funding and calling that sum the cost of the run. Most of that money is parked: it sits in sub-wallets and rent-exempt deposits, it remains yours, and it returns when you consolidate and close accounts. What must be available before you start and what the run costs you are different questions.

Spent lines leave and do not return: the software charge, the base fee on every signature, the priority fee attached to it, the spread and price impact each round trip concedes to the book, and the fees burned by failed attempts. Parked lines are the deposit behind every account you open and the balance each wallet needs to trade at all.

The cost stack, line by line

The software charge is whatever the operator bills, in whatever shape it bills it. It is the only line you cannot derive yourself, and the one most often quoted with none of the others attached. Treat a headline price as incomplete until you have asked which of the remaining lines it covers.

Network fees are the cheapest and most predictable part of the stack. The base fee is a protocol constant of 5,000 lamports per signature, charged whether the transaction succeeds or fails, and one SOL divides into a billion lamports across nine decimals. Count signatures rather than transactions, since a transaction carrying two signers costs twice as much as one.

Priority fees are set per transaction in micro-lamports per compute unit and multiplied by the compute unit limit requested, so what you pay depends on two variables you choose and one you do not, which is how hard everyone else is bidding for the same block. The mechanism belongs to the network rather than to any tool, as the Solana project documents.

Rent exemption is a deposit rather than a fee. The formula is (128 + data bytes) x 3,480 lamports per byte-year x 2 years, so an SPL token account holding 165 bytes needs 2,039,280 lamports and a bare system account needs 890,880. Each deposit returns to the destination you name on closure, and a token account can only close at a zero balance.

Capital parked in sub-wallets is the balance each wallet needs to take its side of a trip, plus a reserve for the transactions that unwind it. Spread and price impact then dominates everything else: each trip buys at one price and sells at a worse one, and the gap widens as order size grows against available depth. Only quoting both legs gives you that figure.

Failed attempts and the buffer close the stack. A failed transaction still consumes its base fee and any priority fee attached, and it still needs replacing, so budget attempts rather than landings: divide the landings you want by one minus the failure rate you assume. Then add headroom for congestion and for the closing sweep.

The budget worksheet

Copy the table into a spreadsheet and fill the final column with your own figures. It is arranged so the two totals stay apart: sum the rows marked spent for the cost of the run, and sum the rows marked parked for the balance that must exist before you start. They answer different questions and should never be merged.

Filling the sheet in is a procedure rather than a guess, and each step depends on a decision taken in the step above it. Work down in order instead of starting from a total you have already decided to part with. A run split across venues needs the rent and spread rows filled in once per venue, which matters when the tool in front of you is a multi-DEX Solana volume bot rather than a single-venue router.

1. Fix the shape first. Decide wallet count, round trips per wallet, order size per leg and the window the run occupies. Every other line derives from those four.
2. Count the signatures. Wallets times round trips times legs, plus the transfers that fund the fan-out and the sweeps that close it, all at 5,000 lamports each.
3. Set a priority ceiling. Choose the compute unit limit and the highest bid per unit you will authorise, run the formula, and multiply by attempts rather than landings.
4. Count the accounts. One token account per wallet per mint at 2,039,280 lamports, plus a system deposit for any wallet that does not exist on chain yet.
5. Price one round trip. Quote both legs at your intended size on the venue you will route to, record the cost as a percentage of notional, and multiply by round trips.
6. Split the totals and set a stop. Spent in one column, parked in the other, a buffer on the spent side, and a written figure at which the run halts.

An illustrative run costed end to end

Arithmetic below uses invented assumptions chosen for legibility rather than measurements from any run. Its purpose is to show the shape of the stack and the ratio between its parts, because that ratio is the part that generalises between runs. The first block covers the on-chain lines, the second what the book takes.

The ratio is the lesson. Under those assumptions the trading cost is more than seven hundred times the on-chain fee cost, while the balance you need available is roughly sixteen times what you actually spend. Report the two columns separately, and add the software charge on top, since no method here derives it for you.

Deriving your readability floor

A run is readable when the change it produces is larger than the variation the pair produces on its own across the same span of time. That is a comparison rather than a number, which is why the floor is derived per pair and cannot be published in advance. Activity inside the ordinary swing of a pair cannot be attributed to anyone.

Getting the swing figure means measuring before you fund anything. Pick a window length, record the traded notional of the pair across comparable windows, and take the spread between the highest and the lowest. Record times of day too, since a pair quiet overnight and busy at open has two different floors. Explorers such as Solscan expose per-transaction history you can aggregate yourself.

Clearing the floor does not mean the run achieved anything worth having. It means only that the change can be attributed to your activity rather than to whatever the pair was doing regardless. A run that clears the floor and produces nothing useful still answers a question, which is more than an unreadable run manages.

How the floor moves with depth and venue

Depth pushes the floor in two directions at once. A deeper pair has a larger natural swing, so the notional needed to stand out rises, while each unit of notional concedes less to price impact, so cost per unit falls. Thin pairs invert both: a small run is visible at once, but every leg pays more and the pattern is easier to identify.

Venue selection splits the problem rather than solving it. Each venue has its own book, its own depth and its own swing, so the floor belongs to a pair on a venue rather than to a run in the abstract. The same notional spread across three venues can leave all three below their floors, and a venue expecting a wrapped SOL account adds another deposit per wallet.

What an underfunded run produces

Underfunding rarely announces itself as a shortfall. It shows up as a run that stops in an odd place, wallets holding tokens they cannot sell, and failed attempts that consumed base fees without changing anything. That outcome is worse than not running, because part of every spent line has been paid and a partial fan-out is left to unwind by hand.

Three failure modes are worth naming. First is fee starvation, where wallets were funded for their trades but not for the signatures that close them out, stranding the rent deposit behind an account nobody can close. Second is the floor case, where the run completed as configured yet sits inside the ordinary variation of the pair. Third is the missing buffer, where congestion raised fees mid-run.

Three questions this page does not price

Budgeting is one decision among several, and three neighbouring ones have their own pages. Pricing structure decides whether the software charge behaves like a fixed line or like a multiplier on the notional in your worksheet, and the shapes are set out in the comparison of volume bot pricing models, which matters because a percentage of routed volume rises when your spread cost does.

Testing comes before committing a full budget, and the procedure for a first deliberately small paid run is written up in the controlled test protocol. Hosting is the third: running an engine yourself moves cost out of a subscription line and into your own infrastructure and time, which the self-hosted and managed comparison frames as a total cost. The rest sits in the buying guide.

A sizing checklist before you commit

Work through this list before any money moves. Every item is answerable from your own worksheet and your own measurements, and none of it requires trusting a figure taken from a marketing page. If any line is still blank at the end of it, the run is not sized, it is guessed.

• The shape of the run is written down: wallets, round trips, order size per leg, and the window it occupies.
• The spent column and the parked column are separate totals, and neither has been folded into the other.
• Attempts rather than landings were used for every fee calculation, with an explicit failure rate you chose.
• Each wallet is funded with a reserve that survives the closing transactions as well as the trading ones.
• The round-trip cost was quoted on the actual pair at the actual order size instead of assumed.
• The natural swing was measured over a defined window, and the run clears your chosen multiple of it.
• A separate floor was derived per venue if the run is split across more than one book.
• A stop condition names the spent figure at which the run halts, and someone is watching for it.

Sizing is the last step before funding and the easiest one to shortcut. The worksheet exists so the shortcut becomes visible: a blank cell is a decision you have not made, and leaving it blank hands that decision to whatever the run does next. Fill the sheet and keep the totals apart.

Frequently asked questions