Jito Bundle Status Monitoring: Pending, Landed, Failed and Invalid

A bundle ID returned by Jito means that the Block Engine accepted the submission. It does not mean the transactions landed, executed successfully or reached the commitment level your application requires. Production software needs a reconciliation loop that distinguishes submission, auction state, on-chain execution and final confirmation.

This guide follows the current Jito low-latency transaction documentation and focuses on the operational states a Solana execution service should persist.

The bundle lifecycle

A useful internal state machine starts before the API response:

1. Constructed — transactions have been built against a recent blockhash but have not been submitted.
2. Submitted — the Block Engine returned a bundle ID.
3. Pending — the bundle remains visible to the inflight endpoint and has not been marked failed, landed or invalid.
4. Landed — Jito reports that the bundle landed in a slot.
5. Confirmed or finalized — the individual transaction signatures reached the commitment level required by the application.
6. Failed, expired or unknown — the system must stop waiting, record the reason and decide whether a new attempt is safe.

Persist the signed transaction signatures with the bundle ID. They are needed when the inflight record expires and for independent verification through Solana RPC.

getInflightBundleStatuses

The inflight endpoint covers recently submitted bundles and is the fastest way to distinguish four Jito states: Pending, Failed, Landed and Invalid. The documented lookback is five minutes, and one request can contain up to five bundle IDs.

A minimal JSON-RPC request looks like this:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getInflightBundleStatuses",
  "params": [["YOUR_BUNDLE_ID"]]
}

Treat Pending as an observation, not permission to resubmit immediately. A duplicate attempt can create conflicting transactions or unintentionally repeat an action when the original bundle lands shortly afterward. Use an application-level idempotency key and understand whether the instructions themselves are safe to retry.

Failed means all regions that received the bundle marked it failed and it was not forwarded. Log the response, simulation result, blockhash age, tip policy and region before considering a retry.

Landed identifies a landing slot. Continue with signature-level confirmation because the client may require confirmed or finalized state and because application bookkeeping should be based on transaction results.

Invalid means the bundle is no longer present in the inflight system. It does not, by itself, prove that nothing landed. Fall back to stored transaction signatures and normal Solana status checks.

getBundleStatuses

The longer-lived bundle status method behaves more like Solana's getSignatureStatuses. When found, it returns the bundle ID, transaction signatures, slot, confirmation status and an error field. If the method returns null, the bundle may not have landed or may be outside the recent status history searched by the backing RPC.

This is why a production reconciler should not model null as a permanent failure. Check the signatures independently and stop only after the blockhash validity window and the application's retry policy have been evaluated.

Reconciliation loop

A practical worker can poll quickly at first, then back off:

submit -> store bundle_id + signatures + last_valid_block_height
       -> poll inflight status
       -> if landed, verify every signature
       -> if invalid/null, query signatures directly
       -> classify success, program error, expiry or unknown
       -> emit one idempotent business event

Store timestamps for submission, first landed observation and confirmation. Those values let you measure landing latency separately from confirmation latency. Also store the selected region, tip, priority-fee policy, transaction size and compute-unit limit so failed and successful attempts can be compared later.

Failure cases worth testing

• The Block Engine returns a bundle ID, but the bundle never wins an auction.
• The recent blockhash expires while the application still reports Pending.
• A transaction fails simulation before submission.
• A landed bundle contains an application-level result that still requires reconciliation.
• RPC providers disagree temporarily about signature status.
• The process restarts after submission but before confirmation.
• A skipped or uncled slot causes transactions to be observed outside the expected bundle path.

Jito warns that transactions from an uncled block can be rebroadcast through the normal banking path. Important invariants should therefore be enforced by transaction instructions and account assertions, not only by an assumption of bundle atomicity.

Operational rules

Never report profit or update a position from the sendBundle response alone. Update business state after the relevant signatures and account changes have been verified. Keep signing isolated from status polling, expose stale Pending bundles in monitoring and alert when unknown outcomes exceed a defined age.

For systems that submit continuously, batch status requests within documented limits and respect regional rate limits. A queue per signer or strategy helps prevent a retry storm during provider degradation.

TierZero implements Jito submission and reconciliation as part of Solana execution infrastructure. If you already have a sender but cannot reliably explain whether every attempt landed, request a focused execution review.