Co-location for Solana Trading: A Practical Latency Guide
How physical placement affects Solana read and send paths, what co-location means, and how to benchmark regions, routing, and tail latency without fooling yourself.
Rrpc edge Team·Jul 22, 2026·11 min read
Frequently asked questions
What does co-location mean for Solana trading?
Co-location means placing the latency-critical parts of a trading system physically and topologically close to the Solana infrastructure they communicate with. That may include shred sources, RPC or gRPC nodes, staked validators, transaction relays, and the Jito Block Engine. A city label alone does not prove a short network path.
How much latency does co-location save?
There is no universal number. Savings depend on the original and new paths, carrier routing, congestion, server processing, and the leaders involved. Measure the exact read and send paths at p50, p95, and p99 under representative load.
Is ping enough to choose a Solana RPC region?
No. Ping measures ICMP round-trip behavior to one host. It does not measure shred arrival, gRPC delivery, RPC processing, transaction submission, leader reachability, or landing. Use ping and traceroute for diagnosis, then benchmark application-level outcomes.
Do I need bare metal for a Solana trading bot?
Not for every workload. Bare metal becomes valuable when shared CPU, virtualization, noisy neighbors, NIC queues, or throttling move tail latency. Start with measured requirements, then choose dedicated hardware when p99 stability and packet processing justify the operational cost.
Should my strategy run in one region or several?
A single region is simpler and can be best for one dominant path. Multiple regions can reduce exposure to leader geography and regional failures, but require state synchronization, duplicate-action prevention, and an explicit ownership rule for each opportunity.
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 service is near relevant stake or data sources
Which validators, how much coverage, whether the path is direct
Co-located with Jito
Short path to a Block Engine endpoint
Region, routing, measured bundle-submit behavior
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?"
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:
Metric
What it tells you
Minimum
The best observed path, often not repeatable
p50
Typical behavior
p95
Frequent tail behavior
p99
The slow edge that can decide contested actions
Loss / timeout rate
Requests or packets that never produced a usable result
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 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.
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:
Workload
Start timestamp
End timestamp
Shred feed
First valid source receipt or common reference
Client receives or decodes the shred
Yellowstone gRPC
Common source event
Client receives matching update
JSON-RPC read
Client sends request
Complete valid response arrives
Transaction sender
Client submits signed bytes
Gateway accepts, then separately first-seen and landed evidence
Jito bundle
Client submits bundle
Block Engine response, then separately bundle outcome
Gateway acknowledgement is not landing. A fast HTTP response proves the gateway accepted work. Landing
requires signature or bundle evidence on the network.
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.
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.
Hold filters, commitment, payload, connection lifecycle, and concurrency constant. Warm persistent
connections before measurement unless connection setup is itself part of the product path.
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.
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.
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.
The clocks must be trustworthy before subtracting timestamps across machines. Without that, keep network
round trips and local processing durations separate.
Physical placement and single tenancy address different problems.
Lever
Primary effect
Physical proximity
Shorter propagation path
Good peering and routing
Fewer detours and less path variance
Dedicated CPU and memory
Less noisy-neighbor compute contention
Dedicated NIC capacity
More predictable packet handling under load
Persistent connections
Less setup work on the hot path
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.
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.
Ingest, strategy, state, and sender live together. It is simple, avoids cross-region coordination, and works
when one location dominates the relevant paths.
One process owns decisions while warm sender agents sit near delivery destinations. The design adds coordination
latency but can shorten the final hop.
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.
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.
Benchmark your workload beside the cluster.
rpc edge provides co-located decoded shreds, Yellowstone gRPC, RPC, dedicated nodes, and a leader-aware transaction sender. Test the path with your filters and traffic shape.
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.
Co-location for Solana Trading: A Practical Latency Guide