Bundle Stuck Pending on Solana? Complete Fix Guide 2026

Your bundle is submitted, you're watching the status, and it just sits there — pending, pending, pending. No confirmation, no failure message, just silence. This is one of the most anxiety-inducing moments in a Pump.fun launch because you don't know if the token is live, if the SOL is lost, or if you should try again. Here's everything you need to know about why bundles get stuck and exactly how to fix it.

What "Stuck Pending" Actually Means Technically

When a Jito bundle is submitted to the Solana network, it goes through several stages before confirmation. First, it's sent to one or more Jito block engines. Then a Jito validator picks it up and includes it in a block. Then that block is confirmed by the network. "Stuck pending" means the bundle has been submitted but hasn't progressed past the first stage.

Unlike regular Solana transactions, Jito bundles are atomic — they either land completely or don't land at all. This is a feature, not a bug. It means your SOL is safe: if a bundle doesn't land, no money was spent and nothing was created. The uncertainty is about whether the token launch happened at all, not whether you lost funds.

The "pending" state you see in your bundler interface is the bundler waiting for confirmation from the Jito block engine. If this confirmation doesn't come within a certain timeout window, the interface shows "stuck" or continues showing pending indefinitely. This doesn't tell you definitively whether the bundle landed — it tells you the bundler didn't receive a clear success or failure signal.

How Long Is Too Long to Wait?

Jito bundles are designed to be fast. Under normal network conditions, a bundle should either land or fail within 5 to 15 seconds of submission. If you're past 30 seconds with no status change, something has gone wrong in the submission or confirmation pipeline.

During peak network congestion — which in 2026 happens regularly during US trading hours and major market events — bundle confirmation times can stretch to 30-60 seconds. But beyond 90 seconds, you should treat the bundle as failed and begin the recovery process. Waiting longer than 2 minutes almost never results in a late confirmation.

The key thing to do while you're waiting: do not submit another bundle yet. Submitting a duplicate bundle while the first one is still in an unknown state can result in double token creation if both happen to land simultaneously, or can create conflicting transactions that cause both to fail.

Cause #1 — Blockhash Expiration

Every Solana transaction is built with a recent blockhash — a reference to a recent block that proves the transaction was constructed recently. This blockhash has an expiration: transactions using a blockhash older than roughly 150 blocks (about 60-90 seconds) will be rejected by validators as potentially stale.

If your bundle construction took too long — for example, if you were uploading a large token image at launch time, or if there was a network delay in fetching the current blockhash — your bundle transactions may have been built with a blockhash that expired before validators could process them.

Fix: Always upload your token image before starting the bundle launch process. SolBundler has a pre-upload feature — use it. This ensures that when you actually submit the bundle, the only thing happening is the bundle submission itself, which is fast. Token creation + image upload + bundle submission in one step is a recipe for blockhash timeout.

Cause #2 — Jito Endpoint Congestion

Jito operates multiple block engine endpoints around the world: New York, Amsterdam, Frankfurt, Tokyo, and a mainnet endpoint. Each of these can experience individual congestion independently. If your bundler only submits to one or two endpoints and those specific endpoints are congested, your bundle gets queued behind hundreds of others and may never land before it expires.

Single-endpoint bundlers are particularly vulnerable to this. They're essentially putting all their eggs in one basket — if that endpoint is having a bad moment, your launch fails. SolBundler submits your bundle to all five Jito endpoints simultaneously. This means if four out of five are congested, the fifth still catches your bundle.

Fix if you're using a single-endpoint bundler: Switch to a multi-endpoint solution. In the short term, retry your bundle — Jito congestion is usually transient and a retry 30-60 seconds later will often land successfully.

Cause #3 — Priority Fee Too Low

Jito validators are economic actors. They choose which bundles to include in blocks based on the tips they receive. If your bundle's Jito tip is too low relative to other bundles competing for the same block space, validators will consistently pick the higher-tipping bundles ahead of yours. Your bundle keeps getting passed over until its blockhash expires.

Fix: Increase your Jito tip before retrying. SolBundler lets you adjust the tip amount in the launch settings before each submission. If you're launching during peak hours, start with at least 0.005 SOL tip. If previous attempts have failed, escalate the tip further. The extra 0.002-0.003 SOL is trivial compared to the cost of a failed launch.

Cause #4 — RPC Node Issues

Your bundler communicates with the Solana network through RPC nodes. These nodes fetch blockhashes, simulate transactions, and broadcast your bundle to the network. If your RPC node is slow, overloaded, or temporarily unavailable, the bundle construction process can fail silently or produce stale data.

Fix: Check your RPC provider's status page. Try switching to a different RPC endpoint. Premium RPC providers like Helius, QuickNode, and Triton offer significantly better reliability than public endpoints, and the cost is negligible compared to the value of a successful launch.

Cause #5 — Wallet Balance Edge Cases

Jito bundles are atomic — if any single transaction in the bundle fails, the entire bundle fails. One of the most common silent failure modes is a wallet that appears to have enough SOL but actually doesn't when you factor in rent exemption, transaction fees, and the actual buy amount.

Fix: Always leave a buffer of at least 0.01-0.015 SOL per wallet above your intended buy amount for fees and rent. SolBundler's wallet checker will flag any wallet that's too low before you attempt to launch. Run the balance check immediately before launching.

How to Check If Your Token Actually Landed

The Recovery Process — Step by Step

How to Prevent This in Future Launches