Execution
Strategy decides what to trade. Execution decides whether that decision ever becomes a transaction in a block, at what price, and at what cost. This section covers the layer where most unexplained losses actually originate.
The defining property of this layer is that its failures are silent. A transaction that never lands leaves no on-chain record, pays no fee and appears nowhere in a profit and loss statement. It shows up only as an opportunity that did not convert, which is indistinguishable from bad luck unless somebody is counting.
Every page here is therefore built around a measurement rather than an opinion. Landing rate for the submission path, a latency distribution rather than an average for the data path, realised against quoted price for the fill, and cost per successful trade for the whole stack. These four numbers describe an execution pipeline more completely than any vendor specification, and all four can be computed from your own logs plus one RPC method.
The ordering of effort matters too, and it is the opposite of what most operators choose. Detection quality sets the ceiling on what is achievable, landing behaviour determines whether intentions become transactions, and fee policy is a fine adjustment inside those constraints. Tuning fees while the data path is the bottleneck is the most common wasted effort in this field.
Pages in this section
Transaction landing on Solana
Why a correctly signed transaction never reaches a block. Leader schedules, blockhash expiry, a diagnostic table of drop causes, retry design and a landing-rate measurement recipe.
Priority fees and Jito bundles
Compute unit pricing with worked arithmetic, local fee markets, what bundle atomicity actually buys, when a tip is wasted, and a fee posture table by trade urgency.
RPC choice and latency
Four provider classes compared, where latency really lives, a six-step measurement recipe you can run today, and the failure modes that hide inside a good average.
The cost of running automation
Six cost lines, an illustrative worked total showing which one dominates, cost per successful trade as a metric, and a build-versus-buy comparison.
The four numbers worth instrumenting
Landing rate is the share of submitted transactions that reach a confirmed block, and it is the first thing to measure because it partitions every other problem. Notification delay, measured against the block time of the triggering event, tells you whether your view of the market is current. Realised versus quoted price exposes slippage that no quote will admit to. Cost per successful trade turns all of it into one comparable figure.
Read together, these numbers usually point at a single dominant constraint, and the fix for it is rarely the setting that was most tempting to change. That is the entire argument of this section: measure first, and let the measurement choose what you optimise.
Where this section stops
Execution covers the path from a decision to a confirmed transaction. What to trade belongs to strategy, which this desk does not publish. Whether a token can be sold at all belongs to the risk desk. Which class of tool you need in the first place belongs to bot classes.
If you only read one page
Landing rate is the metric that separates a working pipeline from a demo, and almost no consumer tool reports it.
Other sections
- Bot classes — taxonomy and evaluation
- Risk desk — screening, custody, failure modes