How to improve your Jito bundle landing rate on Solana: A bot operator's guide (2026)

TL;DR

• Landing rate = auction position × timing × execution validity. All three must be right. A perfect tip on a stale blockhash still fails.
• Tip dynamically, not statically. Competitive tips in 2026 float between 50–70% of expected profit and shift block to block.
• Submission is a routing problem. Multi-relay, multi-region parallel submission beats single-endpoint every time.
• ShredStream buys 50–200ms of earlier state visibility —the difference between detecting inside the slot and next slot.
• Simulate before you submit. Reverted bundles waste tips and drag your rate. simulateBundle catches most failures pre-flight.
• Infrastructure caps your ceiling. Co-location, dedicated nodes, and SWQoS-staked submission paths are where the real spread lives.

‍

Your bundle landing rate is the single number that decides whether your bot makes money. Everything else—strategy quality, signal detection, exit logic—only matters if your bundles actually land. And in 2026, with the Jito-Solana client running under more than 95% of active stake and Jito tips accounting for over 60% of all priority-fee volume on the network, landing rate is a competition you enter on every submission whether you meant to or not.

Here's the uncomfortable truth most operators discover the hard way: you can copy the exact tip strategy of a profitable desk, replicate their bundle structure line for line, and still land at half their rate. The strategy is public. The infrastructure underneath it isn't. This guide walks through both layers—what you can tune in your code today, and the infrastructure decisions that quietly cap your ceiling no matter how good your logic gets.

What "landing rate" actually measures

Before optimizing anything, define the metric precisely. Landing rate is the percentage of submitted bundles that execute on-chain. But that headline number hides three distinct failure modes, and each demands a different fix.

• Auction losses. Your bundle reached the block engine, entered the auction, and lost to a higher bid. This is a tip problem. The block engine runs parallel auctions at 50ms ticks and selects the highest-value combination of bundles that fits the block.
• Timing failures. Your bundle arrived too late for the current leader, or targeted a leader who had already rotated. Jito bundles are only processed when a Jito-Solana leader produces blocks, and the leader schedule is deterministic but unforgiving.
• Execution reverts. Your bundle won the auction but a transaction inside it failed simulation or state assertion. Because bundles are atomic—all five transactions succeed or none do—a single bad assertion kills the whole bundle after you've already competed for it.

Tracking these separately is the first real optimization. An operator losing 40% of bundles to auction losses needs to raise tips; one losing 40% to reverts needs better simulation. Averaging them into a single "landing rate" hides which lever to pull. Instrument your submission pipeline to tag every failure by category before you touch anything else.

Layer 1: Tip calibration—Winning the Auction Without Overpaying

The Jito auction is a first-price sealed-bid mechanism. You bid your tip, and if you win, you pay exactly what you bid. First-price auctions have a well-known property: bidders shade their bids below true value to avoid the winner's curse. Your job is to bid high enough to win but low enough that the strategy stays profitable.

The dynamic tipping principle

Two things define tip dynamics in 2026. First, the auction is continuous and adaptive—tips that worked last week may not work this week, and tips that worked at 3am won't work during a token launch. Second, the competitive tip ceiling has stabilized between 50% and 70% of expected profit. That's what serious searchers actually surrender to win. Pay less and you don't land; pay more and you're running a charity.

The mistake nearly every new operator makes is hardcoding a tip. A static 100,000-lamport tip is simultaneously too high during quiet hours and far too low during congestion. The fix is telemetry-driven dynamic tipping calibrated against live block conditions.

Building a tip estimator

A production tip estimator samples recent tip data and sizes your bid relative to the opportunity:

async function estimateTip(
  expectedProfitLamports: number,
  recentTips: number[],           // tips from recently landed bundles
  competitionLevel: 'low' | 'medium' | 'high'
): Promise<number> {
  const sorted = [...recentTips].sort((a, b) => a - b);
  const p75 = sorted[Math.floor(sorted.length * 0.75)];
 
  const profitCeiling = { low: 0.35, medium: 0.55, high: 0.70 }[competitionLevel];
  const maxTip = Math.floor(expectedProfitLamports * profitCeiling);
 
  const bid = Math.min(Math.floor(p75 * 1.15), maxTip);
  return Math.max(bid, 1000);   // enforce Jito minimum
}

This is deliberately simple. Production systems layer on leader-specific history, time-of-day patterns, and opportunity-type segmentation. But the core discipline—bid off live telemetry, cap against profit—is what separates sustainable operations from ones that either starve or bleed.

Tips versus priority fees

A common confusion: Jito tips and Solana priority fees are not the same thing. Priority fees increase the likelihood the Solana runtime includes your transaction during congestion. Jito tips are bids in the block engine auction that improve your bundle's ranking against competitors. For competitive bundle execution, both matter. Budget for both.

Layer 2: Submission routing—getting to the leader first

Here's where most guides stop and most real edge begins. Submitting a bundle isn't a single API call to a single endpoint. In 2026, production submission is a routing problem.

Why single-endpoint submission underperforms

When you submit to one block engine region, your bundle's fate depends entirely on that region's proximity to the current leader and that single path's health. If the leader is geographically distant, your bundle arrives later than competitors submitting from closer regions. If that endpoint hiccups, you miss the slot entirely.

The production answer is parallel multi-relay, multi-region submission. Submit the same bundle simultaneously to multiple block engine regions and, increasingly, to alternative relays alongside Jito, with raw RPC as a fallback path. The bundle that arrives fastest at the winning leader is the one that counts; the others harmlessly expire.

A parallel submission pattern

