How to Land a Solana Transaction Reliably (and Know That It Landed)

The Short Answer

Sending a Solana transaction and landing it are two different things. sendTransaction submits to the network and returns a signature — but during congestion the transaction can expire (blockhash timeout) or be dropped before a leader ever processes it, and you only find out by polling getSignatureStatuses yourself. Reliable landing means three things: submit through multiple independent paths (local RPC, a MEV relay like Jito, and a direct-to-leader TPU/QUIC leg), re-send with a fresh slot window if it doesn't confirm within a few slots, and track confirmation yourself. A sendAndConfirm-style method packages exactly that: one call that sends across multiple legs, polls for confirmation, auto-resends until it lands or times out, and returns the landing slot, time-to-confirm, and retry count.

Why a plain sendTransaction isn't enough

When you call sendTransaction, the node:

Optionally runs a preflight simulation against the current bank.
Forwards the transaction to the current and upcoming leaders over QUIC.
Returns the transaction signature immediately — before the transaction is processed.

The signature is a receipt that the node accepted the transaction, not that it landed. Under load, leaders are flooded and the transaction competes for block space. If it isn't processed within the blockhash's validity window (~150 slots, roughly a minute), it expires silently. Your bot is left holding a signature that will never confirm.

For a trading or sniper bot this is the difference between catching a launch and missing it. Detection latency gets all the attention, but a detection is worthless if the resulting buy never lands.

The three properties of a landing-grade send

1. Multiple independent send paths. A single RPC node forwards over one path. A landing engine sends the same signed transaction concurrently through several — the local RPC's leader fan-out, a Jito bundle/relay for MEV-protected inclusion, and a raw TPU/QUIC leg straight to the leader. First success wins; the redundant legs raise the probability that at least one path lands the transaction in the current slot.

2. Confirmation tracking with auto-resend. Instead of returning after the first submission, the engine polls getSignatureStatuses. If the transaction hasn't confirmed after a handful of slots, it re-sends within the still-valid blockhash window. This converts "submitted and hoped" into "submitted, watched, and retried."

3. Honest outcome reporting. The call should tell you the landing slot, how long confirmation took, which legs were attempted, and how many re-sends it took — not just a bare signature. That data is what lets you measure your real landing rate and tune priority fees.

Preflight simulation: a hidden landing failure

One non-obvious failure mode: sendTransaction runs a preflight simulation by default, and the simulation races the blockhash. By the time a processed-commitment blockhash is simulated, it can already be expired, producing a BlockhashNotFound error before the transaction is ever sent. For landing-critical sends, skip the preflight (skipPreflight: true) and let confirmation tracking — not simulation — be the landing guarantee. A well-built sendAndConfirm sets this for you by default; confirmation polling, not simulation, is what proves the transaction landed.

What outcome-based pricing looks like

Because landing is the thing of value, some providers price the send on the outcome rather than charging a flat fee per call. The shape of that model: a small base fee covers the multi-leg send work on every attempt, and a landing premium is charged only when the transaction actually confirms — refunded automatically if it doesn't. You pay for landed transactions, not for submissions that expired.

Where Nodius fits

Nodius exposes this as a first-class sendAndConfirm method on the same wallet-authenticated endpoint as everything else. A single call routes through the multi-leg coordinator — local RPC, Jito, and a TPU/QUIC direct-to-leader leg — with per-leg health scoring that deprioritizes a degraded path automatically. It polls for confirmation, auto-resends inside the blockhash window, and returns { signature, slot, confirmations, landing_time_ms, legs_attempted, retry_count, confirmed, charged_credits }. Billing is outcome-based: the landing premium is refunded when the transaction doesn't confirm, so you're charged the full landing price only on a confirmed land. It pairs directly with the subscribeSignal firehose — the same node that detects a new pair can land the resulting snipe in the next call, with no second provider in between.

{
  "jsonrpc": "2.0",
  "method": "sendAndConfirm",
  "params": ["<base64-signed-transaction>", { "encoding": "base64" }],
  "id": 1
}

Live per-call cost is served at GET /pricing; see the API reference for the full method contract and the bot guide for auth setup.