Solana transaction landing latency
How fast does each landing service get a signed mainnet tx confirmed. Slot delta = number of Solana slots between submit and confirmed (1 slot ≈ 400 ms). Active probing, identical signed txs every hour from us-east.
Read this carefully
Six caveats. (1) us-east only, sgp / eu-west arrive in V2. (2) One pre-registered tip per service. (3) Synthetic payload (1-lamport + memo); real swaps may land differently. (4) Helius / Astralane / Nozomi fan out to Jito internally; Jito control probe runs each cycle. (5) Confirmation = `confirmed`. (6) Slot delta is canonical; ms is derived (≈ slot_delta × 400 ms + RTT). Pair with /benchmarks/solana-tx-landing.
This benchmark answers the only question that matters to a Solana trader picking a landing service. how many slots does your signed mainnet transaction take to reach the confirmed state on chain. Every hour from a us-east probe, the harness submits an identical signed tx through each of 5 services in parallel, captures the submit slot before send and the land slot from the signatureSubscribe WebSocket notification at commitment=confirmed, and increments per-service Prometheus histograms. Headline numbers shown are p50 and p99 slot delta over a rolling 7-day window. Wall-clock milliseconds are published alongside for intuition (one Solana slot is ~400 ms, so a p50 of 1 slot is ~400 ms wall-clock plus submission RTT) but slot delta is the canonical, sponsor-proof on-chain measurement. Why slot delta is the right metric. Solana confirmation is a slot-level event. when a slot reaches supermajority vote, every transaction in it becomes confirmed simultaneously. Wall-clock ms conflates HTTP submission time, our RPC's polling lag, and network RTT to the public WebSocket - all of which are measurement artifacts unrelated to the landing service's actual routing quality. Slot delta is what the chain itself records. Coverage. 5 services probed in V0-Lean. Jito Block Engine (the control / baseline because Helius, Astralane, Nozomi all internally route some flow through it). Helius Sender in `swqos_only=true` mode (isolates the Helius own-path from the Jito leg). Astralane Iris (tip-refund mechanism). Nozomi by Temporal Labs (premium tier, hard 1M lamport tip floor). 0slot.trade (premium tier). NextBlock, bloXroute and SolanaVibeStation arrive in the next tier (V1) once the first sponsors land. Companion bench. /benchmarks/solana-tx-landing measures market share via on-chain tip-wallet attribution - who carries the flow today, regardless of speed.
Methodology
We probe 5 Solana transaction landing services from a single Railway us-east region, once per hour, by submitting an identical signed mainnet transaction to each. The payload is the minimal valid Solana tx, compute-budget instructions (50k CU limit, 50k micro-lamport/CU price), a 1-lamport self-transfer, the per-service tip transfer to the service's documented tip wallet, and an OCB-prefixed memo for forensic traceability. All five services are submitted in parallel goroutines within a single cycle so they sample the same chain congestion window. The headline measurement is slot delta, land_slot minus submit_slot, captured from the signatureSubscribe WebSocket notification's context.slot field at commitment=confirmed. Wall-clock ms is reported alongside but is a derived approximation, slot_delta × ~400 ms plus submission RTT and goroutine startup variance. A 60 s no- confirmation deadline classifies the probe as dropped{reason=timeout}; structured RPC errors classify as invalid; transport failures as network_error; HTTP 419 / 429 / "rate limit" errors classify as rate_limited (a separate label so quota issues don't bias the bench against the throttled service). Cost. ~$159/mo at SOL=$86, 86 % of which goes to the four ≥1M-lamport-floor services (Nozomi, 0slot, bloXroute, NextBlock, only two of these in V0-Lean). Sponsor SOL credits covering a service's own probes are explicitly allowed per the sponsor-proof framework. Limitations. (a) Single us-east region, sgp / eu-west arrive in V2 once sponsors fund geographic-edge story. (b) 1-hour cadence, 168 probes per service per 7-day window, enough for stable p50 / p99 over the publication window, not enough for intra-hour resolution (V0.5 / V1 upgrade if needed). (c) Fan-out, Helius probed in `swqos_only` mode only in V0-Lean to keep wire shape simple; dual-mode arrives in v1.0.1 methodology PR.
Frequently asked
Why is slot delta the headline metric instead of wall-clock latency?
Solana confirmation is a slot-level event. when a slot reaches supermajority vote (~2/3 of stake), every transaction in that slot becomes confirmed simultaneously. The WebSocket pushes notifications for all subscribed signatures in that slot at the same instant. So if 3 services delivered txs that all landed in the same slot, our wallclock measurement records the same time for all 3, the only differentiation is whether the next service's tx landed in slot N or N+1. slot_delta captures that directly. Wall-clock ms is derived (slot_delta × ~400 ms + RTT + variance) and conflates routing quality with measurement artifacts like HTTP submission speed and our public RPC's network latency. We publish wall-clock ms because traders think in seconds, but slot_delta is what you should cite in an audit or methodology dispute. It's RTT-independent and reads directly from the chain.
What does '1 slot' actually mean in time?
Solana slots are ~400 ms in practice (~625 ms target with leader skips and forks averaging it down). A p50 slot_delta of 1 means your tx typically lands in the slot immediately following your submission, ~400 ms after sendTransaction return. p50 of 2 means typically one slot later, ~800 ms. The gap between p50 = 1 and p50 = 2 is the operational signal, a service that consistently lands 1 slot earlier than its competitors is ~400 ms ahead, which is the difference between catching an arbitrage and missing it.
Why an active bench when /benchmarks/solana-tx-landing already exists?
/benchmarks/solana-tx-landing is observational, it watches the chain and counts who carries the flow. It cannot answer 'how fast does my tx land if I send it now', because it doesn't send anything. This bench (active probing) answers that, at the cost of running 24 / 7 with real SOL ($159 / month at the V0-Lean cadence). The two benches answer different product questions. Read both.
Why only 5 services, not the 8 you measure observationally?
NextBlock, bloXroute Trader, and SolanaVibeStation all require paid plans or sales-call onboarding before they issue an API key. We're shipping V0-Lean today with the 5 services that have a clear self-serve or contact-based path. The other 3 will be added as the bench scales. The observational bench at /benchmarks/solana-tx-landing already covers all 8 because it doesn't need API keys.
Why us-east only?
V0-Lean. us-east is the de-facto Solana baseline (Jito, NextBlock, bloXroute, Helius all anchor their best-connected POPs there) and is where most Solana bots deploy by default. Adding eu-west and sgp triples the bench cost and answers a different question ('does the ranking change by geography?'), which is a planned V2 scope expansion.
What's the probe payload?
Five instructions in this exact order, locked by methodology §3. (1) SetComputeUnitLimit(50,000). (2) SetComputeUnitPrice(50,000 micro-lamports/CU), together a 2,500-lamport priority fee. (3) SystemProgram.Transfer of 1 lamport from the prober keypair to itself, the minimal valid state-touching tx. (4) SystemProgram.Transfer to the service's documented tip wallet at the pre-registered floor. (5) Memo program write with the cycle ID, service name, and probe mode. Total weight: ~600 bytes, well under the 1,232-byte tx limit.
How is fan-out handled?
Helius (default mode), Astralane, and Nozomi route a portion of flow through Jito internally. The Jito control probe, Jito is part of the V0-Lean probe set, fires in the same cycle as the suspect services with the same blockhash and a comparable tip. The slot_delta column tells you immediately whether a suspect service is adding value beyond a Jito wrapper. Same slot_delta as Jito = same inclusion slot = Jito caught it. Suspect ahead by 1+ slot = real own-path routing. Helius is additionally probed in `?swqos_only=true` mode to fully isolate its own routing path.
Can a service detect and prioritise our probes?
Yes, in principle. The memo prefix `ocb-` is deterministic and the keypair is constant per region. Anti-fingerprinting (memo randomisation, sub-account rotation, tip jitter within the floor band) ships in v1.0.2 methodology PR. We disclose this risk openly; the trade-off is that announcing the bench publicly to providers gives them a chance to fix real performance issues before we publish, which is a good outcome. We do NOT accept private deals to alter the probe surface for any specific service.
Why is sample_size on the dashboard ~168 per service?
V0-Lean cadence = 1 probe per service per hour from 1 region. 168 = 24 hours × 7 days. The 7-day publication window is the trade-off between statistical resolution (sample size grows with window) and freshness (shorter window reflects current chain conditions). At ~168 samples per cell, p50 is stable to within ±5 % and p99 to within ±15 %. Lower confidence intervals are unlocked at V0.5 cadence (1 / 10 min, ~$760 / mo) and above.
How is the confirmation observed?
Via `signatureSubscribe` on the public mainnet WebSocket (`wss://api.mainnet-beta.solana.com`). The subscription is registered BEFORE submission so a fast-confirming tx cannot complete before we are listening (otherwise we'd miss the notification and timeout spuriously). The RPC pushes the notification at the instant the commitment level is reached, so observation resolution is RTT-bounded (~30-50 ms us-east → mainnet-beta) and slot_delta is read directly from the notification's context.slot field. HTTP polling at 200 ms is an automatic fallback if the WebSocket fails to connect for a given cycle.
Source code github.com/MobulaFi/mobula-monorepo/tree/main/miniapps/solana-tx-landing