const BLOCK_ENGINE_REGIONS = [
  'https://amsterdam.mainnet.block-engine.jito.wtf',
  'https://ny.mainnet.block-engine.jito.wtf',
  'https://frankfurt.mainnet.block-engine.jito.wtf',
  'https://tokyo.mainnet.block-engine.jito.wtf',
];

async function submitBundleParallel(signedBundle: string[]): Promise<string> {
  const submissions = BLOCK_ENGINE_REGIONS.map(region =>
    sendBundle(region, signedBundle).catch(err => {
      logRegionFailure(region, err);
      return null;
    })
  );

  const results = await Promise.allSettled(submissions);

  const accepted = results.find(
    r => r.status === 'fulfilled' && r.value !== null
  );

  if (!accepted) {
    throw new Error('All regions rejected bundle');
  }

  return (accepted as PromiseFulfilledResult<string>).value;
}

Region selection should be leader-aware. Because Solana's leader schedule is deterministic, you can pre-fetch upcoming leaders and weight submission toward the regions closest to whoever produces the next several slots.

Leader-aware timing

A bundle sent into the middle of a leader's slot has less runway than one pre-staged and fired at slot boundary. The disciplined pattern: track current slot height in real time, estimate your node's landing drift, pre-build and pre-sign your bundle during the previous slot, and fire at the start of the target slot. Every millisecond of build time you move off the critical path is a millisecond of extra landing margin.

Layer 3: State visibility—seeing the opportunity first

You can't land a bundle for an opportunity you detected too late. This is the ingestion side of landing rate, and it's where ShredStream earns its keep.

On Solana, blocks are constructed and propagated in fragments called shreds, distributed through the Turbine fanout tree. Standard propagation means you see chain state after it has hopped through several relay layers. ShredStream delivers shreds directly from Jito-connected validators, giving 50–200ms earlier visibility on chain state versus waiting for Turbine.

That window is decisive. 50–200ms is frequently the difference between detecting an opportunity inside the current slot and detecting it a full slot late. In a network with ~400ms slots, a 200ms head start is half a slot of pure advantage.

In 2026, ShredStream has become standard for any infrastructure provider serving latency-sensitive workloads, frequently wired in by default through the Yellowstone gRPC Geyser plugin. The practical stack: ShredStream for sub-slot shred delivery, Yellowstone gRPC for structured account and slot streaming, and processed-commitment reads for the earliest possible state. Together they compress the detect-to-submit cycle that governs how many opportunities you can even compete for.

Layer 4: Execution validity—not wasting tips on reverts

Winning the auction and then reverting is the most expensive failure mode. You paid to compete, tied up the opportunity, and got nothing. Worse, in the case of uncled blocks, bundle transactions can get rebroadcast and land as individual reverted transactions outside bundle atomicity protections—so defensive assertions aren't optional.

Simulate every bundle

Jito-Solana RPC supports simulateBundle, which verifies the full bundle executes successfully before you submit. This catches the majority of execution failures pre-flight: insufficient liquidity, expired routes, failed state assertions. Simulation costs a few milliseconds; a reverted bundle costs your tip and your landing rate.

async function submitWithSimulation(
  connection: Connection,
  bundle: string[]
): Promise<string | null> {
  const sim = await simulateBundle(connection, bundle);
  if (!sim.success) {
    logSimulationFailure(sim.error);   // tag by revert reason
    return null;                       // abort before wasting a tip
  }
  return submitBundleParallel(bundle);
}

Defensive state assertions

Because uncled blocks can cause bundle transactions to be unbundled and rebroadcast, protect yourself with pre- and post-account checks inside your transactions. State assertions that conditionally allow the tip to go through—and that fail cleanly if the expected state has changed—prevent you from paying a tip on a trade that no longer makes sense.

Compute unit discipline

Over-requesting compute units bloats your transactions and can push bundles past block limits during congestion. Simulate to determine actual CU consumption, then set limits precisely. Lean transactions land more reliably and compete more efficiently for block space.

Measuring and Iterating

None of this works without instrumentation. The metrics that matter, tracked continuously:

The workflow is a loop: measure each failure category, identify the dominant one, apply the matching fix, and re-measure. An operator whose losses are mostly auction-driven raises tips and tightens region routing. One whose losses are mostly reverts hardens simulation and assertions. One whose losses are timing-driven invests in ShredStream and leader-aware pre-staging. The single-number landing rate tells you something is wrong; the categorized metrics tell you what.

Where the Real Ceiling Lives

Everything above—dynamic tips, parallel routing, ShredStream ingestion, simulation—is public strategy. Any competent team can implement it. What separates teams that consistently land bundles from teams that don't is rarely the strategy. It's the latency profile of the infrastructure underneath.

The spread is stable and measurable. Bundles submitted from dedicated bare-metal nodes co-located near validator infrastructure, with SWQoS-staked submission paths and multi-region failover, land at materially higher rates than the same bundles submitted through shared, distant, best-effort infrastructure. The tip math changes too: when your submission path stops eating your latency budget, you can win auctions at lower tips because you arrive earlier.

This is the decision that hardcoded tips and clever routing can't overcome. You can optimize every line of your submission code and still lose to a team running the same code on better infrastructure. The auction sorts who lands during congestion, ShredStream determines who sees state first, and both are gated by how close your infrastructure sits to where blocks are actually produced.

RPC Fast operates that layer—dedicated bare-metal Solana nodes co-located with validators, Yellowstone gRPC and Jito ShredStream enabled by default, SWQoS-staked submission paths, and multi-region failover, so the strategy you build on top actually lands. If your bundles are losing to timing you can't explain, the submission path is usually where to look first. rpcfast.com