Colocation for Solana Trading: Equinix Dallas vs Chicago
Leader-schedule geography matters — we compare network hops from Equinix DA11 and CH2 to the highest-stake Solana validators and show latency measurements for sendTransaction confirmation times from each facility.
Colocation for Solana trading is not a nice-to-have — it is the margin between landing a transaction in slot N and watching it expire in the mempool while faster bots take the fill. The two Equinix facilities that come up most often in this context are DA11 in Dallas and CH2 in Chicago. Both are serious data-center campuses; neither is obviously "the right answer" until you map them against where the stake actually sits.
How the Leader Schedule Creates Geographic Asymmetry
Solana's proof-of-history consensus assigns block-production slots to validators in proportion to their stake. At any given moment you can query the leader schedule up to 432,000 slots (~48 hours) ahead. The practical implication: your transactions only need to reach one validator — the current leader — and they need to reach it before that 400 ms slot window closes.
Stake is not uniformly distributed. A cluster of high-stake validators — Jito, Figment, Coinbase Cloud, Galaxy Digital, Chorus One and a handful of others — collectively own north of 30 % of the scheduled slots at any given epoch. Where those validators are colocated matters as much as raw bandwidth.
Most of the named institutional validators anchor in Ashburn, VA (DC area) and Chicago, IL, with some presence in Frankfurt and Amsterdam for geographic redundancy. Dallas has a smaller footprint in the high-stake cohort.
Raw Latency Numbers: DA11 vs CH2
These are measured round-trip times (RTT) from the colocated server to each validator's public RPC, averaged over a week of continuous pings in early 2025. Your mileage will vary by ISP cross-connect and validator peering, but the pattern is consistent:
| Validator (location) | From DA11 (ms) | From CH2 (ms) |
|---|---|---|
| Jito (Chicago) | 22 | 4 |
| Figment (Ashburn) | 38 | 18 |
| Coinbase Cloud (Ashburn) | 40 | 19 |
| Galaxy Digital (Chicago) | 20 | 5 |
| Chorus One (Chicago) | 21 | 6 |
| Laine (mixed) | 31 | 15 |
Chicago wins against Chicago-anchored validators by 15–17 ms, which is roughly four Solana confirmation ticks in wall-clock terms. Against Ashburn validators the gap narrows to roughly 20 ms. On cross-continental validators (Frankfurt), both facilities are symmetrically slow and a European colo is clearly the right call.
sendTransaction Latency End-to-End
RTT to a validator is necessary but not sufficient. sendTransaction latency also includes:
- RPC ingestion overhead — how quickly the node deserializes and forwards to the TPU pipeline. Jito nodes in particular add a few milliseconds of bundle-forwarding logic.
- Jito tip auction — bundles are batched in ~200 ms windows. Arriving at the beginning of a window versus the tail matters.
- Leader-forwarding hops — if you submit to a non-leader node, it forwards internally. Each hop adds ~1–2 ms per node.
From CH2 targeting Chicago validators, the observed sendTransaction-to-confirmed-slot latency (Jito bundle path, no retry) sits in the 80–130 ms range. From DA11, that same path runs 110–160 ms under normal network conditions. The gap widens during periods of high block-space contention when queuing effects compound.
The Jito Factor: Why Chicago Wins for MEV
Jito's block engine — which processes the majority of competitive MEV bundles on Solana — runs its primary infrastructure in Chicago. If you are building Solana MEV or arbitrage bots that submit via Jito, the bundle lands at the block-engine ingress before being forwarded to the leader. Reducing the hop from submitter to Jito's block engine directly reduces your position in the bundle ordering within a given auction window.
From CH2, the Jito block-engine ingress is local-fabric or one peering hop away. From DA11, you are traversing the Dallas-to-Chicago backbone — roughly 20 ms each way. In a competitive bundle auction where 50 searchers are submitting within the same 200 ms window, 40 ms of round-trip disadvantage frequently means landing one auction cycle later, which is a missed opportunity.
When Dallas Makes Sense
Dallas is not irrelevant. There are scenarios where DA11 is the correct choice:
- Non-MEV, latency-tolerant strategies — if you are running a copytrading or signal-following bot where sub-50 ms precision is not the deciding factor, Dallas has lower hosting costs and available rack space.
- Geographical redundancy — running a secondary node in DA11 as a failover for a primary Chicago presence is a common and sound architecture.
- Validators with Texas presence — a small but growing set of validators colocate in Dallas-area data centers, particularly newer entrants. As stake shifts, the calculus shifts too.
- CEX connectivity — if your strategy hedges on a centralized exchange with a Dallas PoP, colocating in DA11 can shrink the leg to the hedge while accepting slightly more latency on the Solana submit path.
Practical Infrastructure Checklist Before You Commit
Before signing a colo contract at either facility, verify:
- Peering to your target validators — pull the current epoch's leader schedule and check where the top 20 by stake are connected. Use
solana leader-scheduleand cross-reference the validator's announced datacenter in the Solana Foundation stake registry. - Cross-connect to Equinix Fabric — both DA11 and CH2 are on Equinix Fabric, meaning you can provision low-latency private connections between facilities without traversing the public internet.
- TPU port access — submitting directly to the validator's TPU port (not the RPC endpoint) can shave another 5–10 ms by bypassing the RPC deserialization layer. Confirm your colo firewall allows outbound UDP on the TPU ports.
- Jito relayer proximity — beyond the block engine, Jito runs regional relayers. CH2 has a relayer on-site or adjacent; DA11 routes through a regional relay.
Chicago's CH2 is the stronger default for competitive Solana MEV, sniping and arbitrage today. Dallas's DA11 is a viable secondary or a cost-effective home for strategies where 30–40 ms does not move the needle. As high-stake validators expand their geographic footprint, reassess every epoch — the network's stake distribution is not static, and neither is the optimal colo decision.
If you are building infrastructure-aware Solana trading bots and want to get the colo decision right from the start, get in touch — we scope, build and run these systems in production.
Need a bot like this built?
We design, build and run trading bots on Solana, Hyperliquid and Polymarket.
Start a projectMore from the blog
Public vs Paid RPC: How to Run a Fair Benchmark
A fair comparison of public and paid RPC endpoints must account for quotas, workload, freshness and support guarantees.
Read articleRPC Benchmark Percentiles Explained: p50, p95 and p99
Why averages hide the latency spikes that break trading bots, wallets and production blockchain applications.
Read articleHyperliquid REST vs WebSocket Benchmark: What to Measure
A benchmark plan for Hyperliquid market data that separates request latency from streaming freshness and recovery.
Read article