Jito Bundles: atomic execution on Solana

Solana transactions are atomic internally: if any instruction fails, the whole transaction fails. What the base protocol does not give you is atomicity across multiple transactions. If you need “do A, then B, then C — or none of them,” and that will not fit one transaction’s size, CU, or account limits, you need something outside the default mempool path.

Jito Bundles are that something for most of the network today. Searchers, bots, and apps submit an ordered list of up to five transactions to Jito’s Block Engine. When a Jito-Solana leader is building a block, winning bundles can be included and executed sequentially as a unit. Fail one leg, discard the bundle.

Official reference: docs.jito.wtf — Low Latency Transaction Send. Companion on this site: Solana priority fees in 2026: CU price, Jito tips, or both?.

Click to zoom

How the system fits together

Regional Block Engine URLs (Amsterdam, Frankfurt, New York, Tokyo, Salt Lake City, plus a global mainnet endpoint) exist so you can colocate with the next leader’s geography. Mainnet hub: https://mainnet.block-engine.jito.wtf.

What a bundle is (and is not)

• Max 5 transactions, signed by you before submit
• Executed in the order you send them
• All-or-nothing at the bundle layer: if any tx fails, the bundle is rejected — not a partial land
• Must include a tip (min 1000 lamports per docs; market tips are often far higher under load)
• sendBundle returning a bundle_id means received, not landed — poll getBundleStatuses / getInflightBundleStatuses

Docs are explicit: the method relays the bundle to the leader path without rewriting your txs. Expiration after the next Jito leader can still yield a success response with no chain inclusion.

The tip auction

Blockspace and MEV opportunities are scarce. Bundles compete in a priority auction:

• Parallel auctions at roughly 50ms ticks
• Bundles that lock the same accounts in conflicting ways (write-write, read-write) share an auction; non-overlapping work can run in parallel
• Ordering preference uses tip / requested CU efficiency
• Highest-paying combinations go to the validator up to a CU budget

Practical tip rules from Jito’s docs:

• Tip = any instruction (top-level or CPI) that transfers SOL to one of the tip accounts from getTipAccounts
• Prefer a random tip account to reduce contention
• Prefer tip inside the main logic tx, with assertions so the tip only pays if state is as expected
• Standalone tip txs can open uncle bandit risk — treat carefully
• Do not put tip accounts in ALTs
• For sendBundle, the Jito tip is what matters for the auction; for sendTransaction through Jito they often recommend a mix (e.g. priority fee + tip split)
• Tips do nothing useful when the leader is not Jito-Solana — you waste SOL if that is your only path

# Tip accounts (JSON-RPC)
curl https://mainnet.block-engine.jito.wtf/api/v1/getTipAccounts \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getTipAccounts","params":[]}'

# Submit bundle (shape — encode signed txs base64 or base58 per docs)
curl https://mainnet.block-engine.jito.wtf/api/v1/bundles \
  -X POST -H "Content-Type: application/json" \
  -d '{
    "jsonrpc":"2.0","id":1,"method":"sendBundle",
    "params":[[ "<tx1_b64>", "<tx2_b64>", "<tip_tx_b64>" ]]
  }'

Libraries: jito-ts, gRPC via jito-labs/mev-protos. JSON-RPC may require UUID-style auth headers depending on your access tier.

Advantages

Disadvantages and failure modes

When to use bundles

• Multi-leg trade that must not leave intermediate risk if a later leg fails
• Arb or liquidation where profit is tip-funded and speed is the product
• You already lose to searchers on public RPC alone
• You can pay tips and operate monitoring

Skip bundles when one well-built transaction + priority fees is enough, when tips exceed expected edge, or when your users cannot wait on bundle status machinery.

Alternatives

Bundles are not the only way to get reliable execution. Pick by atomicity need, latency need, and cost tolerance.

1. Fit it in one transaction

Best alternative when possible. v0 transactions, ALTs, tighter CU budgets, and fewer accounts often collapse “needs a bundle” into “one atomic tx.” No tip auction, no 5-tx cap politics — just standard Solana atomicity.

2. Priority fees only (CU price)

Set compute unit limit + price; send via normal RPC. Competes in the leader’s fee market without Jito. Good for ordinary app traffic. See priority fees in 2026.

3. Stake-weighted QoS (SWQoS) RPCs

Providers staked with validators get better landing odds for ordinary txs. Complements priority fees; does not give multi-tx atomicity.

4. Dual-route: Jito + public/staked RPC

Common production pattern: submit the same logical intent as a bundle (for Jito leaders) and as a priority-fee tx (for everyone else). Deduplicate on confirmation. Higher complexity, better coverage across the schedule.

5. Jito sendTransaction (single tx, not a multi-tx bundle)

Same Block Engine path, one transaction, tip + optional priority fee split. Landing and MEV-path benefits without multi-leg packaging. Use when you need the pipe, not the five-tx atomicity.

6. Vendor “smart send” / sender APIs

Helius, Triton, and others expose send helpers that blend priority fee estimation, retries, and sometimes Jito under the hood. You trade control for ops simplicity. Still read whether multi-tx atomic bundles are actually exposed or only single-tx acceleration.

7. Accept non-atomic multi-step flows

Design protocols so partial progress is safe: claims, refunds, cranked settle (cranks / TukTuk), idempotent retries. Costs product complexity; removes dependence on a bundle auction.

8. Specialized MEV / private orderflow products

Other relays, RFQ systems, and app-specific sequencers appear and disappear. Evaluate stake coverage, trust model, and failure modes the same way you evaluate Jito — do not assume “private” means “atomic forever.”

Builder checklist

1. Can this be one transaction? If yes, stop.
2. Estimate edge vs tip floor (Jito tip stream / dashboard).
3. Build ≤5 signed txs; tip to a random tip account; no ALT for tip keys.
4. Simulate; assert intermediate state so tips do not pay on garbage.
5. sendBundle → poll statuses → timeout → rebuild blockhash and retip.
6. Dual-route if you need non-Jito leaders.
7. Log bundle ids, tips paid, win rate — treat it as a trading system.

Related

• Priority fees vs Jito tips
• Cron jobs and cranks (incl. TukTuk)
• Jito low-latency docs
• jito.wtf

Summary

Jito Bundles are the practical answer to multi-transaction atomic execution on Solana: up to five ordered txs, all-or-nothing, bid with SOL tips through the Block Engine into Jito-Solana leaders. Advantages are real for MEV and tightly coupled strategies. Costs are also real — tips, rate limits, schedule gaps, and ops. Before you build a bundler, try one-tx design and priority fees; when you need cross-tx atomicity under contention, bundles earn their keep — preferably dual-routed so the rest of the leader schedule still works.