Pre-flight simulation and --skip-preflight

Every mutating sithbit command submits a Solana transaction, and every one of them accepts --skip-preflight (short -s). This page explains what the pre-flight step actually does, why the flag exists, and what you give up by using it.

What pre-flight is

Before an RPC node broadcasts a transaction to the current leader, the sendTransaction RPC method first simulates it (unless asked not to): signatures are verified and the transaction is executed against the node’s view of the bank at the pre-flight commitment level — the same machinery exposed directly as simulateTransaction. If the simulation fails, the RPC returns the error (with program logs) and the transaction is never broadcast:

• no fee is charged — a transaction that fails pre-flight costs nothing, while one that fails on-chain still pays its signature fee;
• you get the program logs — the simulated instruction trace usually pinpoints the failing instruction and error code, which is the single most useful debugging artifact the CLI can show you.

sithbit runs pre-flight at the CLI’s configured commitment (the same commitment it uses to confirm the transaction afterwards).

Why you might skip it

• Racing fresh state. The simulation runs against the RPC node’s view at the pre-flight commitment, which can lag the tip of the chain. A transaction that depends on an account mutated moments ago — say, a script that creates a mailbox and immediately funds a frombox against it — can spuriously fail simulation even though it would succeed by the time the leader executes it. --skip-preflight lets pipelined sequences run without waiting for the earlier write to reach the simulating node.
• Latency. Skipping saves the simulation round-trip, which matters when submitting many transactions in a tight loop.
• Simulator disagreements. Rarely, a node’s simulation refuses a transaction the leader would accept (state drift between nodes, or features that behave differently under simulation). Skipping removes the RPC node’s veto.

What it costs

A skipped pre-flight means a genuinely bad transaction reaches the chain: it pays its fee to fail, and the CLI has no simulation logs to show — you get an opaque on-chain error where pre-flight would have printed the program trace. Leave pre-flight on (the default) unless you know exactly why a lagging simulation is refusing a transaction you believe in.

Further reading

• sendTransaction RPC reference — the skipPreflight and preflightCommitment parameters the flag maps to.
• simulateTransaction RPC reference — the simulation surface pre-flight uses.
• Transaction confirmation & expiration guide — commitment levels, blockhash expiry, and retry strategy, including how pre-flight interacts with them.