If you've used any Solana trading bot in the last year, you've seen the "Jito tip" setting. Maybe you set it to 0.001 SOL and never thought about it again. Maybe you've noticed that some of your trades land instantly while others fail repeatedly. Maybe you've wondered why your snipe was too slow even though you clicked the button within seconds of a token launch.
The answer to all of this is bundles — and understanding them is the difference between being a competitive Solana trader and being perpetually late to the trade.
This guide explains exactly what Jito bundles are, how they work, why they matter, and how to use them effectively.
The Problem Bundles Solve
Before Jito, Solana's transaction ordering was chaotic. When you submitted a transaction, it went to the current block leader (validator), who included it in the block according to their own ordering logic. There was no transparent way to ensure your transaction would be included quickly or in a specific order.
This created two major problems:
Problem 1: Spam Wars
Traders who wanted priority would submit the same transaction dozens or hundreds of times, hoping one copy would land early in the block. This "spam to win" approach congested the network, drove up costs for everyone, and still didn't guarantee execution.
During memecoin launches or high-volatility events, the network would become nearly unusable as bots flooded it with duplicate transactions.
Problem 2: Unstructured MEV
Validators had the power to reorder transactions within their blocks. Some exploited this to extract MEV (Maximal Extractable Value) — inserting their own trades before or after user transactions to profit from price movements. This happened without transparency and disproportionately hurt regular traders.
Jito created a structured alternative: an auction system where traders can bid for transaction priority using tips, and groups of transactions can be submitted as atomic bundles.
What Is a Jito Bundle?
A bundle is a group of up to five Solana transactions that are submitted together as a single unit. The key properties of a bundle:
Atomic Execution
All transactions in a bundle either execute together, in order, or none of them execute. There's no partial execution. If transaction 3 of 5 fails, the entire bundle is rejected.
This atomicity is extremely powerful. It allows traders to construct complex strategies that require multiple transactions to happen in a specific sequence, with the guarantee that they won't get partially executed (which could leave funds in a vulnerable state).
Ordered Execution
Transactions within a bundle execute in the exact order they're submitted. Transaction 1 runs before transaction 2, which runs before transaction 3, and so on. This ordering guarantee is critical for strategies that depend on state changes from previous transactions.
Priority via Tips
Bundles include a Jito tip — a payment in SOL to the validator for including the bundle in their block. Higher tips get priority over lower tips. The tip acts as an auction bid: you're competing against other bundles for block space and ordering position.
Tips are paid to the validator through Jito's tip program, separate from Solana's normal priority fee mechanism. The validator receives the tip only if the bundle is successfully included.
How Does the Jito Tip Auction Work?
Understanding the tip auction is essential for setting competitive tips without overpaying.
The Auction Process
- Submission: Traders submit bundles to Jito's block engine (a specialized transaction relay service)
- Collection: The block engine collects all submitted bundles during a brief auction window
- Ranking: Bundles are ranked by tip amount (highest tip first)
- Inclusion: The current block leader (validator) includes the highest-tipped bundles at the top of their block, followed by lower-tipped bundles, followed by regular (non-bundled) transactions
- Settlement: Tips are transferred to the validator only upon successful bundle inclusion
What Makes a Good Tip?
Tip requirements are dynamic and depend on:
- Network congestion: During busy periods (launches, market moves), competitive tips increase dramatically
- Block space competition: If many traders are bundling, higher tips are needed to outbid competitors
- Time sensitivity: If your trade is time-sensitive (sniping a launch), you need a higher tip than a casual swap
- Transaction value: Tips should be proportional to the value of your trade. A 0.01 SOL tip on a 100 SOL trade is reasonable; the same tip on a 0.1 SOL trade doesn't make sense
Typical Tip Ranges
| Scenario | Typical Tip Range |
|---|
| Normal swap (no urgency) | 0.0001 - 0.001 SOL |
| Active trading (some priority) | 0.001 - 0.005 SOL |
| Token launch snipe | 0.01 - 0.1 SOL |
| High-priority snipe (competitive) | 0.1 - 1+ SOL |
| Bundle attack / MEV extraction | Variable (profit-dependent) |
Most trading bots let you set a default tip and optionally increase it for specific trades. The right tip depends on context — there's no universal "correct" amount.
How Traders Use Bundles
Bundles aren't just for priority. Their atomic, ordered nature enables specific trading strategies that aren't possible with regular transactions.
Token Launch Sniping
The most common use of bundles is sniping new token launches. When a token launches on Pump.fun or Raydium, traders compete to be among the first buyers. A snipe bundle typically contains:
- A transaction to buy the token immediately after the liquidity pool is created
- (Optional) A transaction to set a sell order or take-profit condition
Traders using Axiom, Trojan, Photon, and other trading bots can configure their snipe parameters in advance. When the launch is detected, the bot constructs and submits a bundle with the appropriate tip to compete for early inclusion.
The tip is the primary competitive variable. A trader with a 0.1 SOL tip will beat a trader with a 0.01 SOL tip, regardless of who "clicked first." Speed still matters (you need to detect the launch quickly), but the tip determines ordering among simultaneous submissions.
Token Launching with Bundles
On the other side of the equation, token launchers use bundles to coordinate their launch. A launch bundle might include:
- Create the token
- Add initial liquidity to the pool
- Buy a portion of the supply from the pool (the "dev buy" or "snipe your own launch")
By bundling these transactions, the launcher ensures that no one can buy the token between liquidity addition and the launcher's own purchase. Without bundles, bots would buy in the gap between steps 2 and 3, front-running the launcher.
This is why you'll often see the first buy on a new token coming from the deployer's own wallet — they bundled their buy with the launch to guarantee first entry.
Sandwich Attacks (MEV Extraction)
This is the adversarial use of bundles. A sandwich attack works like this:
- A bot detects a pending large swap (say, buying 10 SOL of Token X)
- The bot constructs a bundle:
- Transaction 1: Buy Token X (front-run)
- Transaction 2: The victim's original swap (which now executes at a worse price because the bot's buy pushed the price up)
- Transaction 3: Sell Token X (back-run, profiting from the price impact)
- The bundle is submitted with a tip that ensures inclusion in the correct order
The victim gets a worse price, and the bot captures the difference. This is the most common form of MEV on Solana.
Bots use bundles to execute atomic arbitrage across multiple DEXs. If SOL/USDC is priced differently on Raydium vs. Orca, a bot can bundle:
- Buy SOL on the cheaper DEX
- Sell SOL on the more expensive DEX
The atomicity ensures the bot doesn't get stuck with a partial position if one leg fails.
