How We Measure

Methodology of the Netticode Solana Transaction Landing Benchmark.

What We Test

We measure how quickly each provider lands a Solana transaction on-chain from submission to confirmed slot. “Landing” means the transaction appears in a confirmed block. We do not test MEV protection, bundle landing, or websocket latency.

Infrastructure

Location: EU West (Frankfurt). All providers are tested simultaneously — identical transactions are sent to all endpoints at the same instant within each run.

Transaction Parameters

Each run uses an identical base transaction sent to all providers. Priority fees are equal for all providers within each run. Tips (Jito-style) are added only where the provider supports them — currently Jito and Nozomi — at each provider's standard tip amount.

Latency Measurement

Reported latency is not raw wall-clock time. From the send-to-observe interval we subtract the estimated network transit time on both ends: the round-trip to the provider endpoint on the way out, and the approximate shred propagation time from the leader back to our monitoring node. This isolates the provider's own relay and inclusion speed rather than geographic distance.

Landing confirmation uses shred-resolution detection: we monitor the Turbine shred stream directly and timestamp the moment the first shred carrying the transaction arrives — giving single-shred precision instead of the coarser polling-based approach.

Metrics

Verification

Every individual result includes a link to Solana Explorer (solscan.io) so anyone can independently verify the on-chain transaction.

Caveats

Independence

Operated by Netticode Oy. We test our own RPC alongside competitors. No commercial agreements with any provider influence results. All providers run under identical base conditions; tip differences reflect each provider's own requirements.