Solana Transaction Senders: Who They Are and Where They Live

With the Solana strategy deployed, the next stage consists of sending your transactions fast and reliably. It is done via the services known as transaction senders: services that take your signed transaction and deliver it to the current leader via their own infrastructure. Below is the list of primary senders, their endpoints' regional locations, and the critical factor that is almost unnoticed but crucial: the city where your server is hosted.

What a transaction sender does in principle

A sender is an intermediary between your bot and the network of validators. Instead of sending the transaction using a public RPC and hoping, you send it to the service that has its own optimized routes to leaders and sometimes even introduces tips or priorities. Despite the differences in implementation, all senders share one feature: your transaction must travel from your server to the endpoint of the sender. This step is under your control and is the only measurable component of your process.

Senders and the locations of their endpoints

Lists of endpoints below were compiled from the official documentation of the service providers and confirmed as of August 2026. The cities listed in bold are the OrbitServers data center locations.

• Jito — The block engine accepts transactions and bundles in regions of Amsterdam, Frankfurt, New York, Salt Lake City, and Tokyo. Note: Jito's ShredStream data feed is a separate service and will shut down on September 5, 2026, see our ShredStream page.

• Helius Sender — Helius's specialized low-latency submission service with regional endpoints in Salt Lake City, Newark, London, Frankfurt, Amsterdam, Singapore, and Tokyo.

• Astralane — A low-latency transaction gateway with edge locations in Amsterdam, Frankfurt, New York, and Los Angeles.

• Nozomi (Temporal) — Direct endpoints in Newark, Pittsburgh, Ashburn, Los Angeles, Frankfurt, Amsterdam, London, Tokyo, and Singapore. Direct hosts should be used for latency-sensitive tasks; Cloudflare-fronted hosts add one more CDN hop.

• bloXroute — The Solana Trader API has regional endpoints in New York, the UK, Germany, Amsterdam, and Tokyo.

• 0slot — Endpoints are named after New York, Frankfurt, Amsterdam, Tokyo, and Los Angeles; however, the hostnames resolve to shared CDN anycast IP addresses, making the measurement of the network distance to the actual servers impossible. While the sender works, because the measurement cannot be made accurately, it is not included in the measured table.

The measured values

An always-updated table with round-trip times from each OrbitServers data center to the regional endpoints of every sender is published on the Solana sender latency benchmark page, together with the methodology and machine-readable feed on /data/sender-latency.json. There are two things that require repetition here:

• The measurement reflects the network latency, in round-trip time, measured with ICMP alone. Landing rates, tipping efficiency, and throughput depend on the sender's internal implementation and on your workload; there is no way to measure these with ping.

• Measurement is done from within our data centers according to a certain schedule, not extracted from the marketing material. In case a sender has endpoints in the same city where your server is hosted, then the latency is typically sub-millisecond; in the case of intercity latency it is tens of milliseconds. This difference explains the reason for choosing a proper city for server hosting.

Region-first, sender-second

There is a noticeable similarity in the endpoint lists: Frankfurt, Amsterdam, New York/Newark, and Tokyo appear in nearly all the lists. Now, the pool of viable senders is concentrated on a small amount of cities, which makes infrastructure decisions much simpler. By placing your server in one of these cities, you place yourself close to all the senders, thus making it possible to change the services depending on their cost and performance characteristics without changing infrastructure.

All OrbitServers bare-metal locations — Frankfurt, Amsterdam, London, New York, and Salt Lake City, are the Jito-connected edge nodes in this cluster. To verify the pre-commitment path, the latency checker can be run from each OrbitServers location to any of these senders or to any custom host of your choice.

Practical guidance on selection

Single-sender strategies: First, choose a sender based on fees, mechanics, and documentation; then, place your server in the city where the sender's endpoint coincides with other infrastructure. The cities with wide coverage are Newark/New York and Frankfurt.

Multi-sender strategies: Place your server in the city that is common to all the senders and then test the paths from the server once it is up. The tail latency (p99) defines the result of the race; for more information see the tail-latency guide.

Shred-driven strategies: The receive side is as critical as the send side. Pick the sender and the shred feed located in the same city; the ShredStream page helps with that part.

Questions and answers

Question: Is the sender choice more important than the server location?

Brief answer: Not usually. Sender fees and mechanics change every month, while the network's physical constraints stay the same: an improperly located server adds tens of milliseconds per submission, no matter which sender is used. Choose a city where the senders and other infrastructure overlap, and keep flexibility about the service you choose.

Question: Why do you measure ping instead of transaction landing rates?

Brief answer: Ping is an objective measurement; landing rate is not. Landing depends on sender's internal mechanics, tipping, and current network condition. The measurements reported are the measurements that could be reliably made and are reported as such.

Question: Could I check my current configuration against these figures?

Brief answer: Yes. Run the latency checker from your current host to the sender you use now, and compare it to the measured values from our locations on the benchmark page. If your path is slower by tens of milliseconds compared to the co-located number, moving the server would be the cheapest latency upgrade available.

Question: Which sender is the best?

Brief answer: There is no universal answer; anyone saying so is selling something. Narrow the candidates by looking into mechanics and fees, benchmark each candidate in your production region with your workload, and revisit periodically, as the ecosystem changes, like Jito's ShredStream shutdown shows.