How This Log Is Written
Strike Log is written by a desk rather than a person, publishes mechanisms rather than measurements, and states the price of every recommendation. This page sets out how that works and where it stops.
What the desk covers
Strike Log covers the Solana send path: the sequence between a decision to transact and a confirmed outcome on chain. That means blockhash validity and expiry, preflight and admission, delivery toward a leader, scheduling and block inclusion, compute budgets, priority fees, retry semantics and the measurement of all of it.
It does not cover what to trade, when to trade it, or whether a given token is worth attention. Those are strategy questions and this desk has nothing useful to say about them. The scope here begins after a decision has been made and asks only whether the transaction expressing that decision actually happened.
Who writes it
Entries are published under The Strike Log Desk. There is no invented author, no photograph and no biography, because a fabricated person would be the first dishonest thing on the site and would undermine everything after it. The byline is the desk, and the desk is accountable for the entries through the correction process described below.
Where the material comes from
Three sources, in this order of preference. First, published Solana documentation and the reference material maintained around the client and validator implementations. Second, behaviour that any operator can reproduce against a public endpoint with ordinary JSON-RPC calls. Third, the structure of the client libraries themselves, where a behaviour is visible in how an interface is shaped.
What is deliberately absent is a fourth source: the internals of any commercial product. This desk does not have access to how any particular engine is built, does not claim to, and treats every vendor description as a claim to be checked rather than a fact to be repeated.
The rules on numbers
A figure appears on this site only if it belongs to one of three categories, and entries are checked against this rule before publication.
- A protocol constant, such as the 5,000-lamport base fee per signature, the 1,400,000-unit per-transaction compute ceiling, or the 1,232-byte packet limit.
- Arithmetic explicitly labelled as illustrative, built from those constants and from counts chosen to make a relationship legible.
- A value attributed to a named public source that a reader can check for themselves.
Anything else is left out. In particular the desk does not publish landing rates, confirmation times, success percentages or cost figures presented as typical, because those belong to a specific run with a specific window, endpoint and venue, and generalising them would be inventing data. Where a value would be useful and cannot be established honestly, the entry says so rather than filling the gap.
What the desk will not publish
The exclusions are as much a part of the method as the inclusions, and they are firm rather than aspirational.
- No fabricated statistics, review counts, ratings or testimonials, and no invented case studies with profit and loss figures attached.
- No runnable automation. Entries describe mechanisms, sequences and configuration reasoning, and stop short of code that would let someone deploy a strategy without understanding it.
- No technique whose purpose is to deceive another market participant about what is happening. Describing how the send path behaves is not the same as supplying a method for misrepresenting activity.
- No performance claims about products, including products this site links to. A link is a pointer to something a reader may want to evaluate, not an endorsement of any number it publishes.
- No backdated entries. Publication dates reflect when the entry was actually written, and updates are recorded as updates.
How an entry is built
The shape is consistent because the shape is the argument. Each entry opens with a fault card naming a symptom, the mechanism underneath it, the instrument that distinguishes it from its neighbours, and the correction that follows. The body then works through the mechanism in enough detail that the correction is obvious by the time it arrives.
Every recommendation carries its price. A round trip, a rebuild, lamports charged on every landed transaction, throughput given up, or operational attention spent. This is not a stylistic habit; a recommendation without a stated cost is unfalsifiable, and a reader cannot sensibly decline it. Where a trade has no good side, the entry says that instead of dressing it up.
Corrections
Solana changes. Limits are raised through network proposals, client defaults move, and a mechanism described accurately in one period can be described inaccurately in the next without a word on the page changing. When that happens the entry is wrong and the desk would rather hear about it than not.
Corrections are made in the entry itself rather than in a separate notice, and the modification date on the page moves when they are. Substantive changes are described in the text where the change matters, so a returning reader can see what moved. The desk does not quietly rewrite a claim and leave the page looking as though it always said the new thing.
If something here is wrong, incomplete or has aged out of accuracy, the fastest route is the corrections page. Specific beats polite: naming the entry, the sentence and what the current behaviour actually is makes a correction possible in one exchange.
Links to commercial tools
Some entries link to automation platforms where the paragraph is genuinely about choosing or operating one. Those links exist because the topic came up, not because a page was written to hold them, and they are the same links a reader would find by searching the subject.
The desk does not audit any platform it links to, has no way to verify a vendor's internal behaviour, and says so wherever a link appears near a claim. The standard applied throughout this log is the one to apply there too: ask for the denominator, the window and the source, and treat any number without all three as decoration.
What this site is for
It exists because the send path is the part of automated trading on Solana that is least discussed and most often responsible for a bad outcome. Strategy attracts attention; delivery quietly decides whether the strategy ever happened. An operator who can name which of five checkpoints stopped a transaction is in a completely different position from one who can only report that it did not work.
That is the whole ambition. Not to make anyone faster, and certainly not to promise a rate. To make the failure legible, so the next correction is chosen rather than guessed.