Jito MEV uses Block Engine bundles to coordinate atomic Solana execution

Updated: 17 Sep 2026

Jito MEV routes fully signed Solana transactions through the Block Engine as an ordered bundle competing for a Jito-Solana leader’s blockspace. If included through the bundle path, the transactions execute sequentially within one slot and commit only when every transaction succeeds. Submission does not promise inclusion: the bundle must remain valid, satisfy its state assumptions, carry an adequate Jito tip and reach a compatible leader. A returned bundle ID proves receipt, not execution. Use a bundle when dependent steps need one execution boundary. Confirm completion with both landed signatures and the intended on-chain state.

Bottom line: Bundle receipt proves submission, while landed transactions and the intended account state prove successful atomic execution.

Bundle composition defines the commitment boundary

Up to five fully signed transactions can share one bundle. Each transaction still follows Solana’s normal validity rules, including signature checks, a usable recent blockhash, account access rules, compute limits and sufficient balances. Their listed order matters. A later transaction may rely on state an earlier transaction creates, provided the programs and accounts support that dependency.

Bundling is most useful when several transactions form one indivisible operation but cannot fit inside a single Solana transaction. Atomic arbitrage is a common fit because every leg must succeed together. A bundle adds little when the transactions are independent. One invalid or failed member prevents the whole group from committing through the bundle path, so unnecessary members enlarge the failure surface.

Submission produces a receipt before execution

The normal path starts with complete transaction messages, all required signatures and an intentional order. Clients generally encode those signed transactions in base64 and submit them through sendBundle. The Block Engine relays the transactions without rewriting them. It cannot repair a missing signer, stale blockhash, incorrect account list or program error.

A successful RPC response returns a bundle ID. That response establishes the submitted object’s identity and shows the service received it. It does not show the bundle won an auction, reached a leader or committed on-chain. Simulation before submission can catch deterministic failures against the simulated state, but state may change before execution.

Keep the bundle ID beside every transaction signature. Those identifiers support different checks later and should not be treated as interchangeable proof.

Local auctions compare conflicting account access

The Block Engine does not place every bundle into one simple queue. It groups submissions according to their account locking patterns. Bundles with conflicting read and write access compete in the same local auction, while nonconflicting work can compete separately. This design uses Solana’s parallel execution model instead of forcing unrelated state access into a single ordering contest.

Within an auction, the engine evaluates valid combinations under available compute limits and ranks bids by the tip relative to requested compute. A large gross tip can therefore be less efficient than another bid consuming fewer requested compute units. Selection also depends on competing bundles, shared accounts and the state available during simulation.

The auction chooses a candidate combination for a compatible leader. It does not turn the bid into a commitment from the Solana cluster.

What does atomic execution actually guarantee?

A Jito bundle included through the Block Engine path executes in the listed order within one slot and commits only if every transaction succeeds. Earlier state changes are visible to later bundle members during that ordered attempt. If any member returns an execution error, the bundle path does not commit the preceding members as isolated successes.

Atomicity covers execution, not economic quality. A bundle can complete successfully while producing an unwanted trade if its instructions accept that state. Programs should encode minimum outputs, expected accounts, balance conditions or other assertions required by the strategy. A profitable simulation also does not guarantee a profitable landing because prices and account state can move before the leader executes the bundle.

Nor does atomicity guarantee selection or finality. Those are separate auction and cluster outcomes.

Jito-Solana leader support completes the route

A winning candidate needs a leader running the Jito-Solana client because that client understands the bundle path supplied by the Block Engine. The engine forwards selected bundles to that leader for inclusion. A Jito tip does not create the same priority with a validator outside this path, so leader compatibility is part of the submission decision.

Timing remains important after a valid construction. Recent blockhashes expire, account state changes and a targeted opportunity may disappear. Low latency improves the chance a fresh bundle reaches the relevant auction, yet speed cannot overcome a losing bid or a failed assertion. Rebuilding with fresh state may require new transaction messages and signatures; resending stale bytes does not restore validity.

