After an incident: reconcile, reconstruct, then change one thing

When conditions clear you have something you did not have during the session: complete information. The transactions have resolved, the chain has settled, and any official account is either published or on its way. The temptation is to spend that moment arguing about what happened. The productive use of it is reconciliation, a written timeline, and exactly one change.

The order below is not arbitrary. Each step depends on the one before it, and skipping the first is how people end up trading from a position they have not verified.

Why the order matters

Reconcile, reconstruct, read, change. Reconciliation comes first because everything else is analysis and analysis can wait, while an unverified position cannot. Reconstruction comes before reading because your memory of the session degrades quickly and an official narrative will overwrite it if you read one first.

That last point is worth dwelling on. Once you have read somebody else's account of an event, your recollection reorganises itself around it. Details that fit are remembered clearly, details that do not are quietly dropped, and the timeline you produce afterwards is a paraphrase rather than evidence. Write yours down before you read anyone else's.

The change comes last because it is the only step you cannot undo cheaply. A setting altered in the first ten minutes, while adrenaline is still present, is a setting you will find a year from now with no idea why it is there.

Reconcile state before anything else

Read your balances and positions from the chain, not from a cached interface, not from your own database, and not from what you believe you did. During a difficult period the most likely thing to be wrong is your record of your own actions.

Then resolve every ambiguous transaction. Take each signature whose outcome you do not know and establish its fate. This is not optional and it is not something to do later, because a transaction you gave up on can still have been included, and a position you believe you missed may be a position you hold.

Only when both are done is it safe to trade again. Resuming before reconciliation is the classic second mistake of a bad session, and it is usually more expensive than the first one, because it is made with confidence.

Reconstructing your own timeline

A timeline is a list of moments with evidence attached. It does not need to be elegant and it does need to be specific.

1. First anomaly. The earliest moment you noticed anything, with a wall-clock time and what you were doing.
2. What you observed. The concrete symptom, in the terms it appeared in: a timeout, a rejection, a stale balance, a widening gap between two endpoints.
3. What you checked. Each check you ran and its result, including the ones that came back clean, and the time of each.
4. What you changed. Every alteration made during the session, with its time. This is the section people leave out and the one that explains the most.
5. Outcomes. Signatures, with their resolved fates: included and succeeded, included and failed, or never included.
6. End. When behaviour returned to what you consider normal, and what told you so.

Twenty minutes, if you took notes during the session. Considerably longer if you did not, and the reconstruction will be worse, because the details you need are the ones nobody remembers: which endpoint, what time, which signature.

What the chain can tell you

The chain is the only witness that does not have a point of view. For each signature there are exactly three answers, and each one leads somewhere different.

Present and successful. The transaction was included and executed. Whatever your interface showed at the time, this trade happened, and your position reflects it. If your records say otherwise, your records are the thing that is wrong.

Present and failed. The transaction was included and failed on chain, with a reason recorded. This is a parameter or market outcome rather than a network one: slippage exceeded, balance insufficient, account state changed. It tells you the network did its job and your instruction did not survive contact with the state it met.

Absent. No record exists, so the transaction was never included. This is the inclusion competition, and it is answered by fee posture, sizing, deadlines and timing rather than by anything about your parameters.

Counting how your attempts distribute across those three categories is the single most informative thing you can do after a session. A run dominated by on-chain failures and a run dominated by absent signatures look identical from a client and demand opposite responses. The Solana explorer resolves them one at a time; a handful of representative signatures is usually enough for the pattern to appear.

Reading an official write-up

If the event was broad enough to be declared, there will be material published by the people who actually have the evidence. Incident notices and their updates appear on the operator-published status property at status.solana.com, and deeper technical material about causes and the changes made in response is published by the client maintainers, whose documentation lives at docs.anza.xyz.

Read for four things and ignore the rest. What class of event was it. What was the mechanism. What changed as a result, in code or in operational practice. And what, if anything, operators say participants should do differently.

Deliberately do not read for blame, and do not read for a number you can quote. Durations and impact figures published in an official account describe that event and are not a general property of the network, and repeating them out of context is how a specific fact becomes a false generalisation on the internet.

