Solana Transaction Landing, Checkpoint by Checkpoint

On Solana, a transaction lands when a leader includes it in a block. Everything before that point is delivery, and everything after it is execution and voting. Landing is a single bit that the network reports through the signature, and most disagreements about execution quality resolve into a disagreement about how that bit is being counted.

What landing actually means

The word gets used loosely, so it is worth pinning down. A transaction that has landed was packed into a block by the leader for some slot and executed by the runtime. That is the whole claim. It does not say the swap filled, it does not say the account was created, and it does not say the block containing it will survive. It says the network saw the bytes and ran them.

This matters because the two most common ways of describing a run are counting swaps that produced the balance change you wanted, and counting sends that were accepted by an RPC endpoint. Neither is landing. The first undercounts, because failed instructions landed and were paid for. The second overcounts, because acceptance by an endpoint is only a promise to try.

Keeping landing as its own number is what makes the rest of the diagnosis possible. If landing is high and success is low, the problem is in your instructions or your slippage tolerance. If landing is low, the problem is in the send path and no amount of instruction tuning will move it. The two failure families have almost no overlap, and mixing them is why operators change the wrong setting.

The five checkpoints

Between a signed message and a slot there are five places the transaction can stop. Each has a different owner, a different symptom and a different fix. Working through them in order is faster than guessing, because the first three produce no on-chain evidence at all and the last two produce a great deal.

Checkpoints three and four are the uncomfortable ones. They leave nothing behind, which is why operators describe them as sends that vanished. Nothing vanished; the transaction was simply never given to a block producer in time, or was given to one that had better-paying candidates. The absence of evidence is itself the diagnostic signal, and it is the reason a run needs its own attempt log.

Checkpoint one is worth a separate mention because it is entirely under your control. A legacy transaction must serialise within the 1,232-byte packet the network accepts, a figure that comes from the 1,280-byte IPv6 minimum transmission unit minus header overhead. Versioned transactions with address lookup tables exist precisely to buy account slots back inside that ceiling, and a builder that has never hit it will hit it the first time a route grows an extra hop.

Landed, succeeded, confirmed

Three words that get used interchangeably describe three independent facts. A transaction can be any combination of them, and the combinations that look strange are the ones worth understanding.

Landed and failed is the most common surprising combination. A swap that hit its slippage guard was included, executed, reverted its own effects, and charged the base fee of 5,000 lamports per signature plus whatever priority fee it carried. From the network's point of view this is a completely normal transaction. From a cost report's point of view it is money spent for no position change, and it must be counted as such.

Not landed and no error is the second. The client sent, the endpoint accepted, and no signature status ever appeared. There is no exception to catch because nothing went wrong locally. The only correct handling is to treat the attempt as closed once the blockhash cannot be accepted any more, and to record it as an attempt that produced no landing rather than as a mystery.

Commitment sits on a different axis. The three levels published by the cluster are processed, confirmed and finalized, and they answer how much voting has happened on the block, not whether your instructions worked. Reading balances at processed is fast and occasionally wrong; reading accounting at finalized is slow and stable. Choosing one level for the interface and a stricter one for the ledger is a legitimate design, as long as the two are labelled.

The instruments that report each state

Every claim above maps to a specific call. The reason to name them is that an operator with a disputed landing rate usually cannot say which call produced the number, and a number without a source cannot be argued with. The Solana signature status method and the transaction fetch are the two that matter most.

• getSignatureStatuses answers landed and succeeded together: a null status means no landing yet, a status with a null error means landed and succeeded, and a status with an error object means landed and failed. Statuses age out of the recent cache, so a late poll needs the history search flag.
• getTransaction answers the same questions with the slot, the fee actually charged and the compute units consumed. It is the call to use when closing out a run rather than when tracking it live.
• getLatestBlockhash returns both the blockhash and the last block height at which it will still be accepted, which is what defines the deadline for the attempt.
• getBlockHeight is the clock that deadline is measured against. Wall time is a poor proxy because skipped slots make the mapping between seconds and blocks variable.
• getSlotLeaders exposes which validators are scheduled to produce upcoming slots, which is context for delivery rather than a diagnostic on its own.

