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 entryLanding: Whether the Transaction Got In
Landing is one bit. Either a leader packed the transaction into a block or it did not, and everything an operator argues about downstream depends on which. The entries in this section deal only with that bit: what has to be true for it to be set, what sets it to zero, and how to tell the difference between a transaction that was refused and one that was never seen.
Nothing here is about strategy. The desk takes the intention as given and asks whether the transaction expressing it actually happened.
- Window
- A recent blockhash is accepted for roughly 150 blocks, measured in block height rather than seconds
- Base fee
- 5,000 lamports per signature, charged on inclusion whether the instructions succeeded or not
- Packet limit
- A serialised transaction must fit within 1,232 bytes, derived from the IPv6 minimum MTU
- Terminal states
- Landed and succeeded, landed and failed, or expired; there is no fourth outcome
4 entries in this section
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.
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 entryBlockhash and expiry
The 150-block window, why block height and not a wall clock is the deadline, and how a durable nonce changes the contract when you need a longer life.
Read the entryRetries without duplicates
Resending identical bytes is deduplicated by the runtime; rebuilding is not. The rule that makes a retry loop safe, and the loop that terminates on evidence.
Read the entryWhat this section refuses to do
No entry in this section quotes a landing rate as though it were a property of the network. Landing rates belong to runs, and a run has a window, a venue, an endpoint and a denominator. Numbers here are protocol constants or arithmetic labelled as illustrative, and where the desk could not establish a value it says so instead of supplying one.
Checkpoint 1 Build validity: size, signers and account resolution, entirely inside your own process
Checkpoint 2 RPC admission: preflight simulation, blockhash recognition and request limits
Checkpoint 3 Delivery: forwarding toward a leader, where a drop leaves no evidence at all
Checkpoint 4 Scheduling: whether the leader had space and whether you were competitive for it
Checkpoint 5 Inclusion: the transaction executed, paid its fee, and reported an outcome
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. How this log is written Method and limits What the desk checks before an entry is published, which claims it refuses to make, and how a correction changes a page that is already live.