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
    A bundle of Solana transactions locked together racing toward the Jito block engine

    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.

    Balance showing a small Jito tip outweighing overpayment, illustrating dynamic tip bidding

    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

    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