Closing a Run and Reconciling What Actually Happened

End of run reconciliation means making four records agree: what you planned, what the run attempted, what the chain confirmed, and what your balances say. Closing a run is the ordered sequence that gets you there, and it begins after the last in-flight transaction settles rather than at the moment you press stop. Everything read before settlement is provisional.

This is the phase operators skip. Attention drops sharply the instant the sending stops, which is precisely when balances are still moving, accounts are still open, and the record you will need in a week is still assemblable. An hour spent here is worth more than the same hour spent watching the middle of the run.

Stopping is not closing

A stop is a statement about future work: nothing new will be submitted. It says nothing about work already submitted, which continues to resolve on its own schedule, and it says nothing about the state left behind, which persists until you deal with it deliberately.

Three things remain live after a stop. Transactions in flight, which will succeed or fail without further input from you. Accounts holding balances, including dust that is too small to notice and large enough to matter across a fleet. And the record itself, which is complete at this moment and starts degrading immediately as caches expire, sessions end and memory fades.

Treating stop as the end produces a specific, recurring outcome: numbers that almost reconcile. The gap is usually small, always unexplained, and reliably grows across runs because each unexplained gap becomes the starting point for the next reconciliation. Closing properly the first time is cheaper than closing properly the fifth time with four unexplained gaps behind you.

The quiesce sequence

Quiescing means bringing the run to a state where nothing is changing, so that everything you read is stable. Do it in order, and resist the urge to start reading balances before the sending has definitely stopped.

1. Stop new work, then confirm it stopped from outside. Note the newest transaction signature at the moment you press stop, then check whether anything newer appears. The interface reporting a stop is a claim about the interface.
2. Wait out the in-flight window. Submitted transactions need time to reach a final state. Reading balances during this window produces numbers that will change under you, and reconciling against them wastes the whole exercise.
3. Snapshot every balance at one point in time. Every participating wallet, the reserve, and any account holding token balances. A snapshot taken across twenty minutes is not a snapshot.
4. Freeze the record. Export or copy the run history, the logs and the journal before anything expires. Retention policies you never chose are a common way to lose the evidence.
5. Only then start reconciling. Reconciliation against a moving system is guesswork, and the temptation to start early is strongest exactly when the run ended badly.

Confirmation semantics matter here more than anywhere else in the live window, because the whole sequence depends on knowing when a transaction is genuinely final rather than merely accepted. The commitment levels and their guarantees are set out in the Solana documentation, and reading a specific signature to its final state is straightforward on Solana Explorer if you do not have your own tooling for it.

The four ledgers

Reconciliation compares four accounts of the same run, each produced by a different party, each with a different failure mode. They will not match exactly, and the point is not to force them to; it is to be able to explain every difference.

The order matters. Planned against attempted tells you whether the software did what you asked. Attempted against landed tells you whether the network accepted it. Landed against settled tells you whether you understand your own costs. Each comparison isolates one category of problem, and doing them out of order mixes the categories back together.

What each gap between ledgers means

Every gap has a small set of plausible explanations. Working through them explicitly turns reconciliation from an accounting chore into the most informative half hour of the whole exercise.

• Planned above attempted. The run did less than you asked. Causes: it stopped early, it was throttled, a queue never drained, or the plan was never fully loaded. Check the journal for a stop or an adjustment first.
• Attempted above landed. Submissions did not become confirmed transactions. This is the failed transaction rate, measured after the fact and therefore trustworthy. Group the failures by error class before drawing any conclusion.
• Landed above what you expected to land. Retries that succeeded twice, duplicated work, or a plan that was ambiguous about what counted as one action. Duplicates are worth chasing; they usually indicate a retry design problem that will recur.
• Landed and settled disagree. Costs you did not itemise: transaction fees, priority costs, account rent, or value left in accounts you have not swept. This gap is almost always cost accounting rather than a missing transaction.
• Settled is lower than every explanation covers. Stop and investigate rather than rounding. An unexplained shortfall is the one result that should not be written off, and the record is at its most complete right now.

Costs that only appear at the end

Three categories of cost are invisible during the run and unmistakable at reconciliation, which is why runs so often feel cheaper while they are happening than they turn out to have been.

Per-transaction cost across a fleet. Any individual fee is negligible; the total across many wallets and many actions is not. Illustrative arithmetic with invented inputs: if a run performs N actions and each action costs you c in total network cost, the run costs N times c before anything else, and both N and c are quantities you can read after the fact rather than estimate. Doing that multiplication once, from real post-run numbers, is usually more educational than any live reading.

Locked account balances. On Solana, accounts must hold a minimum balance to remain resident, and token accounts are accounts. Across a fleet this is capital that is committed rather than spent, and it is recoverable only if you close the accounts. The mechanics are documented in the Solana program documentation, which is worth reading once so that you know which of your locked lamports come back and which do not.

