Jito bundles
Jito bundle arbitrage: land atomic bundles without overpaying for the tip
Jito bundles let a Solana arbitrage bot submit several transactions that are included together, in order, or not at all. That atomicity removes the risk of a half-executed trade, but it introduces a new problem: bidding the right tip. We build Jito bundle arbitrage bots that solve both.
- Execution
- All-or-nothing atomic bundles
- Tips
- Dynamic bidding from expected value
- Submission
- Multi-region block engine endpoints

How Jito bundles change arbitrage on Solana
Without bundles, an arbitrage that needs two or three transactions can be split by a competing trade, leaving you holding inventory you did not want. A Jito bundle is submitted to the block engine as one unit: the validator running the Jito client includes every transaction in the bundle sequentially or drops the whole thing. For an arbitrage bot that means the profit is either realised in full or the attempt costs nothing but the failed simulation.
Bundles also carry a tip paid to the validator. The tip is an auction: the block engine ranks bundles by tip and expected fees, so the bundle that pays more for the same slot generally wins. Paying too little means losing the race; paying too much hands your margin to the validator. The tip strategy is the heart of a Jito arbitrage bot.
Dynamic tip bidding
We size the tip from the simulated expected value of the route, the recent tip distribution observed on the block engine, and how contested the specific pools are. A route with a large expected profit on a quiet pool gets a modest tip; a thin route on a pool where several bots are racing gets a higher share of the expected value or is skipped entirely.
The bot tracks its own inclusion rate per tip bucket and adjusts continuously. You configure the ceilings: a maximum tip as a percentage of expected value, a maximum absolute tip in SOL, and daily budgets per strategy. Everything is visible in Grafana so you can see exactly what you paid to land and what you lost by underbidding.

Bundle assembly and submission
A bundle is built from the simulated route: swap instructions for each leg, the tip transfer to a Jito tip account, compute-unit limits tuned to the actual usage, and address lookup tables to keep transactions small. The bot signs with a hot key that holds working capital only, never your treasury.
Submission goes to several Jito block engine regions at once so the bundle reaches the current leader as early as possible. The bot listens for bundle status, records landed, dropped and expired outcomes, and feeds those results back into the tip model. When the leader is not running the Jito client, the bot can fall back to priority-fee transactions for routes that do not require atomicity.
Why we build it in Rust
Between a Geyser update arriving and a bundle leaving, the bot has to update the pool graph, search routes, simulate, sign and serialise. On a contested opportunity that budget is well under a millisecond. Rust gives us predictable latency with no garbage-collection pauses, and the same language the Solana runtime itself is written in, so instruction encoding and account layouts match exactly.
The Jito bundle layer, the route solver and the risk guards are separate modules with their own tests. Your team can read, extend and audit each of them; the repository is yours at handover with documentation and deployment templates.
FAQ
Jito bundle arbitrage: questions we are asked
Related services
Built on the same engine

Solana MEV bot
Arbitrage, back-running and liquidation bots that compete for block space on Solana.

Rust arbitrage bot
Sub-millisecond engines with in-memory state, simulation and guards, delivered as your repository.

Cost and timeline
What drives the price of a custom bot, what is included, and how payment by milestone works.
Ready to build? Tell us about your strategy.
Tell us about your edge, capital range and infrastructure. We reply with a scoping call, a live demo of bots we have built, and a fixed-scope quotation.
Start your project