Skipping Preflight Simulation on Solana: Speed vs Safety Tradeoffs

Every millisecond in Solana bot development is a negotiation, and skipping preflight simulation on Solana is one of the first deals you have to make. The flag is a single boolean — skipPreflight: true in your sendTransaction options — but the consequences range from a quiet 30 ms improvement to a cascade of reverted transactions that burn your fee budget and miss every window you were racing for.

What Preflight Actually Does

When you submit a transaction with preflight enabled (the default), your RPC node does three things before forwarding it to the leader: it checks the transaction signature format, verifies that the referenced blockhash is recent enough to be valid, and runs a simulation of the transaction against its local account cache. That simulation executes the full instruction set in a sandboxed environment and returns any program errors — insufficient funds, constraint violations, bad account discriminators — before you pay a fee.

The cost is a full synchronous round-trip on that simulation. Your client sends the transaction, the RPC node runs simulateTransaction internally, responds with the result, and only then sends the packet on. On a properly peered node this adds roughly 20–60 ms. On a shared public RPC under load, that number easily becomes 80–150 ms.

The Numbers That Actually Matter

In a sniping or MEV context, the first-block landing rate degrades nonlinearly with latency. At 50 ms extra you might drop from landing in block N to block N+1 perhaps 15–25% of the time, depending on how contested the target is. At 100 ms you can be consistently one or two blocks behind the pack.

The failure modes you accept by skipping preflight are measurable:

• Stale blockhash reverts: A blockhash is valid for roughly 150 slots (~60 seconds). If your transaction construction pipeline is fast, stale hash reverts without preflight are essentially zero under normal conditions. They spike during RPC instability or when you cache blockhashes too aggressively — we see rates of 0.5–2% in those scenarios.
• Fee-payer / account errors: These are the real danger. Preflight catches insufficient SOL in your fee payer, missing token accounts, and ATA initialization gaps before you consume a fee. Without it, those transactions fail on-chain and cost you the priority fee. On bots submitting hundreds of transactions per hour, a 1–3% error rate from account-state drift translates to meaningful fee leakage.
• Program constraint reverts: If your simulation logic is wrong or you skip simulation everywhere including your test path, you lose the safety net that catches malformed instructions. This matters most in complex multi-instruction transactions — a swap followed by a transfer followed by a close, for example.

When Skipping Pays Off

The tradeoff is favorable in three specific situations. First, in Jito bundle submission — Jito's block engine does not run preflight against your bundle anyway, and you are already paying a tip for inclusion. Simulating before bundle submission gives you a false sense of safety and adds latency with no real protection; the bundle either lands or it doesn't based on tip priority and block space, not preflight validation. Skip it.

Second, in high-frequency sniping where you control account state tightly. If your bot manages a fixed set of pre-funded fee wallets, you know the account balances, and you rotate wallets deterministically, the account-error failure modes that preflight catches simply don't occur. You have already done the check in your own process. Skipping the RPC-side duplicate saves real time.

Third, when you are operating on a co-located or private RPC node with sub-millisecond local round-trips. If the simulation costs you 5 ms rather than 50 ms, the urgency of the tradeoff shrinks significantly. Profile your actual round-trip before making the call — the right answer depends on your infrastructure, not a general rule.

When Keeping Preflight Is Worth It

Keep preflight enabled on any transaction path that involves dynamic account state you have not fully reconciled in memory. Order placement bots, market-making engines, and anything that reads on-chain state to construct a transaction benefit from preflight as a last-chance guard. A missed quote update that causes a failed order on Solana DEX is annoying but recoverable; without preflight it fails on-chain and costs a priority fee each time.

Also keep it enabled during development and on any code path that handles user-supplied parameters. Preflight simulation is your cheapest integration test and catches instruction encoding bugs before they hit mainnet. The bots we ship at TierZero always ship with preflight enabled in staging environments, even when the production path skips it.

A Practical Implementation Pattern

The cleanest production pattern is not a binary choice. Gate preflight on transaction type:

const opts: SendOptions = {
  skipPreflight: isJitoBundle || isHighFrequencySnipe,
  preflightCommitment: "processed",
  maxRetries: 0,
};

Set maxRetries: 0 regardless — Solana's client-side retry loop with stale blockhashes is worse than managing retries yourself with fresh hashes. When preflight is off, wire your own error handler to classify on-chain failures and resubmit with a fresh blockhash if you see BlockhashNotFound. Treat fee-account failures as alerts, not retries — they usually signal a wallet management bug that needs fixing, not a transaction worth resending.

Monitor your skip-preflight revert rate as a first-class metric. If you are seeing more than 2% of skipped-preflight transactions fail on-chain for non-competition reasons (i.e., not "someone else landed first"), that is a signal your account state tracking has drifted and the skip is costing more than it saves.

---

If you are building latency-sensitive bots on Solana and want an infrastructure setup that handles these tradeoffs correctly from day one, reach out — this is exactly the kind of production detail we get right before the first transaction lands.