Dust. Small residual balances spread across many accounts, each too small to bother with individually, collectively worth attention. Dust is not a loss until you decide it is not worth sweeping, at which point it becomes one. Decide that consciously, and write the decision in the run report so that the next reconciliation does not rediscover it as a discrepancy.

Sweeping and closing accounts

Sweeping returns balances to the reserve. Closing accounts releases the balances they were required to hold. Both are irreversible in the sense that matters: a transfer cannot be recalled, and a closed account's state is gone.

Do both after reconciliation, never before. Reconciliation compares closing balances against opening balances, and a sweep performed first destroys the closing balance you needed to read. The temptation to tidy up immediately is strong, particularly after a run that ended badly, and it costs you the ability to explain what happened.

Order within the close-out matters too. Sweep from working wallets back to the reserve first, then close the accounts that no longer need to exist, then take a final balance reading. Closing an account with a balance still in it, or sweeping after closing, are both ways to lose value quietly, and neither produces an error message.

The run report

The report is the artefact that makes the next run better. It should take fifteen minutes, fit on one page, and contain nothing that requires interpretation to read a month later.

The field names above are a template, not data. The "changes" line is the one that justifies the whole exercise: a report that ends without a change to a threshold, a cadence or a rule has told you the run was well calibrated, which is itself a finding worth recording explicitly rather than leaving implicit.

If the run was executed on a hosted Solana volume bot platform, export its record rather than relying on it remaining available, and keep your own copy alongside the journal. A record you do not control can change format, expire, or become inaccessible when an account lapses, and none of those events announce themselves.

Feeding the numbers back into thresholds

Post-run measurement is the only honest source for the thresholds you will use next time. Live readings are fast and approximate; the reconciled numbers are complete. Setting a threshold from a live reading is setting it from the least reliable version of the quantity.

Three thresholds usually deserve revision after every run. The failure share, which you can now compute properly from attempted against landed. The wallet floor, which the closing balances tell you was either too generous or too tight. And the elapsed-time ceiling, which the actual duration will either validate or quietly embarrass.

Revise deliberately and record the revision with its reason. A threshold that drifts across runs without an explicit decision is not being calibrated; it is being negotiated downward by whichever run most recently made it inconvenient. The override log from the run is the best input here, because a condition overridden twice is a condition asking to be rewritten.

What to archive, and for how long

Archive four things: the plan, the journal, the reconciled ledgers with the run report, and the raw record from whatever executed the run. Store them together, named by date and run identifier, somewhere that is not the machine that did the work.

Retention is a judgement, but the asymmetry is clear. The cost of keeping a one-page report and a log file is trivial. The cost of not having them when a question surfaces months later is that you cannot answer it at all, and the questions that surface late are disproportionately the ones that matter.

One rule is not a judgement: nothing in an archive should contain a private key, a seed phrase or an endpoint credential. Check before you file, not after, because an archive is by design the thing you copy, sync and forget about.

Restarting safely after a stop

A run that stopped and a run that resumes are two runs, and treating the second as a continuation of the first is how state gets lost. The plan for the second run has to be written from the state you are actually in, which is not the state the first plan assumed.

Before restarting, answer four questions. Has the condition that stopped the first run actually been resolved, or has it merely stopped being visible? What state does the previous run leave behind, including partially completed sequences and unswept balances? Are the wallets still above the floors the new plan requires, or does the fleet need refunding first? And is the plan you are about to run the old plan with a fresh start, or a plan written for the situation you are now in?

If the honest answer to the first question is that you are not sure, the restart is a second attempt at the same failure. The discipline that makes stop conditions worth writing is the same discipline that makes restarts deliberate: the rule fired for a reason, and resuming without addressing the reason converts a controlled stop into a delay.

The close-out checklist

• New work has stopped, and I confirmed that from outside the tool that reported it.
• The in-flight window has passed and no transaction from this run is still unresolved.
• Closing balances for every wallet and the reserve are recorded at a single point in time.
• Planned, attempted, landed and settled are written down, and every gap has an explanation.
• Network costs are totalled from the record rather than estimated.
• Locked account balances and dust are identified, with a decision recorded for each.
• Sweeping and account closure happened after reconciliation, not before.
• The run report exists, including the line about which thresholds change.
• The archive contains the plan, the journal, the ledgers and the raw record, and no secrets.
• If a restart is planned, the condition that ended the previous run has actually been addressed.

Finishing this list is what converts an hour of watching into something cumulative. The run produced whatever it produced, and that part is done. What you carry forward is a calibrated set of thresholds, a cadence you have tested against reality, and a record that will still make sense to you when the details have gone.