Trading through congestion
A working posture for periods when inclusion is expensive and uncertain: smaller units, explicit deadlines, honest fee budgets, idempotent retries and a rule that tells you when to stop.
Open the reportResponding to Solana network conditions while you are still trading
Knowing that the network is contended does not by itself tell you what to do about it. Response is a separate discipline, and it splits cleanly in two. While a condition is running you are managing exposure with degraded information, so the useful moves are the ones that reduce the cost of being wrong. After it clears you have complete information for the first time, so the useful move is a single deliberate change to the settings that failed you.
Both halves work better when they are decided in advance. A stopping rule written on a calm day is a rule; the same decision made during a bad session is a mood. This section covers the working posture for a contended period and the reading pass that turns the session afterwards into something you can act on.
during reduce cost Smaller units, explicit deadlines, honest fee budget, safe retries
stop rule pre-written A threshold decided calmly, not a judgement made while losing
after read first Your own timeline, then the official write-up, then one change
change one at a time Two simultaneous changes teach you nothing about either
2 reports in this section
What to change while conditions are bad and what to do once they clear: sizing, fee posture, retry discipline, pausing rules, and the reading pass that turns an incident into a settings change.
After an incident
The reading pass that turns a bad afternoon into a settings change: reconstructing your own timeline, matching it against official post-incident publications, and deciding what to alter.
Open the reportThe rule that saves the most money
Stop sending. It sounds too simple to be a technique, and it is the response most operators reach last, after an hour of raising fees into a window that was never going to include them. A contended period ends. The trade you wanted may not still be there afterwards, which is a real cost, and it is a smaller cost than an unbounded retry loop paying for inclusion it does not get. Write the threshold down before you need it, and let the rule make the decision.
| Situation | Weak response | Better response | Why |
|---|---|---|---|
| Repeated rejections on one pair | Raise the fee and resend faster | Halve the size, widen the deadline, resend once | Contention is per account; smaller and slower competes better than louder |
| Every venue failing at once | Rewrite the routing logic | Pause and check for a declared incident | A chain-wide condition is not fixed by your code |
| Unknown outcome after a timeout | Send a replacement immediately | Resolve the original signature first | A replacement can execute alongside the original |
| Session over, still angry | Change five settings tonight | Write the timeline, change one setting | Only one change per event is attributable to the event |
Conditions The states the cluster can be in and what each one does to a trader: contention for block space, degraded periods where the chain runs but runs badly, and the scheduled windows around epochs and client upgrades. Open the section Diagnosis Separating a chain-wide condition from an endpoint fault and from a mistake in your own request. The order of checks, the evidence each one produces, and where the official status signal actually lives. Open the section