None of these instruments requires special access. Any endpoint that serves standard JSON-RPC will answer all of them, and a run that logs the four numbers those calls produce for every attempt can reconstruct its own landing history without trusting anyone's dashboard. That reconstruction is the entire method this desk uses.

A worked landing budget

Numbers make the distinctions concrete, so here is an illustrative example built only from the documented base fee. The volumes are chosen for arithmetic, not observed anywhere. Suppose a run makes 500 send attempts against a single signer, and the attempt log at the end shows 420 signatures with a status and 80 with none.

Two ratios come out of that table and they are not the same. Landing rate is 420 of 500, or 84 percent. Success rate is 360 of 500, or 72 percent. A report that quotes only one of them is hiding the other, and the two demand opposite corrections: the 80 missing sends are answered by the send path, the 60 reverted ones by the instruction and its tolerances.

Reading one failed send

Before touching aggregates, it is worth being able to read a single attempt end to end. The sequence below takes about a minute per transaction and settles most arguments, because it produces a checkpoint number rather than an opinion.

1. Confirm the client produced a signature. If signing threw, the attempt stopped at checkpoint one and the network was never involved. Nothing about fees or endpoints is relevant.
2. Check the response from the send call. An RPC error means checkpoint two. Preflight failures name the offending instruction, and that message is the most useful single string in the whole path.
3. Record the block height at send time and the last valid block height. The gap between them is the entire budget the attempt has. If the gap was already small when you sent, delivery had almost no room.
4. Poll the signature status until the last valid block height passes. A status that appears is checkpoint five, with or without an error. No status by the deadline means checkpoint three or four.
5. If a status appeared with an error, read the instruction index. That index points at exactly which instruction returned the error, which converts a vague failed swap into a specific program error code.
6. Write the result into the attempt log with the slot. The slot is what lets you go back later and ask what the network was doing at that moment rather than what it is doing now.

Doing this for ten failures usually reveals that they are not one problem. A run with a poor landing rate typically has two or three distinct causes with quite different fixes, and the aggregate rate averages them into a single unhelpful number. Splitting first and tuning second is the order that saves the most time.

What to change, in order

Corrections have costs, and a tuning list that does not state them is a wish list. Each item below names what it buys and what it charges, so the trade is visible before it is made.

The last row is there because it is the most common misapplied fix. Widening slippage changes what happens after inclusion. If the transaction is not being included, the tolerance is irrelevant and the only thing a wider guard achieves is a worse price on the attempts that were already landing.

Order matters as much as content. Expiry is checked first because it is free to fix and invalidates every other measurement. Delivery second, because resending costs nothing but requests. Fees third, because that is where money starts moving. An operator who reaches for the fee lever first has usually paid for a problem that was never a scheduling problem.

When the send path stops being yours

There is a point at which building this instrumentation stops being the cheapest option. If the send path is not the thing you are trying to learn, a hosted runner moves the whole checkpoint list behind an interface, and the question changes from how do I fix delivery to how do I verify what I am being told. That is a different and much shorter list of questions.

The useful comparison when picking one is not the feature grid, it is the reporting. A tool that hands back signatures and slots can be audited against the same instruments described above; a tool that hands back a success percentage cannot be audited at all. That distinction is worth more than any headline number when reading a roundup of the best Solana volume bot options, because it is the only property you can independently check.

The same applies to running one. Whether the engine is yours or a hosted Solana volume bot, the operator's job after the first hour is the same: keep an attempt log, split landing from success, and treat any number without a source as decoration. The checkpoints do not care who wrote the sender.

What none of this settles is whether the run is worth making. Landing is a delivery property, not a strategy. This log takes the strategy as given and asks only whether the transactions that were supposed to happen actually happened, at what cost, and which of the five checkpoints stopped the ones that did not.

Questions this entry keeps getting