Reading a run report line by line
The report is the only part of a panel that tells you what happened rather than what was planned. It is also the part nobody explains, which is how people end up comparing a number on a dashboard with a number on an explorer and assuming one of them is lying.
In one line
A run report has three parts: header totals, a per-transaction log with a status on every line, and a cost breakdown; the status column is the part worth reading first.
The short answer
A run report has three parts. A header with totals, a per-transaction log where every line carries a status, and a cost breakdown. Read the status column first, because it tells you what fraction of the run actually happened. Then read the cost breakdown, because it tells you what the run charged you for the parts that did not. The header totals are the least informative section and the one everybody looks at.
Everything a report claims can be checked on a block explorer using the transaction signatures in the log. That check takes a couple of minutes and is the difference between believing a dashboard and knowing what it did.
The three parts of a report
Panels lay these out differently, but the content sorts into the same three groups, and knowing which group you are reading prevents most misinterpretation.
| Section | Typical contents | What it is good for |
|---|---|---|
| header | Total swaps, total notional, duration, stop reason | A one-glance summary and the reason the run ended |
| transaction log | Timestamp, wallet, side, amount, status, signature | Everything that actually happened, and what did not |
| cost breakdown | Network fees, priority fees, venue fees, slippage, rent | Where the money went, and which line dominated |
If a report offers only the header, it is not a report; it is a scoreboard. The log is the part that can be verified, and a tool that does not expose transaction signatures has made itself unauditable. That is a reasonable thing to check before a run rather than after.
The header totals
Four numbers usually sit at the top, and three of them are ambiguous unless the report says otherwise.
Total swaps. Attempts or successes? These differ by the failure rate, which on a busy network is not a rounding error. If the panel shows one number, assume it is attempts and look for a landed count in the log.
Total volume. Buys plus sells, or one side only? A round trip of a 0.05 SOL buy and a 0.05 SOL sell is 0.1 SOL of turnover by the usual market convention, and 0.05 SOL if the panel is counting one direction. Both conventions exist.
Duration. Wall clock from start to stop, including any period where the panel was retrying rather than trading. A run that shows two hours may have traded for forty minutes and struggled for the rest.
Stop reason. The only unambiguous number in the header, and the most useful. Cap reached, duration elapsed, manual stop, or insufficient funds. That last one is a problem to fix rather than a stop to accept.
Every status in the log
The status column is the substance of a report. Names differ between tools but the underlying conditions are a short list, and each one implies a different fix.
| Status | What happened | Cost | What to change |
|---|---|---|---|
| landed | The transaction confirmed and the swap executed | Full fees plus venue costs | Nothing |
| slippage exceeded | Price moved past the tolerance and the swap cancelled itself | Fees, no swap | Widen tolerance slightly, or reduce size |
| blockhash expired | The transaction was not included before its reference block aged out | Usually nothing | Better endpoint, or slower pacing |
| insufficient funds | The wallet lacked SOL for the trade or the fee | Nothing | Fund workers properly; check the sweep did not run early |
| account not found | A required token account did not exist yet | Fees for the failed attempt | Let the panel create accounts before trading starts |
| simulation failed | The transaction would have failed and was not sent | Nothing | Usually a venue or routing problem |
| retried | The same intent was rebuilt and resent | Fees for every attempt | Watch the ratio; high retries means an execution problem |
| cancelled | The run stopped before this line was sent | Nothing | Nothing; expected after a stop |
Two of those rows are commonly misread. Blockhash expiry is not an error in your configuration: a transaction on Solana references a recent block and is only valid for a limited window, so an attempt that waits too long simply stops being valid. The mechanism is described in the Solana transactions documentation. And slippage cancellations are the tolerance doing its job, which is what you wanted when you set it, however irritating it looks in a list.
Attempted against landed
This is the single most useful ratio in the report and the one most likely to be missing from the header. Work it out yourself from the log.
Take an illustrative run: 300 attempts, of which 246 landed, 31 failed on slippage, 18 expired and 5 were cancelled at the stop. The landing rate is 246 divided by 300, which is 82 per cent. The turnover the panel reports depends entirely on which number it used: at 0.05 SOL per swap, attempts imply 15 SOL and landed swaps imply 12.3 SOL. Only the second one exists on chain.
| Outcome | Count | Notional | Fees paid |
|---|---|---|---|
| landed | 246 | 12.30 SOL | Full |
| slippage exceeded | 31 | None | Signature and priority fees |
| expired | 18 | None | Usually none |
| cancelled at stop | 5 | None | None |
The second column is what happened. The third column is what a volume figure would report. The fourth is what you paid for the difference. A report that only shows the first row is technically accurate and practically misleading, and a report that shows all four is one you can plan a second run from.
A landing rate in the low eighties is unremarkable on a busy network. A landing rate in the thirties means something is wrong that more attempts will not fix, and the status distribution says which: mostly slippage means the tolerance is too tight for the venue, mostly expiry means the transactions are not reaching a block in time.
The cost breakdown
The cost section should account for every SOL that left the funding wallet. Read it against your own estimate from before the run, line by line, because the line that differs is the assumption to fix next time.
- Network fees. Signature fees at the protocol rate. This line should be small and boring. If it is large, the run made far more attempts than you thought.
- Priority fees. The variable part of getting included. This is the line that moves with network conditions and the one most likely to exceed an estimate.
- Venue fees. A percentage of the notional that landed. Check it against the venue's published rate: if it does not match, the run probably routed somewhere other than where you thought.
- Slippage. The gap between quoted and executed prices, aggregated. This is usually the largest controllable line and the one that punishes an oversized swap setting.
- Rent deposits. SOL locked in token accounts. Not spent, but not yours to use until the accounts are closed. Check whether the report shows it as returned.
- Unswept remainder. Whatever is still sitting in worker wallets. This is the line people forget, and across many wallets it adds up.
The comparison that matters is simpler than any of those lines: what the funding wallet held before, minus what it holds after, minus anything still in worker wallets. That difference is the true cost of the run, and it is the only figure worth carrying between runs because it cannot be defined away.
Checking the report on chain
Five minutes of work, and it settles every argument about whether a panel is honest. Do it once after a first run and you will know how much attention future reports need.
-
Take three signatures from the log
One landed, one failed, one from the middle of the run. Copy them exactly; a transaction signature is long and truncation is easy.
-
Open each on an explorer
Paste them into a block explorer such as Solscan. You are checking that the transaction exists, that its status matches the log, and that the fee shown matches what the report claims.
-
Confirm the swap contents
The transaction detail shows which programs were called and which token balances changed. Confirm the mint is the token you configured and the amount matches the swap size on that line.
-
Open one worker wallet
Look up the address on the explorer and read its transaction history. The count and rhythm of transactions there should match what the per-wallet section of the report says.
-
Compare the funding wallet balance
Before and after, adjusted for anything still sitting in workers. If the difference matches the report's total cost, the whole document is trustworthy. If it does not, the gap is the number to ask about.
None of that requires a tool, an account or a purchase, and it works on any panel from any vendor. It is the reason a tool that hides transaction signatures should be treated as a tool that cannot be checked.
Why an aggregator disagrees
You reconcile the report against the chain, the numbers match, and then a third-party site shows a completely different volume figure for the token. Nothing is broken. The two are counting different things.
No official volume number exists on Solana. Every figure you see is a service reading transactions out of blocks and deciding which of them count as swaps of that token, which pools to include, how to price SOL at the moment of the trade, and whether to count both legs. Two services applying different decisions produce different totals from identical data, and some of them explicitly discount activity that looks self-generated.
The practical consequence for reading a report: your panel's totals describe your run, and an aggregator's totals describe what that aggregator chose to count. Comparing them tells you about the aggregator's methodology, not about the accuracy of your report. This is also why no honest tool can promise how a run will appear on any particular site.
The per-wallet view
Better reports break the run down by worker. This view answers questions the aggregate cannot, and it is where genuine faults become visible.
Look for wallets with a landing rate far below the rest, which usually means they ran short of fee money and started failing. Look for wallets that stopped early while others continued, which suggests distribution did not complete. Look for wallets holding token balances at the end, because those are the ones with unsold positions and open token accounts. And look at the spread of activity: if two wallets did most of the work, the wallet count you paid for did not deliver what it was supposed to.
This view is also the cleanup checklist. Every wallet listed with a remainder is a sweep you have not done, and every wallet with an open token account is a rent deposit you have not recovered. Working through the list once after a first run is how the true cost of a wallet count stops being theoretical.
What a report cannot tell you
Four things, and no amount of detail in the log changes any of them.
It cannot tell you whether anybody noticed. A report describes transactions, and attention is decided by other people's software and other people's attention, neither of which is measurable from your own logs.
It cannot attribute anything that happened afterwards. If other trading appeared during or after a run, nothing in the report establishes a connection, and the temptation to read one is where the most confident wrong conclusions in this subject come from.
It cannot tell you whether the activity survived any filter. Ranking systems apply their own rules and do not publish them. A landed transaction is a fact; a counted transaction is a decision made elsewhere.
It cannot tell you whether the run was worth doing. That is a judgement about what the spend bought, made after the fact, with an honest view of what the money achieved. A report gives you the cost side of that comparison and nothing else. Reading it properly is still the whole point, because a cost you can measure is the only part of automated volume management that is fully within your control.
The post-run review
Twenty minutes, once, after a first run. It converts a single run into information you can use for the next one.
- Write down the landing rate. Landed divided by attempts, and the dominant failure status.
- Compare estimated cost against actual. Line by line, and note which assumption was furthest out.
- Check the stop reason. Cap, duration or funds. Only the first two are stopping conditions.
- Verify three transactions on chain. One landed, one failed, one arbitrary.
- Sweep and close. Return remainders, close token accounts, note what could not be recovered.
- Record the true cost. Funding wallet before, minus after, minus what is still stranded.
Where this leaves you
You can now read a report as a document rather than as a scoreboard: which fraction of the plan happened, what the failures cost, where the money went, and whether the panel's account of itself survives a check against the chain. That is the whole skill, and it does not depend on which tool produced the report.
If this was your first run, the most valuable next step is not another run. It is going back to the field guides with your actual numbers in hand: the landing rate tells you whether the slippage tolerance was right, the cost breakdown tells you whether the swap size suited the venue, and the stop reason tells you whether the cap was doing anything at all.
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.