If you're running a Solana trading bot and the P&L doesn't look right, the answer is almost always cost attribution. Most operators know roughly what their gross profit is. They have a vague sense of fees. The detailed breakdown of where money is actually going — between fees, tips, sandwich tax, slippage, failed-transaction costs, and infrastructure — is usually missing.
This piece covers how to attribute Solana trading costs accurately, why most bots over- or under-estimate specific categories, and the patterns that turn fuzzy P&L into clean attribution.
The Categories of Cost
For a Solana trading bot, the cost categories you need to track:
Base fees. Solana's flat per-signature fee. Tiny but present.
Priority fees. Per-CU charge that signals priority to validators. Can be substantial.
Bundle tips. Optional MEV protection / bundle inclusion fees. Vary widely.
AMM swap fees. What the DEX/pool charges for the swap itself. Programmatic.
Sandwich tax. Difference between AMM-math expected output and actual fill. Hidden cost.
Slippage cost. Difference between intended price and execution price (excluding sandwich).
Failed transaction costs. CU consumed × CU price for transactions that failed.
Infrastructure costs. Your RPC provider, your servers, anything you pay outside of on-chain transactions.
Opportunity cost. Capital tied up in inventory or rejected opportunities. Hardest to measure.
Most bots track 2-3 of these clearly and have fuzzy sense of the rest. Production-grade operations track all of them.
Attribution Per Trade
For each completed trade, you should be able to compute:
Gross profit = Sale price - Buy price (in some quote unit)
Costs:
+ Buy fees (base + priority + bundle tip)
+ Sell fees (base + priority + bundle tip)
+ Buy AMM fee
+ Sell AMM fee
+ Buy sandwich tax (expected output - actual output)
+ Sell sandwich tax
+ Buy slippage (intended price - execution price)
+ Sell slippage
Net profit = Gross - Total costs
Computing each requires the per-signature telemetry covered in the monitoring piece.
How to Compute Sandwich Tax Accurately
The most-missed category is sandwich tax. To compute it:
-
Compute the AMM-math expected output at submission time, given pool reserves and your input amount. This is what the AMM curve says you should get with your slippage tolerance.
-
Compare to actual output from the transaction.
-
Sandwich tax = expected output - actual output.
For multi-hop swaps, compute expected output for each hop, sum the discrepancies.
If your bot doesn't compute expected output at submission time, you can't measure this. Add it to your telemetry.
How to Compute Slippage (Non-Sandwich)
Slippage that isn't sandwich attack is genuine market movement during your transaction:
-
Capture intended price at submission time. (Requires snapshot of pool state.)
-
Capture execution price from the actual transaction.
-
Slippage = intended - executed price.
-
Sandwich tax is a subset of slippage; non-sandwich slippage is the rest.
Some bots conflate these; the difference matters because sandwich tax is preventable (Anti-MEV) and natural slippage isn't.
Failed Transaction Costs
A failed transaction still costs:
- Base fee (5000 lamports)
- Priority fee × consumed CU (not always the full budget)
- bundle tip if used (behaviour on failures varies by provider)
Track per-failed-transaction costs. If your failure rate is 10% and average failed-tx cost is comparable to successful tx cost, your effective per-attempt cost is much higher than nominal.
Infrastructure Costs
Per-month, divided across your transaction count:
- RPC provider fees (free tier is free; paid tiers cost real money)
- Server costs (cloud VMs, networking)
- Software licenses
- Other infrastructure (databases, monitoring, etc.)
A bot doing 30,000 transactions/month with $300/month infrastructure has $0.01/transaction infrastructure cost. Small per-transaction, real in aggregate.
What Production Cost Attribution Looks Like
A reasonable monthly summary for a trading bot:
Total transactions submitted: 30,000
Total transactions landed: 24,000 (80% landing rate)
Gross profit on landed: 500.00 SOL
Costs:
Base fees: 0.15 SOL
Priority fees: 3.50 SOL
Bundle tips: 8.20 SOL
AMM swap fees: 12.50 SOL
Sandwich tax (estimated): 2.10 SOL (with Anti-MEV)
Other slippage: 1.80 SOL
Failed transaction costs: 1.40 SOL
Infrastructure: 0.30 SOL ($300 in SOL terms)
──────────────────────────────
Total costs: 29.95 SOL
Net profit: 470.05 SOL
Each row is computed from per-signature telemetry plus monthly aggregations. Without the telemetry, you can't compute this accurately.
Why Attribution Matters
Specific decisions you can make with good attribution:
Tip strategy tuning. If priority fees are 10% of costs but landing rate is only 80%, the tip strategy is off. If they're 2% and landing rate is 90%, you're under-tipping.
RPC choice. If sandwich tax is 5% of costs, you're not on an Anti-MEV RPC. Switching addresses this.
Strategy adjustment. If specific token types have systematically higher sandwich tax, avoid them.
CU budget tuning. If failed-transaction costs are non-trivial, your CU budget might be wrong.
Overall efficiency. Cost as percentage of gross tells you whether the strategy is operationally efficient.
Without attribution, you tune blind.
Common Attribution Mistakes
Conflating sandwich tax with slippage. Different categories with different fixes.
Ignoring failed transaction costs. They feel free; they're not.
Not amortising infrastructure. Per-month divided by transactions; this is a real cost.
Tracking only successful trades. Failed attempts are part of the cost structure.
Using nominal fees instead of effective. A "1% fee" might be effectively 1.5% after sandwich and slippage.
Not comparing to alternative paths. Without comparison data, you don't know if you're efficient.
What to Do This Week
If you want to clean up your cost attribution:
- Build per-signature telemetry that captures expected vs actual output. Without this, you can't measure sandwich tax.
- Categorise costs by type. Don't just track total fees.
- Track failed transactions separately. They're a meaningful cost category.
- Compute monthly summary by category. See where the money goes.
- Compare to baseline. What does cost-as-percent-of-gross look like? How does it change over time?
- Attribute changes in P&L. When monthly P&L moves, which category drove it?
What BoltTx Helps With
For trading bot cost attribution:
- Native Anti-MEV routing reduces sandwich tax to near-zero
- Sub-second confirmation reduces non-sandwich slippage from price drift
- Tip-based pricing — you pay only on transactions that reach the chain, which simplifies attribution
- Per-signature delivery telemetry — exactly what you paid for each landed transaction
- SWQoS-aware delivery — better landing rate means fewer failed-transaction costs
import { Connection } from "@solana/web3.js";
const connection = new Connection(
"https://bolttx.io/?api-key=YOUR_API_KEY",
"processed"
);
Free tier signup. For trading bots, the cost reduction usually shows up in attribution within the first week.
FAQ
Is sandwich tax really significant? For directional bots without protection, yes — often 5-30 bps per swap. Compounds across thousands of trades.
How do I track sandwich tax if I don't have AMM-math expected outputs? Build the calculation. Pool reserves at submission + your input amount = expected output. Compare to actual.
Should I include opportunity cost? Hard to measure but real. Capital allocated to slow strategies has opportunity cost vs faster ones.
What about MEV that benefits me? Some MEV strategies (back-running your own opportunity) can be positive. Most "MEV exposure" for bots is negative (sandwich).
Is there a benchmark for "good" cost attribution? For arbitrage bots, total costs <30% of gross is reasonable. For market makers, <50%. For sniper bots, costs vary widely with strategy.