Short answer: A bot using Jito bundles submits grouped transactions with an attached tip to Jito’s block engine, competing in an ordering auction rather than relying on standard transaction submission. The core architecture needs bundle construction, tip sizing logic, and integration with Jito’s submission endpoint — distinct from a standard Solana RPC transaction flow.
Bundles are a different submission path entirely
A standard Solana transaction goes to an RPC node and is picked up by whichever validator is producing the current block. A Jito bundle is different: it’s a set of transactions submitted together to Jito’s block engine, with an attached tip, and the bundle is atomic — it either all lands in the target block or none of it does.
This atomicity is part of the appeal for MEV-sensitive strategies: a bot can bundle a setup transaction and its dependent follow-up (for example, a swap and the liquidation it enables) with the guarantee that if the first fails, the second never executes either.
The core components a bot needs
At minimum: transaction construction logic for the strategy itself, bundle assembly that groups the relevant transactions in the right order, tip-sizing logic that estimates a competitive bid without over-tipping, and an integration layer that submits the bundle to Jito’s block engine endpoint rather than a generic RPC.
Tip sizing is the least mechanical part — it requires estimating the expected value of the opportunity in real time and bidding a tip that’s competitive against other searchers without eating the entire margin. This is closer to an auction-strategy problem than a pure engineering one.
What breaks if you treat this like a normal transaction flow
A bot built around simple RPC submission with no bundle awareness will consistently lose ordering races against bundle-submitting competitors in any strategy where transaction ordering affects profitability — arbitrage and liquidations being the clearest examples. The gap isn’t code quality, it’s architecture: without bundle submission, there’s no way to compete for priority in the first place.
This is also where a lot of naive backtests go wrong: a strategy backtested assuming simple sequential execution can look profitable on paper while being structurally unable to capture that profit live, because it never accounts for the ordering auction it would actually be competing in.
Start simple, verify the auction dynamics before scaling
Before building a full bundle-submission pipeline, it’s worth manually submitting a handful of bundles and observing win/loss rates against the tips attached — the auction dynamics on a given strategy type are easier to calibrate empirically than to model from first principles.