The six lines are infrastructure, RPC and data, network fees and tips, platform or protocol fees, slippage and price impact, and failed transactions plus account rent. The first four are visible and easy to budget. The fifth is usually larger than all of the others combined and is charged silently inside the execution price, which is precisely why it goes unmanaged.
The six cost lines
Every automated strategy on Solana pays into the same six buckets, whether it is self-hosted or bought as a service. Naming them separately matters because they scale on completely different variables: some scale with time, some with transaction count, and one scales with notional volume, which is what makes it dominant.
| Line | Scales with | Visible? | Typical control lever |
|---|---|---|---|
| Infrastructure | Time | Yes, billed monthly | Right-sizing the host and region |
| RPC and data | Request volume and streams | Yes, until overage | Caching, batching, subscriptions instead of polling |
| Network fees and tips | Transaction count | On chain, if you look | Compute limit sizing and a written fee policy |
| Platform or protocol fee | Notional or per action | Depends entirely on the vendor | Vendor selection and understanding the basis |
| Slippage and price impact | Notional relative to pool depth | No, unless you measure it | Position sizing, order splitting, venue choice |
| Failures and rent | Transaction count and mints touched | Partially | Landing rate, tolerance settings, closing token accounts |
Line by line
Infrastructure
A modest virtual server in a region near your endpoint is sufficient for most strategies, and this line is usually the smallest one on the list. It grows when operators reach for a dedicated node or a colocated machine, which is a step change rather than an increment and should be justified by a measurement rather than by ambition. The real infrastructure question is not size but whether the machine is dedicated to the bot, which is a security requirement as much as a performance one.
RPC and data
This is the line that surprises people, because the pricing unit is rarely a plain request. Providers meter in credits, weight expensive methods more heavily, and cap concurrent subscriptions separately. A strategy watching many markets can breach a plan on subscription slots while using a fraction of its request allowance. The reductions available are real and mostly free: cache immutable data, batch status queries, and prefer subscriptions to polling loops. The RPC page covers how to size this properly before signing.
Network fees and tips
Base fee per signature plus the priority fee you choose, plus tips where bundles are used. Individually tiny and collectively meaningful only at high transaction counts. The single largest avoidable error here is declaring a compute unit limit far above actual consumption, since the priority fee is charged against the limit you request. The arithmetic is worked through in priority fees and Jito bundles.
Platform or protocol fee
If you buy rather than build, this line replaces most of the first two and adds a variable component. What matters is the basis, not the rate. A SOL volume bot charging a percentage of notional and one charging a percentage of profit are not comparable at any activity level, and only the first can be estimated before the run begins. A percentage of notional volume, a percentage of profit, a flat fee per action and a spread taken inside the execution price behave completely differently as activity scales, and the last one is the hardest to audit because it cannot be separated from slippage without a reference price.
Slippage and price impact
The difference between the price you were quoted and the price you received. It scales with your size relative to pool depth, and it is a real transfer of value rather than an accounting artefact. Nothing else on this list responds so strongly to a decision that costs nothing to make, namely trading smaller relative to depth or splitting an order across time. Measure it per trade by parsing the confirmed transaction rather than trusting the quote.
Failures and rent
Two different things, grouped because both are invisible in most reporting. Transactions that land and fail pay fees and produce nothing. Transactions that never land pay nothing at all, so they cost only opportunity, but they distort every other metric if uncounted. Separately, holding a token requires a rent-exempt account per mint, currently on the order of 0.002 SOL locked. That is recoverable when the account is closed, and it accumulates permanently in operations that never close them.
An illustrative worked total
Every input below is an assumption chosen to make the structure of the arithmetic visible. They are not benchmarks, not typical values, and not claims about any product. Substitute your own figures; the ordering of the lines is the finding, not the totals.
Assumed scenario. A market-activity configuration submits 300 transactions per day. Landing rate is 85 per cent, so 255 land. Of those, 8 per cent fail on chain, leaving roughly 235 successful trades. Average notional per successful trade is 0.5 SOL, giving 117.5 SOL of daily traded notional. Average realised slippage is 0.7 per cent. Priority fees average 0.00004 SOL per landed transaction, and 20 per cent of landed transactions carry a tip averaging 0.0004 SOL.
| Line | Calculation | Daily cost in SOL | Share of on-chain total |
|---|---|---|---|
| Base fees | 255 landed × 0.000005 | 0.001275 | 0.1% |
| Priority fees | 255 landed × 0.00004 | 0.0102 | 1.2% |
| Tips | 51 tipped × 0.0004 | 0.0204 | 2.4% |
| Slippage | 117.5 notional × 0.7% | 0.8225 | 96.3% |
| On-chain total | Sum of the above | 0.854475 | 100% |
Two costs sit outside that table on purpose. Infrastructure and RPC are billed in fiat, and converting them into SOL requires a price assumption that would make the arithmetic depend on the market rather than on the strategy. Keep them in their own currency and add them at the end. A platform fee, if you are buying rather than building, is a further line: at a stated one per cent of notional it would add 1.175 SOL per day under these assumptions, which is larger than every on-chain cost combined and is exactly why the basis of a fee model matters more than its headline rate.
Also note what the failures cost. The roughly 20 transactions that landed and failed paid base and priority fees for nothing, which is around 0.0009 SOL: negligible. The 45 that never landed cost nothing in fees at all. The instinct to optimise failure rates for cost reasons is misplaced; the reason to fix them is missed trades, not the fee bill.
Cost per successful trade
Divide the on-chain total by successful trades: 0.854475 divided by 235 gives approximately 0.0036 SOL per successful trade. Against an average notional of 0.5 SOL, that is around 0.73 per cent of traded value, and 96 per cent of it is slippage.
This single metric is the most useful thing on the page, for three reasons. It is comparable across configurations, unlike totals that move with activity. It exposes the dominant line immediately, which redirects effort towards the thing that matters. And it gives you a hurdle: a strategy whose expected edge per trade is smaller than its cost per successful trade is not a strategy, regardless of how good the individual trades look.
The uncomfortable implication for most operators is that a week spent tuning fee policy would move the total by roughly one per cent, while a decision to halve position size relative to pool depth could move it by far more. Cost optimisation in this field is almost entirely a sizing and venue-selection problem wearing an infrastructure costume.
Build versus buy
Once the lines are separated, the build-versus-buy question becomes concrete: buying replaces engineering time and infrastructure with a variable fee and a custody dependency.
| Dimension | Self-hosted | Managed platform |
|---|---|---|
| Time to first run | Weeks, assuming you can already write the code | Same day |
| Upfront cost | Engineering time, which is the real number people omit | Effectively zero |
| Marginal cost per run | Network fees only | Network fees plus the platform fee |
| Fixed monthly cost | Host plus RPC plan, paid whether you trade or not | Usually none, or a small subscription |
| Custody | You hold the keys and the responsibility | Depends on the model; the first thing to verify |
| Control | Total, including the freedom to be wrong in novel ways | Bounded by exposed parameters |
| Failure ownership | Yours, at any hour | Shared, subject to how the vendor actually behaves |
| Where to look | Open-source SDKs and your own repository | A published Solana volume bot platform, assessed against the nine criteria |
The honest decision rule is about volume and skill rather than principle. A percentage fee is cheap at low activity and expensive at high activity, so there is a crossover point where building starts to pay, and you can compute yours from the table above once you know your monthly notional. Below that point, building is usually a way of spending expensive time to save inexpensive fees. Above it, the fee line starts to dominate the very cost stack you were trying to control.
Two adjustments to that rule. First, engineering time is not free even when it is your own, and a bot is not a project that ends: it needs maintenance every time a venue changes a program. Second, buying moves custody and execution transparency into the vendor's hands, which is why the fee comparison should never be made in isolation from the nine-criteria evaluation. A cheaper fee on an opaque platform is not cheaper; it is unpriced.
The buy-side link above points at one example of the managed class so the comparison has something concrete in it. Treat it as a specimen to run the criteria against, not as a recommendation: the point of the table is the method for pricing your own situation.
Computing your own crossover
The crossover is where the variable platform fee equals the fixed cost of running the same thing yourself. Continuing the illustrative scenario above, a platform fee of one per cent on 117.5 SOL of daily notional is 1.175 SOL per day. If the self-hosted equivalent costs a fixed monthly sum for a host and an RPC plan, the comparison is simply that monthly figure against roughly 35 SOL of fees per month at the same activity, plus the engineering time to build and maintain the system.
Run that comparison at your own activity level, and run it twice: once at the volume you are trading now, and once at the volume you expect if things go well. The two answers frequently differ, and the useful conclusion is usually not build or buy but buy now and revisit at a stated threshold. Writing that threshold down converts a recurring argument into a trigger.
The costs that never reach the spreadsheet
- Your time. Monitoring, debugging and re-tuning are recurring, not one-off. Priced at anything above zero, this is frequently the largest line in the entire stack for a self-hosted operation.
- On-call. Markets do not respect time zones. A strategy requiring intervention at unpredictable hours has a real cost that shows up in your life rather than your ledger.
- Rent accumulation. Token accounts left open across hundreds of mints immobilise capital indefinitely. Closing them is a five-minute periodic job that nobody schedules.
- Provider overage. Credit-based plans bill for the burst, and the burst happens during exactly the events you built the system for.
- Opportunity cost of segmentation. Wallet tiering, which is the correct security posture, immobilises capital in fee headroom and rent across every wallet. That is a real price for a real benefit.
- Learning cost. The first month of any new configuration is tuition. Budget it explicitly rather than treating it as an unexpected loss.
A budgeting procedure
- Estimate transaction count per day from your intended activity, not from a best case. This drives three of the six lines.
- Estimate notional per trade and total daily notional. This drives the two lines that dominate: slippage and any percentage platform fee.
- Measure realised slippage on a small sample before scaling. Do not use a quoted figure; parse the confirmed transactions.
- Price the fixed lines in fiat and keep them separate from the on-chain lines rather than converting through a volatile rate.
- Compute cost per successful trade and compare it against your expected edge per trade. If the second is not comfortably larger, stop here.
- Re-run the calculation monthly with measured inputs replacing assumptions, and keep the old versions so the drift is visible.
The discipline that makes this work is refusing to mix measured values with assumed ones in the same table without marking which is which. Most cost models in this field fail not because the arithmetic is wrong but because an assumption made once, early, quietly acquires the authority of a measurement and is never revisited.