Match the write-up against your own timeline rather than replacing your timeline with it. If your first anomaly was well before the declared start, that is interesting and worth keeping. If your session was unaffected while others were, that is also interesting, and it usually means something about your endpoint rather than about you.

What a write-up is not

An official account explains an event on the network. It does not tell you whether your setup handled that event well, and this is where most reviews go wrong.

Two operators can read the same publication and reach opposite conclusions about their own systems, correctly, because their exposure differed. One had bounded retries and a stopping rule and lost a little. The other had unbounded retries and no rule and lost considerably more from the same conditions. The network account is identical; the lesson is not.

So separate the two questions explicitly. What happened on the network is answered by the write-up. How your system behaved during it is answered only by your own timeline, and it is the question that produces the change.

This applies to any tooling you did not build. If you run a hosted platform, the useful post-event question is whether its reporting let you answer the second question at all. A console that shows attempts, inclusions and on-chain failures as separate figures makes the review possible; one that reports a single success number does not, and no amount of reading about the network will fill that gap.

The one-change rule

At the end of the review you make exactly one change. Not five, not a rewrite, one.

The reason is attribution. Conditions are not reproducible, so you cannot run the experiment again with different settings. If you alter several things and the next difficult session goes better, you have learned nothing about which alteration mattered, and you have added complexity you will not be able to justify later.

A good change is small, specific, and traceable to an observation in your timeline. A retry cap where the timeline shows unbounded retries. A signature-resolution gate where the timeline shows a replacement sent into an unknown outcome. A stopping rule where the timeline shows an hour of sending after the point you now recognise as the moment to stop.

A bad change is a general improvement with no observation behind it. Switching provider because the session was unpleasant, when your notes show your endpoint agreed with an independent one throughout, is a change that will feel productive and teach you nothing.

The reconciliation worksheet

The structure below is what a completed review looks like. Fill it once and it becomes a template you can complete under time pressure.

The three chain-sourced rows are the core. Everything above them is context and everything below is judgement, but those three are facts, and they are the facts that decide which direction your change should point.

Lessons and coincidences

Bad sessions produce false lessons reliably, because a condition that ends on its own schedule will happily take credit for whatever you did last. The three most common false lessons are worth naming.

• The fee lesson. You raised the price, things improved, you conclude that price was the answer. Check whether the improvement arrived with the change or several minutes later, and whether a quiet account was also struggling at the time.
• The provider lesson. You switched endpoint, things improved, you conclude the first provider is unreliable. Check whether your notes show the two endpoints disagreeing at the time. If they agreed, you changed nothing that mattered.
• The code lesson. You altered a parameter, things improved, you conclude the parameter was wrong. Check whether anything else changed in the same minutes, including the condition itself ending.

The test for all three is the same: does the timeline show the improvement following the change closely enough, and does an independent observation support the mechanism you are proposing? If not, keep the note and do not keep the conclusion.

This is also the fair way to judge a tool. Deciding after one bad session that a platform is broken, or that Solana Volume Bot Pro or any other hosted console is the answer, is the same error in both directions. What either judgement needs is your own three-way split of attempts, and whether the tool made that split visible to you without a manual reconstruction.

Keeping the record

One review is a document. Twenty reviews are an operating manual for your own system, and they are worth more than any live indicator because they describe your setup rather than the market.

• Keep every review, including the ones where nothing was wrong on your side.
• Record the one change and the observation that motivated it, in the same entry.
• Note what you deliberately did not change and why, so the next review starts from a known baseline.
• Keep a copy of the resolved three-way split rather than only your conclusion about it.
• Record the official status result including clean answers, with the time you checked.
• Revisit the file quarterly and remove settings whose justification no longer holds.
• Never backdate an entry, and never smooth a timeline to make it read better.

What accumulates is a short list of changes, each with a reason and a date, and a longer list of conditions you survived without altering anything. Operators who keep that record stop rebuilding their systems after every difficult week. They already know which parts have failed them, which parts have not, and which unpleasant afternoons were simply the network having one.

Questions the desk keeps being asked