How Jito's Block Engine Auction Actually Works

What actually gets submitted

When you send a transaction to a normal Solana RPC node, it goes into gossip and hopes to get picked up by whichever validator is leader. Jito's Block Engine skips that lottery entirely. You submit a bundle — an ordered list of up to 5 transactions that either land atomically together or not at all — directly to a Jito block engine endpoint, and it competes in a private auction for inclusion at the top of the next block.

That atomicity is the whole point. If you're backrunning a large swap or sandwiching a mispriced pool, you need your setup transaction, the target transaction (or its equivalent), and your cleanup transaction to execute in a fixed sequence with no one able to slip in between. Bundles guarantee ordering. Regular transactions, submitted independently, guarantee nothing — another searcher's higher-priority-fee tx can land between yours and break the whole sequence.

A bundle is really just a JSON-RPC payload: an array of base58 or base64-encoded signed transactions, submitted via sendBundle. The last transaction in the bundle typically carries a tip instruction — a plain SOL transfer to one of eight designated Jito tip accounts. That tip is your bid.

Inside the block engine auction

The block engine is a separate piece of infrastructure from the validator client. It's an off-chain service, run by Jito Labs (and now increasingly self-hosted or regionally distributed), that:

1. Receives bundles from searchers over gRPC
2. Simulates each bundle against current state to check it actually executes and doesn't revert
3. Runs a continuous auction across all pending bundles
4. Streams the winning bundles to the current leader's relayer just before their slot

The auction isn't a single event at the start of a slot — it runs continuously, re-ranking bundles as new ones arrive and as the current leader's slot window ticks down. Ordering within the winning set is primarily by tip size, denominated in lamports, with simulation success as a hard filter. A bundle that fails simulation (state changed underneath it, a required account got locked by something else) gets dropped before it ever reaches ranking.

There's a nuance a lot of people miss: the auction happens per-region, not globally. Jito runs block engines in Amsterdam, Frankfurt, New York, Tokyo, and a couple of other locations. Your bundle only competes against other bundles submitted to the same regional endpoint that are targeting the same upcoming leader. Submit to the wrong region relative to your target validator's physical location and you're adding round-trip latency that no tip size can compensate for — this is a mistake we see constantly when reviewing searcher infra during MEV bot engagements.

Tip calculation and ordering

Tips aren't fixed-price. There's no minimum tip enforced by the protocol (a few validators run local minimums via jito-relayer config, usually tiny), so in practice the market sets the floor. During normal conditions on a liquid pair, a profitable backrun might tip 5-15% of expected profit. During a hot NFT mint or a big liquidation cascade, tips spike because dozens of searchers are bidding on the same opportunity simultaneously — this is functionally a sealed-bid, pay-what-you-bid auction repeated every ~400ms slot.

The block engine doesn't just take the single highest-tip bundle. It packs the set of non-conflicting bundles that maximizes total tip revenue for that slot, subject to compute budget limits (48M CU per block, with per-bundle simulation determining actual usage). Two bundles that touch completely different accounts can both land in the same slot even if one tips less, as long as they fit.

Validator selection and the relayer handoff

This part surprises people coming from Ethereum/Flashbots: on Solana, the leader schedule is public and deterministic, published a full epoch (roughly 2-3 days) in advance. You always know exactly which validator will produce block N, four hours from now. There's no PBS-style blind auction across unknown builders — you're bidding to get included in a specific, known validator's block.

Once the auction picks winning bundles, the block engine hands them to the relayer — a component that sits between the block engine and the validator's own TPU (Transaction Processing Unit). The relayer's job is to protect the validator from spam and to forward only auction-approved bundles plus normal gossip traffic during that validator's slot. Validators running Jito-Solana (a patched validator client, not a fork with different consensus rules) opt in to receiving relayer traffic and split tip revenue with the block engine operator — historically an 8-9% Jito fee off the top of tips, rest to the validator and its stakers.

If a validator isn't running the Jito client, none of this applies — your bundle simply never gets a chance at their slot, which is why leader-schedule awareness matters as much as tip sizing.

A worked example

Say a large swap on Raydium is about to move SOL/USDC price by 40 bps. Your bundle:

Tx1: Buy SOL/USDC on Orca at pre-swap price (your capital)
Tx2: [the victim's swap — not yours, just expected to land]
Tx3: Sell SOL/USDC on Orca at post-swap price
Tx4: Tip transfer, 0.015 SOL to tip account

Wait — you can't include someone else's transaction in your bundle without their signature. So in practice this is a backrun, not a sandwich bundle: Tx2 is omitted, and you submit Tx1+Tx3+tip as a bundle that only lands if it's profitable given whatever state exists when it executes, racing to land in the same slot right after the victim's independently-submitted swap. The block engine's simulation step is what makes this safe — if the victim's tx didn't land or landed differently than expected, your bundle fails simulation and gets dropped for free, no wasted signature, no partial execution risk. That safety net is the actual product Jito sells.

Where it breaks down

A few practical gotchas we run into building and auditing this infrastructure:

• Bundle size is capped at 5 transactions. Complex multi-hop strategies sometimes need to be split, which reintroduces atomicity risk between bundles.
• Tip account contention. All searchers tip into the same 8 rotating accounts; heavy bundle volume can cause account-lock contention if you're not reading current tip account state correctly.
• Latency to the block engine matters more than people assume. Comparing bundle-based flow against raw RPC submission is a different latency problem than comparing Yellowstone gRPC streams against polling RPC for data ingestion — but both come down to shaving milliseconds off a 400ms slot budget, and both require colocated or purpose-built data infrastructure.
• Not every profitable opportunity is bundle-shaped. Some strategies, especially on venues with their own matching engines like the mechanics around Hyperliquid's HLP vault, don't route through Jito at all.

If you're weighing Jito against Ethereum-side MEV infra, the auction model differs enough from Flashbots-style bundle auctions that porting a strategy over 1:1 usually loses money in week one — the tip curve, block engine regionality, and public leader schedule all change the math, and we've written more detail on those bundle auction differences for teams migrating strategies cross-chain.

Building or auditing a searcher stack that actually accounts for regional routing, tip curve modeling, and simulation-safe bundle construction is most of the engineering work — if you want that built right the first time, our Solana MEV and arbitrage bot development work starts exactly here.