Jito Block Engine, demystified: bundles, MEV, and what tips actually pay for

Every active Solana builder has tipped Jito at some point. Most don't fully understand what the tip is buying. The Jito Block Engine is the most consequential piece of MEV infrastructure on the chain — by 2026 around 80-88% of staked SOL runs the Jito-Solana validator client and consumes bundles through it.

Here's what it actually does.

The problem it solves

Solana's base protocol has no transaction ordering market. Validators receive transactions, sort them by compute unit price within each write-locked account, and produce blocks. There's no native concept of "execute these three transactions in this order, in this slot, or none of them."

For consumer transactions, you don't need that. For arb, liquidation, sandwich-resistant trading, or any flow where ordering matters more than inclusion, you absolutely do. Jito built the Block Engine to provide that primitive.

The mechanics

Three components:

1. Block Engine — a network of off-chain servers run by Jito Labs. Searchers (anyone, including you) submit bundles here. The Engine simulates them, scores them by tip, and forwards the winners to the current and upcoming leader validators.

2. Jito-Solana validator client — a fork of Agave that knows how to receive bundles from the Block Engine and prepend them to the block it's building. Validators run this fork to capture MEV.

3. Tips — transfers to one of eight known Jito tip accounts, inside a bundle. The validator client routes tips to the block leader and (after Jito's cut) to delegators.

What a bundle is

A bundle is up to 5 ordered transactions with three guarantees:

• Atomicity. Either all transactions land in the same block, in order, or none of them do. No partial execution.
• Top-of-block placement. Bundles land before regular mempool transactions in the block they're included in.
• No public mempool exposure. Bundles go directly to the Block Engine, not to validators' public ingress. No frontrunner can see and copy your tx.

That's the entire product, summarised.

Submitting a bundle

import { Connection, SystemProgram, PublicKey, Transaction, sendAndConfirmTransaction, Keypair } from "@solana/web3.js"

const JITO_TIP_ACCOUNTS = [
  "96gYZGLnJYVFmbjzopPSU6QiEV5fGqZNyN9nmNhvrZU5",
  "HFqU5x63VTqvQss8hp11i4wVV8bD44PvwucfZ2bU7gRe",
  "Cw8CFyM9FkoMi7K7Crf6HNQqf4uEMzpKw6QNghXLvLkY",
  // 8 total — pick one at random per submission for load distribution
]

// 1. Build your transactions normally
const tx1 = /* your buy/swap/whatever */
const tx2 = /* the action that depends on tx1 */

// 2. Add a tip transfer to the LAST transaction in the bundle
const tipIx = SystemProgram.transfer({
  fromPubkey: payer.publicKey,
  toPubkey: new PublicKey(JITO_TIP_ACCOUNTS[Math.floor(Math.random() * JITO_TIP_ACCOUNTS.length)]),
  lamports: 100_000, // 0.0001 SOL — adjust based on current tip floor
})
tx2.add(tipIx)

// 3. Submit to a Block Engine endpoint as a bundle
const bundle = [tx1, tx2].map((t) => t.serialize().toString("base64"))
const res = await fetch("https://mainnet.block-engine.jito.wtf/api/v1/bundles", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "sendBundle",
    params: [bundle, { encoding: "base64" }],
  }),
})
const { result: bundleId } = await res.json()

The tip must be inside the bundle, not a standalone transaction. The Block Engine only routes bundles that include a tip transfer to a known tip account.

What you're actually paying for

Tip economics, concretely:

• You pay: the lamports in the tip transfer.
• The validator gets: a configurable share (typically ~95%), distributed to its delegators.
• Jito Labs gets: a small commission on the remainder.

The tip is what gets your bundle selected by the Block Engine when multiple bundles touch the same accounts. Higher tip = better odds of inclusion in the next slot. Tip floor varies wildly: sub-1000 lamports during quiet periods, 10M+ during a launchpad snipe.

When to use a bundle (and when not to)

Use bundles for:

• Arbitrage between AMMs (atomic buy + sell, or it didn't happen)
• Liquidations (you need first-mover ordering)
• Launchpad snipes / NFT mints with competitive demand
• Multi-step protocol interactions where partial execution is dangerous
• Any flow where you'd be exploited if a frontrunner saw your tx

Skip bundles for:

• A user clicking "send 10 USDC" in a wallet — the overhead isn't worth it
• Cron jobs and recurring tasks where 1-block latency doesn't matter
• Any single-transaction flow with no atomicity requirement — standard CU price submission is simpler and free of Jito-specific plumbing

The 12% gap

~12-20% of Solana stake doesn't run Jito-Solana. Those validators don't process bundles — they only see your bundle if it's forwarded as individual transactions via the public mempool. If a non-Jito validator gets the next slot, your bundle doesn't land that slot.

For high-stakes flows (arb against time-sensitive opportunities), many searchers submit both: a Jito bundle and the same transactions with a high CU price via standard RPC, accepting that one will land and the other will error.

References

• Jito docs — Low-latency transaction send
• Jito — Bundles for searchers
• jito-labs/mev-protos — gRPC protocol definitions

Jito tips aren't a tax — they're an auction. Understanding what they're actually buying (ordering, atomicity, mempool privacy) is the difference between paying for inclusion you didn't need and paying for ordering you genuinely required.