Jito Bundles and Private Mempool: MEV Bot Infrastructure on Solana

Solana has no mempool in the Ethereum sense — transactions flow peer-to-peer directly to validators, which makes front-running harder but also means the standard MEV playbook doesn't translate cleanly. Jito Labs changed the calculus in 2022 by shipping a modified validator client with a block engine and an off-chain bundle auction sitting in front of it. If you're running arbitrage or liquidation bots on Solana, understanding exactly how that pipeline works determines whether your bundles land or quietly get dropped on the floor.

How the Block Engine Fits Into Slot Construction

Jito-Solana validators run a forked client that exposes a gRPC endpoint called the block engine. When a validator using this client becomes the leader, it allocates a portion of its block-building time — roughly the first 400 ms of a 400 ms slot — to receiving bundles from the block engine rather than pulling exclusively from the standard transaction stream.

The block engine collects bundles from searchers, runs a tip-weighted auction, selects winners, and forwards the ordered set of transactions to the leader. Non-Jito validators ignore the block engine entirely and process the gossip queue normally. This means your bundle's fate depends on who the leader is for the target slot: Jito validators have historically accounted for around 60–70% of stake weight, so your success rate has a hard ceiling before you've written a line of code.

Anatomy of a Bundle

A bundle is between 1 and 5 transactions that land atomically and in order. If any transaction in the bundle fails, the entire bundle is dropped — no partial execution, no fees paid. This atomicity guarantee is the core value proposition: you can express "these three transactions must execute as a unit or not at all" without cross-program coordination.

The tip transaction is almost always the last instruction in the bundle's final transaction, sending SOL to one of the eight Jito tip accounts. The accounts rotate; pull the current set from the Jito SDK rather than hardcoding them. Tip amounts are denominated in lamports and get included in the block engine's comparison across competing bundles — it's a pure priority auction on tip value, not on compute units or base fee.

Tip Selection Without Leaving Money on the Table

Tip selection is where most implementations either over-pay or lose. A few concrete heuristics from running this in production:

• Baseline from the tip percentile API. Jito exposes a getTipAccounts endpoint and a separate percentile feed. Poll the 50th and 75th percentile over the last 20 slots before submitting. For low-latency arb, targeting p75 is a reasonable floor during normal market conditions.
• Scale with opportunity size, not arbitrarily. If the expected gross PnL on a liquidation is 0.8 SOL, you can afford to tip 0.15–0.2 SOL and still come out well. Hard-coding a flat 0.001 SOL tip loses you most slots during competitive moments.
• Don't tip what you don't win. Because failed bundles pay no fee, there's no cost to losing an auction beyond the round-trip latency. This is different from EVM where a failed transaction still burns gas. On Solana with Jito, aggressive tip sizing is lower-risk than it looks.
• Time-decay your tip. If you resend a bundle across multiple upcoming leader slots, consider slightly increasing the tip each retry rather than sending the same value repeatedly. Stale opportunities that have been visible for 200+ ms are worth less; bid accordingly.

Monitoring Bundle Landing and Rejection

Jito returns a bundleId on submission. You can poll getBundleStatuses via the block engine RPC to check outcomes: Invalid, Pending, Failed, or Landed. Failed means the bundle was selected but a transaction within it reverted. Invalid usually means you hit a non-Jito leader slot, the bundle TTL expired (default is 5 slots), or a transaction signature was malformed.

Track your rejection reasons explicitly. A high Invalid rate usually points to slot targeting — you're consistently hitting non-Jito leaders or your bundle is stale when it arrives. A high Failed rate means a state race: something between when you built the bundle and when it executed changed the on-chain state your transactions assumed. Common culprits are stale price oracle reads and account lamport assumptions in liquidation checks.

Build a rolling dashboard that shows landed / total submitted per hour, segmented by rejection reason. If your landed rate drops below 40% for more than a few minutes during active market hours, that's a signal — usually a competitor has raised the tip floor substantially, or you've hit a cluster of non-Jito leader slots.

Latency Is Still Load-Bearing

Bundle submission latency matters even though Jito's auction is tip-weighted rather than FIFO. If your bundle arrives after the block engine has already closed its collection window for a given leader slot, it misses entirely regardless of tip. The block engine is co-located with Jito validator infrastructure, with primary nodes in Amsterdam, New York, and Tokyo at the time of writing.

Co-locate your bundle submission node geographically near the block engine endpoint you're targeting. The difference between 8 ms and 80 ms round-trip to the block engine is meaningful when you're competing across a 400 ms slot window. Use the Jito SDK's sendBundle with connection keep-alive; establishing a fresh TLS handshake per bundle under load is a silent performance drain.

Simulating Before You Submit

Submitting a bundle cold and hoping it lands is how you learn expensive lessons. Simulate each transaction individually against simulateTransaction before assembling the bundle, then build a local simulation pass that checks the sequential state mutation: does transaction 2 depend on an account state that transaction 1 modifies? The block engine does not simulate bundles for you before forwarding them to the leader.

If your stack includes a local validator fork for pre-flight checks, snapshot the cluster state as close to submission time as possible. Stale snapshots more than two slots old are often worse than no simulation at all — they give you false confidence on accounts with high write frequency.

---

If you're building competitive MEV infrastructure on Solana and want it running reliably in production rather than as a weekend experiment, talk to the team at TierZero — we've shipped this stack and we know where the sharp edges are.