Latency Benchmarking: Solana RPC vs Validator Co-location

Getting your transaction to a Solana leader fast is the entire game for time-sensitive strategies. When I benchmarked three common connectivity tiers — a standard Helius shared RPC, a dedicated Triton one node, and a staked connection with a process co-located on the same machine as the leader — the numbers came back with a spread large enough to be the difference between landing in slot N and watching the opportunity resolve in slot N+1. Here is what the data actually looks like, and what it means for how you architect your infrastructure.

What We Measured and How

The benchmark ran a synthetic round-trip test across epochs 650–662 on mainnet-beta: build a signed no-op transaction with a fresh blockhash, submit it via sendRawTransaction with skipPreflight: true and maxRetries: 0, then poll getSignatureStatuses at 20 ms intervals until confirmation lands or 5 seconds elapse. We logged wall-clock microseconds from submission to first-confirmation slot. Runs were scheduled against the known leader schedule so each submission targeted the same validator tier wherever possible. Sample size: 3,000 submissions per tier, distributed across 12 epochs to smooth out per-epoch validator hardware variance.

Summary table (mainnet-beta, epochs 650–662):

Tier	p50 (ms)	p99 (ms)	Drop rate
Helius shared RPC	312	1,840	3.2%
Triton dedicated node	148	610	1.1%
Co-located staked connection (TPU direct)	28	95	0.3%

The p99 column is the one that matters for production bots. A tail at 1,840 ms on a shared endpoint means that one in a hundred of your most time-sensitive submissions misses multiple leader rotations. At 400 ms per slot that is up to four full slots of latency on your worst transactions — exactly the ones that were probably competing on the tightest opportunity window.

Why Shared RPC Tail Latency Is So Bad

Helius shared endpoints are geographically distributed and absorb aggregate load from thousands of clients. Your transaction hits their ingress, gets queued, forwarded to the current leader's TPU, and confirmation flows back through the same stack. The p50 of 312 ms is perfectly acceptable for dashboard queries or wallet reads. For submission-critical paths, the problem is the shared queue: a burst of traffic from another client on the same endpoint pool can add hundreds of milliseconds to your forwarding time. The drop rate at 3.2% is not catastrophic, but on a bot submitting 500 transactions per hour that is 16 dropped transactions — each representing a missed position entry or a stale close.

Helius's staked connection product (their premium tier using validator stake weight for priority forwarding) closes some of this gap, typically landing around 180–220 ms p50 in my testing, with p99 closer to 700–900 ms. Worth considering as an intermediate step before committing to dedicated infrastructure.

Dedicated Nodes: The Middle Ground That Often Makes Sense

A Triton one dedicated node puts you on hardware that forwards only your traffic to the current leader. The p50 drops to 148 ms — roughly half the shared latency — and the p99 falls to 610 ms. More importantly, the drop rate at 1.1% means your retry logic is doing real work rather than compensating for infrastructure churn.

The operational advantage here is stability: your throughput does not degrade based on what other clients are doing. For strategies where you need sustained throughput — a Solana market-making bot continuously re-quoting both sides of a DEX pair — dedicated nodes are often the right tier. You also get access to Geyser streams directly, which lets you bypass the account-polling overhead entirely for event-driven triggers.

Pricing for dedicated nodes runs roughly $1,500–3,000/month depending on spec. That sounds significant until you calculate what a 1% drop rate improvement is worth on a strategy with $50k average daily notional.

Co-location and TPU Direct: The Numbers That Matter for Searchers

Direct TPU submission bypasses RPC entirely. You connect to the validator's TPU port (UDP, port 8000 by default) and push packets to the leader's ingress queue without an intermediary. When your process runs on the same machine or on a host in the same rack as the leader, the network hop is measured in single-digit milliseconds.

The p50 of 28 ms in our data represents the hardware floor: transaction construction, signature computation, UDP send, and the validator's own processing queue. The p99 of 95 ms tells you the tail is now driven by validator-side scheduling variance, not network jitter. The 0.3% drop rate reflects the remaining risk of leader queue saturation during burst periods — no infrastructure eliminates this entirely.

The operational complexity is significant. Solana's leader schedule rotates every four slots (roughly 1.6 seconds), and co-location benefits are localized to the current leader's physical machine. In practice, co-located setups maintain connections to the next 2–3 scheduled leaders simultaneously and pre-warm those connections during the current leader's slot window. Missing a leader rotation because your connection handshake is in flight costs you the full slot.

What this tier actually requires:

• Bare-metal or close-to-bare-metal hosting in the data centers where Solana validator stake is concentrated (primarily Frankfurt, Amsterdam, and Ashburn data centers host a large share of mainnet stake)
• Custom UDP send logic; standard sendRawTransaction RPC calls will not use TPU directly unless you are wrapping your own socket layer
• Connection management across the live leader schedule, pulling leader pubkeys and resolving TPU addresses in real time
• Jito bundle submission as a fallback for slots where the TPU leader is a Jito-enabled validator (roughly 50–60% of stake)

The infrastructure overhead is why this tier is reserved for strategies where sub-100 ms round trips are load-bearing — primarily MEV, cross-DEX arbitrage, and liquidation hunting. For a sniper bot targeting Pump.fun launches, the difference between 28 ms and 148 ms may or may not translate to a filled order depending on bundle competition dynamics.

Choosing the Right Tier

The decision is not just latency — it is latency relative to your strategy's time sensitivity and the capital efficiency of the fee budget you would otherwise spend compensating for slow delivery.

• Shared RPC (Helius/QuickNode standard): Sufficient for wallet trackers, dashboard data feeds, and strategies where execution timing is flexible. Do not run latency-sensitive submission paths here.
• Dedicated node (Triton, Helius premium staked): The correct default for actively trading bots — copytrading, market-making, moderate-frequency arb. The p99 improvement over shared is the main argument, not the p50.
• Co-location + TPU direct: Warranted for MEV, liquidation bots, and competitive sniping where the edge is measured in single slots. Budget for the engineering overhead; this is not a drop-in upgrade.

The infra and data pipelines we build at TierZero use a tiered model: Geyser subscriptions on dedicated nodes for event detection, and either dedicated-node or co-located TPU submission depending on the strategy's latency requirements. The two functions have different optimal infrastructure, and conflating them into a single RPC endpoint is a common mistake that shows up clearly in the p99 numbers.

---

If you are building or running a Solana trading system and the latency tier you are on is limiting your fill rate, reach out — we scope and build this infrastructure as part of every bot engagement.