When a leader produces a block, they choose which transactions to include and in what order. That choice has value, because the right ordering can capture real profit from things like DEX arbitrage. The name for this profit is MEV: maximum extractable value. Jito is the system most of the Solana network uses to organize how MEV gets captured. This lecture covers MEV in plain terms, then walks through the two things Jito introduced: tips and bundles.

Imagine a user is about to swap 100,000 USDC for SOL on a DEX. Their swap is large enough to move the price by half a percent. If you can spot their pending swap and buy SOL right before them, then sell right after, you pocket the half-percent move. They wanted to trade. You made money from the fact that you knew about their trade and got to choose the order.

That's MEV in one example. The profit comes from controlling transaction ordering. It exists in any system where somebody decides what goes in a block first, second, third. Solana has it just like every other chain does.

The wrinkle is that Solana doesn't have a public mempool. On chains that do, anyone can watch pending transactions and try to front-run them. On Solana, transactions go straight from RPC nodes to leaders via Gulf Stream, with no public waiting room in between. So you can't scan for opportunities from the outside. But the leader still sees every transaction they're about to include and still chooses the order. The MEV is still there. It just goes to whoever has the closest relationship with the leader.

This is the problem Jito was built to organize. Before Jito, MEV on Solana was opaque. Big trading firms ran their own validators or made informal deals with leaders, and ordinary users had no idea their transactions were being reordered around them. Jito turned this into an open market that anyone can participate in, with clear rules.

The simpler half of what Jito introduced is the tip. A tip is a regular SOL transfer to one of eight special accounts that Jito designated. That's it. There's no special instruction, no bundle, no API call. You just add a SystemProgram::transfer to your transaction, sending some lamports to a Jito tip address.

What happens next: leaders running the Jito-Solana validator client watch for these transfers. When they're building a block, they prioritize transactions that include tips, ordered by how much was tipped. Higher tip means earlier inclusion.

The eight tip accounts exist for performance reasons. Solana's runtime serializes transactions that write to the same account, so if every tip went to one account, every tipped transaction in a block would block each other. With eight accounts, Jito-Solana spreads the load. Your client picks one at random for each transaction.

Tips are not the same as priority fees. They live alongside each other:

• Priority fees go to the leader as part of normal fee processing. Set via the ComputeBudget program.
• Jito tips go directly to the leader as a SOL transfer. Recognized only by Jito-Solana leaders.

A transaction can have both. Most production wallets and routers attach both, because together they maximize the chance the transaction lands.

This is the mechanism behind a lot of behavior you've probably seen without knowing why. When Phantom shows you "transaction priority: high" and the swap lands quickly, there's a Jito tip in there. When Jupiter routes a swap and asks if you want "MEV protection," it's adding a tip plus some other tricks. When you read about a wallet's "land rate" improving, the team probably just turned on Jito tips. The tip mechanism is what makes all of this work.

The other half is bundles. A bundle is a small group of up to 5 transactions that the leader commits to including together, in the order you specify. If any transaction in the bundle fails, none of them land. The whole bundle is atomic.

Why does atomicity matter? Because some operations only make sense as a sequence. A classic example: arbitrage between two DEXes. You want to buy a token on one DEX, then sell it on another at a better price. If only the buy lands, you're stuck holding tokens you didn't want. If only the sell lands, you don't have the tokens to sell and the transaction fails. With a bundle, you get all-or-nothing. The two transactions land together, or neither does.

How bundles work mechanically: a searcher, meaning someone running a trading bot, submits the group of transactions to the Jito block engine, which is an off-chain service that runs an auction. Bundles compete against each other for the same slot. The block engine picks winners based on tip size, simulates them to make sure they'd succeed, and forwards the winning bundles to the current leader. The leader, running Jito-Solana, places them in the block.

The tip works the same way as for single transactions: a SOL transfer to one of those eight tip accounts, included as one of the transactions in the bundle. If the bundle lands, the leader collects the tip. If the bundle fails or doesn't win the auction, no tip is paid.

Two things to know about bundles:

They're submitted to the block engine rather than to RPC nodes. The block engine has its own API endpoint that searchers use directly. Regular wallets and applications don't talk to it.

The order is fixed. When you submit a bundle, you specify the exact order the transactions should appear in. The leader respects that order. This is what makes patterns like "do my buy right before this user's swap" possible.

You probably won't submit a bundle yourself. Bundles are mostly used by trading firms and MEV bots. But Jito affects every Solana developer, because tips have become the standard way transactions get prioritized on the network.

Your users' transactions need tips to land reliably during busy periods. When the network is calm, a normal transaction with a small priority fee lands easily. When the network is busy, transactions without tips often get dropped while tipped ones go through. If you ship a frontend that submits user transactions, you probably want to attach a Jito tip. Most wallet SDKs and transaction-building libraries support this directly.

Your users get protected from MEV through Jito. When a user does a large swap on a DEX, MEV bots want to sandwich them. The defense is to route the user's transaction through Jito, often as part of a bundle that includes a "protection" component preventing other transactions from being inserted nearby. Aggregators like Jupiter do this automatically when MEV protection is enabled. The user pays a small tip and gets a fair price.

You don't have to integrate any of this directly. Most developers get it for free by using a wallet adapter or aggregator that already handles tips internally. But knowing the mechanism is what makes you able to debug "why isn't my transaction landing" and "why did my user get a worse price than expected." The answer to both involves Jito, and now you know what to look for.