Co-location for Solana Trading: A Practical Latency Guide

Your code sits between two network legs

A latency-sensitive Solana strategy is a loop:

shred / gRPC / RPC source
          │
          │  read network leg
          ▼
 ingest → decode → decide → sign
          │
          │  send network leg
          ▼
leader TPU / transaction relay / Jito Block Engine

The middle is compute you can profile and refactor. The two outer legs are network paths. Faster parsing does not remove a cross-continent route, and a larger instance does not shorten a fiber path.

Location is therefore an architectural input, not a final tuning step. It determines how soon a strategy can observe an event and how soon its response can reach the infrastructure that may include it.

The complete pipeline is mapped in Building an HFT Data Pipeline on Solana. This guide focuses on measuring and placing the two network legs.

What co-location does and does not mean

The term is used loosely. These arrangements are not equivalent:

A city name is not a topology. Traffic between two servers in the same metro can leave the metro because of carrier policy, peering, or cloud routing. Conversely, a well-peered path between nearby metros may be more stable than a poorly routed path inside one marketing region.

Treat co-location as a testable statement about a specific path.

The useful question is not "Are you co-located?" It is "Which path is shorter, under my workload, at the percentile where I lose fills?"

Why p99 matters more than the best sample

Trading opportunities concentrate around busy moments. Those are also the moments when shared hosts, queues, and network paths are most likely to degrade.

A minimum or average hides that behavior. Record a distribution:

Include load with every number. A 2 ms p50 at one request per second is not evidence for the same path at 10,000 streamed events per second. Include the sample count, time window, client region, server region, payload, concurrency, and commitment level.

RPC Edge publishes benchmark methodology and the tail rather than turning the best observation into a product claim. The DoubleZero placement study is an example: it pairs comparable sends and separates results by leader distance instead of declaring one route universally faster.

Ping is a diagnostic, not a trading benchmark

ping is useful. It tells you whether a host is reachable and gives an ICMP round-trip distribution. It does not exercise the same protocol, server work, or destination as a trading path.

ping -c 200 rpc.example.com
traceroute rpc.example.com

Those results can expose obvious distance, loss, or routing problems. Do not translate them directly into "time to see a transaction" or "time to land."

Application-level measurements should match the job:

Gateway acknowledgement is not landing. A fast HTTP response proves the gateway accepted work. Landing requires signature or bundle evidence on the network.

A paired region benchmark that survives scrutiny

Sequential tests are weak because Solana load and Internet paths change between runs. Use paired requests or sends from the same source process whenever possible.

1. Define the decision

Write the question before collecting data. Examples:

• Which region sees my target program's decoded transactions first?
• Which route produces a higher same-slot landing rate?
• Does dedicated hardware reduce p99 under my peak stream load?

One benchmark should answer one decision.

2. Synchronize clocks

Maintain stable clock synchronization on every machine. Record monotonic durations locally when possible. Wall clocks are still needed to align independent hosts, so track synchronization health and drift.

3. Keep the workload identical

Hold filters, commitment, payload, connection lifecycle, and concurrency constant. Warm persistent connections before measurement unless connection setup is itself part of the product path.

4. Pair observations by identity

Match reads by slot, signature, shred index, or account update. Match sends using a design that avoids double execution. Never broadcast two economically active transaction variants merely to create a chart.

5. Segment the result

Break down by:

• Client and server region
• Leader location or distance bucket
• Time window and congestion regime
• Message type and size
• Shared versus dedicated tenancy
• Success, timeout, and missing-observation class

6. Publish enough context to reproduce it

Keep raw timestamps or an anonymized result set. Report negative findings. If the advantage disappears for nearby leaders or reverses in one region, that belongs in the conclusion.

Separate network time from server time

An endpoint response combines several stages:

DNS + connection setup + network to server
+ queue wait + server processing
+ network back to client
= observed response time

Persistent connections remove most DNS, TCP, TLS, and QUIC setup from the hot path. That is correct for a long-lived trading service, but it must be stated in the methodology.

Server timing can help separate queue and processing work from the wire. Client-side timestamps alone cannot tell whether a p99 spike came from routing, garbage collection, CPU contention, or a provider queue.

Instrument both sides when you control them:

client_send
server_receive
server_work_start
server_work_end
client_receive

The clocks must be trustworthy before subtracting timestamps across machines. Without that, keep network round trips and local processing durations separate.

Dedicated hardware solves variance, not geography

Physical placement and single tenancy address different problems.

A dedicated server in the wrong region still pays for distance. A nearby server with saturated shared resources can still have poor tail latency. Low-latency infrastructure needs both a short path and stable processing.

The Solana Foundation's guide to high-performance validator hardware describes why direct NIC access, CPU pinning, enterprise NVMe, and 10 to 25GbE connectivity matter as Turbine packet rates rise. Those validator requirements do not transfer one-for-one to every bot, but the queueing lesson does: abstraction and contention become visible in the tail.

Read Solana Turbine Explained for the propagation mechanics that turn higher block capacity into more network packet work.

Read placement and send placement may differ

The optimal read region is not automatically the optimal send region.

A shred source may give one metro the earliest view. The current and upcoming leaders may make another route preferable for sending. The Jito path introduces another destination. A globally distributed leader schedule prevents one fixed rack from being nearest to every producer.

Three common designs follow:

One-region system

Ingest, strategy, state, and sender live together. It is simple, avoids cross-region coordination, and works when one location dominates the relevant paths.

Central strategy with regional senders

One process owns decisions while warm sender agents sit near delivery destinations. The design adds coordination latency but can shorten the final hop.

Regional strategy replicas

Each region ingests and can act. Local execution can minimize paths but creates the hardest correctness problem: which replica owns an opportunity, and how do the others avoid duplicate action?

Do not add regions without an ownership protocol. Faster duplicates are still duplicates.

When co-location changes the business outcome

Proximity is valuable when time-to-action changes expected value:

• Arbitrage where a competing transaction closes the spread
• Liquidations with several searchers targeting the same account
• Market making where stale quotes increase adverse selection
• Copy trading where the follower's delay becomes slippage
• Launch detection where the earliest valid observation changes entry price

It is less important for historical analytics, accounting, dashboards, and workflows measured in seconds. A nearby dedicated node can be wasted spend if the application waits on a slow database or a human approval.

Start from the cost of delay, not from an infrastructure fashion.

Production checklist

Before choosing a region or provider:

• Map the read and send destinations separately.
• Ask for facility, routing, source, and tenancy details.
• Measure application outcomes, not only ping.
• Use paired tests over representative time windows.
• Report p50, p95, p99, loss, and timeout rate.
• Segment results by leader distance and congestion.
• Keep connections warm if production keeps them warm.
• Track server processing separately from network time.
• Test peak event rate, not only idle traffic.
• Define multi-region ownership before enabling multiple actors.
• Re-run the benchmark after routing or infrastructure changes.

The takeaway

Physical proximity shortens the two network legs around a Solana trading strategy. It cannot fix slow code, invalid transactions, weak fee policy, or a poor route hidden behind a nearby city label.

Make placement measurable. Name the source and destination, use the real application protocol, publish the load and percentiles, and judge the system by first-seen and landing outcomes. Once compute is lean, the remaining latency budget lives in topology.