Bare Metal Dominates

TeraSwitch Networks hosts ~59% of validators and produces ~59% of leader slots. This is a bare metal game.

Europe Produces Most Blocks

The majority of leader slots are produced in Western Europe (Germany, Netherlands, UK). Amsterdam alone accounts for roughly a quarter of all slots. This challenges the common assumption that Chicago is the optimal Solana colocation.

Sub-Millisecond Latency in Chicago

Our Chicago probe recorded a 965µs (0.965ms) QUIC handshake to a Solana validator, indicating colocation within the same datacenter or network backbone. TeraSwitch has major Chicago presence, and firms co-locating there can achieve near-zero network latency to validators in the same facility.

What These Numbers Are (and Aren't)

These are public-network RTTs to Jito's regional block engines. They tell you where to host if you submit via Jito, and how much network penalty you pay for cross-region submission. They do not measure transaction landing time, bundle auction timing, or end-to-end execution latency — those depend on Jito's internal forwarding, validator acceptance, and the current leader's position in the schedule, none of which are externally measurable.

Jito Isn't an "Extra Hop Tax"

Whether going through Jito is faster or slower than a direct path to the leader depends entirely on what your "direct" path actually looks like. A plain RPCsendTransactionis proxied and rebroadcast, and under congestion can be dropped before inclusion. Solana's Stake-Weighted QoS reserves 80% of leader TPU capacity for staked and trusted peers, so an unprivileged direct sender is not competing on equal footing. Jito's block engine already holds those privileged relationships, which is why in practice Jito can land faster than a non-privileged direct path — even though on paper it adds one network leg.

Three Submission Modes, Three Products

• Jito sendTransaction — single transaction routed through the Jito low-latency path. Comes with MEV protection by default. Useful for general high-priority flow where you want Jito's leader-side advantage without bundle semantics. Spend is usually split between priority fee and Jito tip.
• Jito sendBundle — up to 5 transactions executed atomically and sequentially. For true MEV strategies that depend on multi-tx atomicity. Only the Jito tip matters here; priority fees don't apply.
• bundleOnly=true on sendTransaction — single tx submitted only via the bundle path. Mainly for revert protection, not broadest routing.

Most Sophisticated Flow Races Both Paths

Helius Sender's default mode sends to both Solana validators and Jito simultaneously, explicitly framed as the "maximum inclusion probability" route. HFT firms and searchers with serious infrastructure typically segment flow by strategy — using direct / staked paths for non-MEV single-tx flow, and the Jito path for MEV, atomic, or protected flow — and race both when landing probability matters more than cost. The right question isn't "direct or Jito"; it's "which flow down which path, and when do we fire both."

Infrastructure Overlap With Validators

Jito's regional block engines all run on TeraSwitch bare metal — the same provider that hosts the majority of Solana validators. A host in TeraSwitch Amsterdam can reach both Jito AMS and many Amsterdam validators in the same millisecond range, even though the two paths serve different purposes. This is why geography-level co-location analysis needs to consider both layers together, not just one.

Note on BAM

Jito's Block Assembly Marketplace (BAM) Nodes currently run on the same infrastructure as block engine, so BAM latency is essentially identical to block engine latency from any external probe. We don't measure BAM separately today. Once BAM decentralizes to third-party operators in new providers and regions, we'll revisit.