Jito Bundle Not Landing on Solana? How to Check Submitted vs. Landed Status

A Jito bundle_id tells you that your bundle was received. It does not tell you that its transactions landed on Solana. If your application reports “submitted” but you cannot find the expected on-chain result, check the bundle status before changing the tip or sending it again.

This guide separates Jito’s recent in-flight statuses from processed bundle results. It is for operators investigating an existing submission, not a token-launch walkthrough.

Submitted vs. landed

Jito’s sendBundle relays a list of signed transactions for processing. Its documentation explicitly says that receiving a successful response with a bundle_id does not guarantee processing or on-chain landing. Save that ID, the submission time, the endpoint used and every transaction signature. A bundle ID is not interchangeable with a transaction signature.

Submission is a receipt. Landing needs a separate status check.

A normal Jito bundle contains up to five transactions. They execute sequentially within the same slot and atomically through the bundle execution path: if one fails, the bundle cannot commit successfully. That describes the execution rules, not a promise that a submitted bundle will be selected.

There is an important exception when reconciling explorer results. Jito warns that transactions from an uncled block can be rebroadcast through Solana’s normal banking stage, which does not preserve bundle atomicity. An individual transaction appearing in an explorer is therefore not, by itself, proof that the complete bundle landed as intended.

Read the bundle status

getInflightBundleStatuses checks submissions within the last five minutes, with up to five bundle IDs per request. These are Jito’s documented meanings:

The five-minute window is a status lookup boundary, not a universal transaction expiry rule. An older bundle returning Invalid does not prove it never landed. Likewise, a Failed response is a specific in-flight outcome—not evidence that every future corrected submission must fail.

getBundleStatuses is the complementary check for processed bundle details. A found result includes the bundle ID, transaction signatures, processing slot and confirmation status. Jito lists processed, confirmed and finalized; landing and finalization are different observations.

If the bundle is not found or has not landed, this method returns null. Its on-chain lookup uses recent transaction history rather than an unlimited archive. Treat null as “not established by this lookup,” not a permanent failure verdict.

Check both status methods

Use the actual ID returned by your submission. These read-only request templates follow the official Jito status API. Replace YOUR_BUNDLE_ID before running them. They are examples, not records of an executed or successful bundle.

curl 'https://mainnet.block-engine.jito.wtf/api/v1/getInflightBundleStatuses' \
  -X POST -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"getInflightBundleStatuses","params":}'

For processed details, use the second method rather than guessing from your application’s “submitted” label:

curl 'https://mainnet.block-engine.jito.wtf/api/v1/getBundleStatuses' \
  -X POST -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"getBundleStatuses","params":}'

1. Confirm the identifier. Copy the bundle ID from the submission response, not a wallet address or one transaction’s signature.
2. Check recent in-flight status. Record the exact status and time. Preserve the whole response instead of converting every non-Landed result to “failed.”
3. Check processed status. Inspect transaction signatures, slot, confirmation state and any reported error. Jito says retryable status-query errors should be queried again.
4. Reconcile on-chain evidence. Search the actual bundle in Jito Explorer and check the saved transaction signatures with your Solana RPC or explorer when the status methods do not establish the outcome.

Do not poll aggressively. Jito documents a default limit of one request per second per IP per region. An HTTP 429 or a JSON-RPC error is a request problem, not one of the four in-flight bundle statuses. Preserve that distinction in logs and support reports.

Diagnose before resubmitting

Once the evidence is recorded, investigate the relevant failure class. Raising the tip is not a substitute for checking whether the transactions can execute.

• Transaction validity: Jito’s troubleshooting guidance recommends simulateTransaction and says Jito-Solana RPC should support simulateBundle. Check your provider’s actual support before relying on the latter. A single-transaction simulation does not prove that a dependent sequence succeeds as a bundle.
• Tip and auction competition: a tip is required for consideration. Jito documents a minimum of 1,000 lamports, but says that this can be insufficient in competitive conditions. Check current tip information; no tip amount guarantees selection or landing. Do not transfer single-transaction priority-fee recommendations into a universal sendBundle recipe.
• State and balance conditions: verify sufficient funds and the conditions needed for the tip and main instructions to execute. Jito recommends appropriate state assertions, particularly when a tip is in a separate transaction.
• Latency: Jito explicitly includes latency to the components you interact with in its landing troubleshooting. Preserve the submission endpoint and timing so that transport issues can be investigated rather than inferred from a missing explorer result.

Before rebuilding or resending, reconcile the original signatures and current chain state. If transactions were rebroadcast outside the intended bundle path, repeating the operation without checking what already happened can produce an unintended action. A corrected submission still needs its own status checks; a new receipt is not proof of a new landing.

For support, collect the bundle ID, submission time, endpoint, transaction signatures, exact responses from both status methods and available simulation errors. Never include a private key or a Panda Bundler support key in a public issue.

If the next problem is organizing the wider launch and trading workflow, continue with the Solana Bundler Guide. It owns wallet preparation and operator workflow; this page stays focused on Jito submission diagnostics.

Panda Bundler is a web-based launch and trading platform accessed through PandaBoost support with a support key. Use that handoff to discuss your operator requirements—not as a guarantee of landing, MEV protection or first-block position.

FAQ