How to Size Jito Tips for Maximum Profitable Bundle Inclusion

Bundle inclusion on Solana is a sealed-bid auction where the clearing price shifts every few hundred milliseconds. Get the bid wrong in either direction and you either bleed alpha to the validator or watch your bundle land in the rejection queue. Here is how to model it correctly and automate the decision.

How the Jito Tip Auction Actually Works

Jito-Solana validators run a modified block engine that accepts bundles from searchers via a gRPC stream. Each bundle carries a tip paid to the validator in SOL, transferred via a Jito tip account. The block engine ranks bundles by tip-per-compute-unit and selects a subset that maximises total fees within the block's compute budget.

The key nuance: bundles compete not only against other searchers but against the organic fee market for the remaining block space. When a block is near capacity, even a mid-tier tip can price out your bundle. When the chain is quiet, you can land a bundle for close to the floor — currently around 1,000 lamports, though this floor shifts with validator policy and network upgrades.

Tips are not refunded on failure. If your transaction logic reverts after the tip is committed, you still pay. This makes the tip decision asymmetric: underestimating costs you the slot; overestimating costs you margin on every trade.

Empirical Baseline: What the Auction Clears At

Before writing any formula, pull real data. The Jito block engine exposes landed-bundle tip data through its API, and on-chain you can reconstruct clearing prices from the tip account transfers in each slot. A practical starting point is to sample 5,000 recently landed bundles across a variety of network conditions and compute the following:

• p50 tip: the median clearing price — your floor in moderate conditions
• p80 tip: what you need to hit roughly 80 % inclusion probability
• p95 tip: reserved for latency-sensitive opportunities where missing the slot is catastrophic

In our production data across Q1 2026, the Solana mainnet p50 sat in the range of 50,000–120,000 lamports during US trading hours. Block utilisation above 85 % pushed the p80 roughly 2–3x higher. These numbers are not static — run a rolling 24-hour sample and recompute every few minutes.

The Sizing Formula

A dynamic tip should track three variables: the gross opportunity value (V), the current inclusion probability curve (P), and a competitiveness scalar (C) derived from observed searcher activity.

tip = min(V * margin_cap, P_target_lamports * C)

Where:

• V is the expected gross PnL of the bundle in lamports, estimated before submission
• margin_cap is the maximum fraction of gross PnL you are willing to spend on tip — typically 15–30 % depending on strategy type
• P_target_lamports is the empirically observed tip that achieves your target inclusion percentile
• C is a competitiveness multiplier, starting at 1.0 and rising when you detect competing bundles on the same opportunity

The min() guard prevents you from paying more than your margin cap regardless of how hot the auction gets. If the auction clears above V * margin_cap, the trade is not worth taking — kill the order, do not raise the tip.

Detecting Competing Searchers

The competitiveness scalar C is the hardest part to estimate, but the signal is observable. Watch for these indicators and increase C accordingly:

• Failed bundle rate rising: if your own recent bundles are landing at lower rates than your target percentile, the auction has moved against you
• Mempool duplicate detection: if you see multiple signed transactions targeting the same pool or account within the same slot window, assume at least one other searcher is present
• Block engine latency spikes: unusual latency in the gRPC stream often correlates with high submission volume

A simple implementation: maintain a rolling 60-slot window of your personal inclusion rate. If it drops more than 20 percentage points below your historical baseline, bump C by 1.25. Cap C at 2.0 to prevent runaway tip escalation during adversarial conditions.

Compute Budget Interaction

Tips compete on a per-compute-unit basis, which means your bundle's compute request directly affects its competitive position. A bundle requesting 400,000 CU at a 100,000 lamport tip scores half as well as a 200,000 CU bundle at the same tip. Audit your compute requests ruthlessly: use simulation to find the actual CU consumed and set your request to consumed + a small buffer (we use 5 %), not the default ceiling.

This one optimisation often delivers a 20–40 % effective tip efficiency gain with zero increase in nominal spend. Our trading bot infrastructure applies this at the transaction-building layer before the tip is calculated, so the formula always operates on accurate CU figures.

When to Walk Away

A tip model without a kill condition will eventually destroy your account. Define hard limits:

• If P_target_lamports * C > V * margin_cap, skip the opportunity entirely
• If block utilisation exceeds 95 % for three consecutive slots, pause the strategy — you are in a fee spike event, not a durable market condition
• If your inclusion rate drops below 30 % over a 10-minute window despite tip escalation, halt and audit — you may be racing a well-capitalised searcher with co-location advantages you cannot overcome on tip alone

Profitable MEV is not about winning every auction. It is about winning the auctions where winning is worth it and having the discipline to let the others go.

---

If you want a second opinion on your tip logic or are building bundle infrastructure from scratch, reach out to the TierZero team — we have shipped this in production across multiple Solana strategies and can cut straight to what matters for your specific setup.