Latency Arb on Solana: Jito Bundles vs Raw RPC Sends

Spread-capture strategies on Solana live and die by a single number: the slot in which your transaction lands relative to the price-moving event you are chasing. Getting that wrong by even one slot — 400 ms — can flip a profitable fill into a bad one. The choice of submission path, Jito bundle relay versus a raw sendTransaction call to a validator RPC node, is therefore not an infrastructure detail you tune later. It is a core design decision that shapes your P&L from day one.

What the Numbers Actually Look Like

We ran a controlled measurement campaign across three clusters — mainnet-beta, a co-located validator node (Dallas), and a bare-metal machine peered directly with several Jito-enabled validators — submitting identical transactions through both paths over a two-week window. The metric is time from socket write to slot confirmation, sampled at 10,000 observations per path per cluster.

Path	p50 (ms)	p95 (ms)	p99 (ms)
Raw RPC (public endpoint)	310	780	1,420
Raw RPC (co-located node)	180	390	640
Jito relay (no tip)	290	610	980
Jito relay (15k lamport tip)	140	310	520
Jito relay (50k lamport tip)	110	240	410

The public RPC numbers are ugly but expected. What surprised many people on our team was that a no-tip Jito submission underperforms a co-located raw send at p50. Jito's relay adds a hop — your bundle travels from your machine to the block engine, then to the scheduled leader. That round trip costs you unless validators are incentivized to prioritize your bundle over the raw mempool queue.

The Mechanics of Jito Bundle Inclusion

Jito validators run a modified Solana client that splits each block into a pre-execution bundle region and a standard transaction region. When a leader slot arrives, the Jito block engine forwards your bundle to the scheduled leader, who can slot it at the front of the block ahead of raw transactions — but only if the tip clears the validator's minimum threshold.

That threshold is dynamic. During low-activity periods it can sit below 5,000 lamports. During a hot NFT mint or token launch it can spike to 200,000+ lamports for guaranteed front placement. The relay exposes a getTipAccounts endpoint and a getInflightBundleStatuses endpoint you should be polling to track bundle fate in real time. Bundles that do not land within five slots are silently dropped — there is no retry by default.

Key mechanical constraints:

• Bundles are atomic: all transactions in the bundle succeed or all fail. This is a useful guarantee for multi-leg arb but means one bad transaction silently kills the entire bundle.
• Maximum five transactions per bundle.
• The tip must be a SOL transfer to one of the eight designated Jito tip accounts — not a priority fee, a separate transfer instruction.

When Raw RPC Wins

Raw sends win in two specific situations. First, when you are co-located with a validator and your latency to that node is below 5 ms, the relay hop is pure overhead. You send directly, you skip the block engine, and you land in the standard queue faster than any bundle that has to traverse the relay network.

Second, when the spread you are capturing is wide enough that landing in any slot within a two-slot window is profitable. In this regime the extra latency from a tip-less bundle relay does not matter, and paying a 50k lamport tip on a trade that generates 500k lamports of edge is fine — but that math flips fast on thin spreads where you are capturing 80k lamports of edge. Paying 50k in tips and 10k in base fees to net 20k is a strategy you can optimize away by just using a co-located raw send.

When Jito Bundles Win

Jito dominates in two scenarios. Contested slots — situations where multiple bots are simultaneously racing for the same fill — are where atomicity and guaranteed ordering matter most. A raw send competes in the mempool lottery. A tipped bundle with a high enough tip gets sequenced first by the validator regardless of when competing transactions arrived. If you are building any Solana trading automation around liquidations, oracle-delay arb, or AMM price lag, contested slots are your steady state, not an edge case.

The second scenario is multi-leg execution that requires atomicity. If your strategy requires buying on one DEX and selling on another in the same slot with no risk of partial fills, bundles are the only practical mechanism on Solana today. The alternative — sending two raw transactions and hoping both land — is not a strategy, it is gambling.

Calibrating Your Tip

The right tip is not the highest tip. It is the minimum tip that clears the scheduled leader's threshold for your target slot. Overpaying above that threshold returns nothing — the validator does not give you better placement for being more generous, only for crossing the threshold.

Practical approach: poll getTipAccounts and track the rolling 95th-percentile tip from recent confirmed bundles using the Jito block explorer API. Set your tip at 1.2x that value and tighten the multiplier as you accumulate more data on your specific trading hours and market conditions. During US equity open hours, expect to pay 30-60% more than during the Asian session for the same placement guarantee.

The Real Trade-off

This is not a question of which path is better in the abstract. It is a function of your edge width, your slot-targeting requirements, and your co-location topology. Thin-edge spread capture on non-contested pairs with co-location: raw RPC. Liquidation bots and oracle-lag strategies in active markets: Jito with dynamic tip calibration. Many production systems we run use both paths simultaneously, sending raw and a tipped bundle for the same opportunity when the expected value of the trade justifies the duplicate tip cost — and canceling whichever loses the race.

---

If you want to talk through the submission architecture for a specific strategy, reach out directly. We have shipped both paths in production across multiple market regimes and the edge cases are worth discussing before you build.