Leader support is necessary for this route, but the cluster still decides whether the resulting slot survives and reaches the chosen commitment level.

Tips price the bundle auction

The bundle API currently enforces a minimum Jito tip of 1,000 lamports. That amount is an admission floor, not a competitive clearing price. Demand changes with blockspace, account contention and the opportunity other searchers see. A sender can inspect recent landed-tip information, but a historical percentile does not promise acceptance in the next auction.

The Jito tip and Solana priority fee serve different mechanisms. The tip bids in the Block Engine auction. A priority fee belongs to Solana’s native transaction fee path and does not replace the bundle bid. For sendBundle selection, the Jito tip is the relevant auction payment.

Tip instructions must transfer SOL to a designated tip account. Fetching the allowed accounts avoids relying on a copied address. Placing the tip instruction in the transaction containing the main strategy lets the same failure conditions govern both actions. If space forces a separate tip transaction, state assertions should stop a payment detached from the intended result.

Status methods separate receipt, landing and confirmation

Bundle tracking has two useful views. In-flight status can report a submission as pending, failed, landed or invalid within its five-minute tracking window. A landed result identifies an on-chain appearance, while an invalid result means the service no longer tracks that bundle. Neither a missing response nor an old invalid status alone explains the underlying cause.

The bundle status method can return the included transaction signatures, slot and cluster confirmation state for a processed bundle. These details connect the bundle ID to ordinary Solana evidence. The strongest completion check follows each signature to the required commitment level and then inspects the accounts the operation intended to change.

This distinction prevents a common monitoring error: recording the RPC receipt as success before any transaction has landed. It also avoids treating simulation as completion. Simulation predicts execution against one state snapshot; confirmation records what the cluster accepted.

Skipped slots create an unbundling edge case

A produced block may fail to become part of the cluster’s accepted chain. Transactions observed from that skipped block can be rebroadcast through Solana’s normal banking path. That path does not enforce the bundle’s all-or-nothing rule, so individual transactions may appear outside their original atomic context.

Transaction-level assertions limit the damage from this edge case. Each sensitive instruction should reject an unacceptable account state even if another bundle member is absent. Keeping the tip with the strategy logic also reduces the chance a detached tip succeeds after the intended operation fails. When the tip must stand alone, it needs its own slot, balance or state condition tied to the expected execution.

Atomic bundle semantics are therefore a strong execution property, not a substitute for defensive program logic under rebroadcast conditions.

DontFront adds a separate ordering rule

DontFront constrains where marked transactions can appear inside a Block Engine bundle; it does not change bundle atomicity. An instruction can reference a valid public key beginning with jitodontfront. Mark that account as read-only. The Block Engine then rejects a bundle unless that transaction appears at the front. Multiple protected transactions must remain contiguous there and satisfy the required signer relationship.

View full-size image

This rule applies only inside the Jito Block Engine path. It does not govern transactions sent directly to other validator software and it cannot prevent every form of third-party ordering. The account marker also does not fix broad slippage tolerances or missing program assertions. Those controls remain inside the transaction logic.

View full-size image

Use the rule when front placement is an explicit acceptance condition. Do not interpret its presence as evidence the bundle landed or received favorable execution.

A bundle readiness checklist for a verifiable decision

A bundle is ready only when its dependency, auction path and completion evidence all match the intended operation.

• Dependency: Include only transactions whose success must be coupled, and keep them in the required execution order.
• Validity: Confirm every signature, recent blockhash, account input, compute request and program-level state assertion before submission.
• Auction bid: Fetch a designated tip account and size the Jito tip from live conditions rather than the minimum alone.
• Failure containment: Keep the tip with the main logic where possible and make every member safe against isolated rebroadcast.
• Completion proof: Preserve the bundle ID and signatures, require the chosen commitment level and inspect the expected account state.

Use the bundle path when several dependent actions must share one commit boundary. If the actions can succeed independently, separate transactions avoid turning one failure into a group rejection. Final evidence comes from the confirmed transaction set and the on-chain state the instructions were written to produce, rather than the bid, response or simulation.