How Jito Bundles Work on Solana (Explained for Devs)

Five transactions, one tip, one block. That is a Jito bundle in a sentence. The interesting part is the path those five transactions take, because it is different from how a normal Solana transaction gets into a block, and the differences explain both why bundles are useful for launches and why they sometimes vanish without a trace.

#The normal path, for comparison

When you send an ordinary transaction, your RPC node forwards it to the current leader (the validator producing blocks for this slot) and the next few leaders. The leader's scheduler picks transactions from what it has received, roughly favoring higher priority fees, and packs them into the block. Your transaction lands somewhere in the block, or in a later block, or not at all.

There is no promise about ordering between two transactions you send. Send three buys from three wallets a few milliseconds apart and they can land in any order, in different blocks, with strangers' transactions between them.

#What Jito adds

Jito Labs maintains a modified Solana validator client (Jito-Solana) and runs a service called the block engine. Validators that run the Jito client receive bundles from the block engine, alongside their normal transaction flow.

A bundle is a list of up to 5 signed transactions with two rules attached:

1. Sequential. They execute in exactly the order listed, back to back. No outside transaction can be placed between them.
2. Atomic. Either every transaction succeeds and they all land in the same block, or none of them land.

1. Your app

   signs up to 5 transactions and sends them as one bundle

2. Block engine

   simulates the bundle and drops it if any part fails

3. Auction

   competes with other bundles on tip for space in the block

4. Leader

   a Jito-enabled validator executes it in order, in one block

The block engine is the gatekeeper. It simulates each bundle before forwarding it. If transaction 3 of 5 would fail, for example because a wallet does not have enough SOL or a slippage check would trip, the whole bundle is thrown out at this stage. Nothing reaches the chain, so nothing is charged.

#How the tip works

There is no special "tip field" in a Solana transaction. A Jito tip is a plain SOL transfer to one of a small set of tip accounts that Jito publishes. You put that transfer instruction inside one of the bundle's transactions, usually the last one.

Because the bundle is atomic, the tip has a nice property: it only gets paid if everything lands. A failed or dropped bundle costs you nothing.

When several bundles want space in the same block, the ones paying more for the space they use tend to win. That is the whole auction from your side: tip enough to be competitive at that moment. Jito's minimum and typical tip levels change, so check current figures rather than hardcoding a number. Jito tips explained covers how to choose one.

#What a pump.fun launch bundle contains

Here is how DevBundler uses the 5-transaction limit for a mainnet launch:

Five transactions for up to 11 wallets only works because of an address lookup table. Every pump.fun buy references a long list of accounts, and a Solana transaction can be at most 1232 bytes. The lookup table lets each transaction refer to those accounts by 1-byte indexes instead of full 32-byte addresses. DevBundler creates one reusable table per account, once, for about 0.005 SOL.

Order is not cosmetic here. Each buy pushes the bonding curve price up for the next one, so the wallet in transaction 2 pays less per token than the wallet in transaction 5. Since the bundle runs in a fixed order, a tool can quote every wallet against the price left by the wallets before it, and the quotes will match what lands.

#Why do bundles fail to land?

Bundles fail quietly. There is no on-chain error, because nothing reached the chain. These are the usual reasons:

Most Solana stake runs the Jito client, so the last case is less common than it sounds, but it happens. The fix for most of these is the same: rebuild with a fresh blockhash and send again. DevBundler checks balances, the coin address and the curve before it sends anything, so the first two reasons are usually caught before you spend a lamport.

#What about devnet?

Jito bundles are a mainnet service, so there is nothing to send a bundle to on devnet. A bundler can still run the same launch there by sending the create and the buys one after another. You lose atomicity and same-block ordering, but you get to practice the whole flow with free test SOL. Keep in mind that devnet's pump.fun curve is configured very differently from mainnet, so the percentages you see there will not match a real launch.

#Bundles outside of launches

The same mechanism is useful after launch too. Selling from several wallets is the mirror image of buying from them: you want the sells to land together, in a known order, without outside trades between them. DevBundler's trading bar has a "Bundle" mode (Premium) that packs selected wallets into one Jito bundle in the same block, alongside a "Fast" mode where each wallet sends its own transaction immediately. In Fast mode each wallet's trade stands on its own, so one failure does not hold up the rest; Bundle gives you the ordering and the all-or-nothing behavior.

If you want the deeper reasoning on why the atomic part holds, read why bundled transactions land together. If you want to see a bundle in action on your own coin, the full launch guide walks through every step.