Solana transaction landing
What landing means on Solana, the five checkpoints a signed transaction passes, and the difference between landed, succeeded and confirmed.
Read the entryWhether the transaction lands is the whole game
Strike Log reads the Solana send path the way a flight recorder reads a flight: symptom, mechanism, instrument, correction. Not what to trade, but whether the transaction expressing that decision actually reached a block, how long it took, and what it charged you on the way.
Every entry works from documented protocol behaviour and evidence any operator can reproduce against a public endpoint. Every tuning recommendation states what it costs.
SEND PATH CONSTANTS
- Blockhash window
- About 150 blocks, counted in block height rather than seconds
- Base fee
- 5,000 lamports per signature, charged on inclusion
- Unit ceiling
- 1,400,000 compute units for a single transaction
- Packet limit
- 1,232 bytes for a serialised transaction
- Leader rotation
- Four consecutive slots per leader, assigned each epoch
The four ways a send dies
Almost every failure an operator meets is one of these four, and they leave different amounts of evidence behind. Only the last one appears on chain, which is why the first three feel like mysteries and are not.
D1 / EXPIRED
The window closed
The referenced blockhash aged past the acceptance window before any leader packed the transaction. It cannot land now and it cost nothing. The window is spent from the moment the blockhash is fetched, not from the moment you send.
Correction: fetch later, measure in blocks
D2 / REFUSED
The endpoint said no
Preflight simulation failed, the node did not recognise the blockhash, or the request hit a rate limit. This class is the most informative, because the response usually names the program and the error that stopped it.
Correction: read the simulation logs first
D3 / SILENT
Nothing came back
A signature was returned and no status ever appeared. The transaction was never delivered to a block-producing leader, or arrived when that leader had better-paying candidates. There is no error to catch anywhere.
Correction: resend identical bytes, never rebuild
D4 / REVERTED
It landed and failed
The transaction was included, executed, and returned an error from one of its instructions. It paid its base fee and its full priority fee. From the network's point of view this is an entirely ordinary transaction.
Correction: read the instruction index, not the total
Featured log entries
Four entries that cover most of what an operator needs before touching a single setting: what landing means, why sends fail, what a priority fee buys, and how to measure any of it without fooling yourself.
Why transactions fail
A fault table for the send path: which errors are client-side, which are runtime rejections, which never reached a leader, and what each one costs you.
Read the entryPriority fees in practice
How the priority fee is actually computed, why the requested unit limit and not the consumed one sets the bill, and how to raise a fee without wasting it.
Read the entryMeasuring landing rate
A landing rate that means something: what counts as an attempt, what counts as a landing, and the four numbers that make the rate diagnosable rather than decorative.
Read the entryTwo sections, one send path
Landing asks whether the transaction got in. Latency asks how long it took and what it cost. They are the same path measured with different instruments, and an answer from one is usually meaningless without the other.
Landing Did it get in Whether a signed transaction reaches a block at all: expiry windows, rejection classes, duplicate risk on retry, and the evidence that separates a dropped send from a failed one. Latency How long and how much The cost and timing side of the same send path: priority fees, compute budgets, measured landing rate over time, and what the network does to all three when it is busy.
Telemetry the desk works from
Five figures that appear across the entries. They are protocol constants and documented mechanisms, not measurements of anyone's run, and every piece of arithmetic on this site is built from them or clearly labelled as illustrative.
- Blockhash window
- Roughly 150 blocks of validity, measured against block height, which advances only when a block is actually produced.
- Signature fee
- 5,000 lamports per required signature, charged whenever the transaction is included, including when its instructions fail.
- Compute ceiling
- 1,400,000 units per transaction, with priority fee computed from the units requested rather than the units consumed.
- Transaction size
- 1,232 bytes for a serialised message, which is what address lookup tables in versioned transactions exist to work around.
Practical entries
The four remaining entries, each one a mechanism with a correction and a stated price.
- LND-03Blockhash and expiry
- LND-04Retries without duplicates
- LAT-02Compute units and limits
- LAT-04Behaviour under congestion
When the send path stops being your problem
Building this instrumentation is worth it if the send path is the thing you want to understand. If it is not, the whole checkpoint list can sit behind an interface, and the question changes from how do I fix delivery to how do I verify what I am being told.
That second question is shorter and it has a fixed answer: signatures, slots, intents and cost per landed swap. A console that reports those can be checked against the same instruments described throughout this log. One that reports a single percentage cannot be checked at all.
How this log is written
The method is deliberately narrow, and the limits are part of it. More detail, including what happens when an entry turns out to be wrong, is on the page about how this log is written.
Mechanism before advice
Every entry starts from a documented behaviour of the runtime or the client, and reaches a recommendation only after the mechanism is on the page. A correction that cannot be traced back to a mechanism does not get published.
Numbers or nothing
A figure here is either a protocol constant, arithmetic labelled as illustrative, or absent. The desk does not publish landing rates, latency measurements or performance figures, because those belong to a specific run and cannot be generalised honestly.
Every trade has a price
Each recommendation names what it costs: a round trip, a rebuild, lamports on every landed transaction, or throughput. Readers are meant to be able to decline a suggestion on grounds the entry itself supplied.