Solana transaction landing services market share
Share of tipped Solana transactions attributed to each landing service, counted via known on-chain tip wallets. Observational, no transactions sent.
Read this carefully
Three caveats. (1) Market share, NOT landing rate, measuring success rates would require sending controlled tx, which costs SOL. (2) Jito is over-counted, other services (Helius Sender, Astralane, bloXroute) fan-out tips to Jito alongside their own wallet, inflating Jito's counter. (3) High share ≠ best, Nozomi has tiny share but charges 10x higher tips for guaranteed inclusion. Pick on latency / cost / reliability fit, not leaderboard position.
This benchmark answers the question every Solana dev choosing a transaction landing service asks. who actually carries the flow, what does it cost, and is it growing or shrinking. Marketing pages quote self-reported "99% landing rate" without methodology; this page measures the reality on-chain by observing the known tip wallets each service publishes in its docs. Every confirmed Solana transaction that pays a tip to one of ~72 known landing- service wallets is attributed to that service. Zero on-chain footprint, we don't send tx ourselves, we watch the chain. Coverage. 8 services with cleanly attributable tip wallets. Jito Block Engine (the OG, 8 wallets), Helius Sender (10 wallets, disjoint from Jito's pool), Nozomi by Temporal Labs (17 wallets with `noz` vanity prefix), bloXroute Trader API (17 `bLx` wallets), 0slot.trade (10 wallets), NextBlock (8 wallets), Astralane Iris, SolanaVibeStation Lightspeed. Blind spots. Syncro Sender (per- customer tip wallets, undisclosed), Slipstream (pure router whose tx land via underlying senders' wallets and get attributed to those), and any direct-RPC tx that doesn't pay a tip (a large share of total Solana traffic, but not what this bench measures).
Methodology
We attribute Solana transactions to their landing service by watching the on-chain tip wallets each service documents publicly. A single WebSocket connection to mainnet-beta subscribes via `logsSubscribe(mentions=[tip_wallet], commitment=confirmed)` for each of ~72 tip wallets across 8 services. Every confirmed notification increments a per-service counter; signatures are deduplicated against a 50k-entry LRU so reconnect replays don't double-count. Failed transactions (Err != null) are excluded - they didn't actually land. The headline metric is total landed-and-tipped tx attributed to each service in the last 24 hours, surfaced as a leaderboard sorted by volume. This is the observational counterpart to a controlled landing-rate benchmark. it costs nothing to run (no tx sent, no SOL spent), provides market-share signal that the controlled approach cannot (real user behaviour, not synthetic probes), and stays neutral (services can't fingerprint our probes, there are no probes). Limitations. (a) Helius Sender fans some tx to Jito under the hood; if Helius's own tip wallet is paid, attribution is clean, but Helius's "dual-path" fallback to Jito-only payment would be miscounted as Jito. (b) Services rotating tip wallets without doc updates introduce silent under-counting until the new addresses are added to the harness. The harness logs every unattributable tip-pattern tx so the gap surfaces in operator metrics.
Frequently asked
What is a Solana landing service?
Solana has no traditional mempool. Transactions go directly to the current and next slot leader. During congestion, leaders drop transactions they can't process, they're simply lost, not queued. Landing services help your tx avoid being dropped via various tricks. direct connections to leaders (Nozomi, 0slot), stake-weighted QoS pools (Helius Sender, Triton Cascade), tip-based bundle auctions (Jito), multi-path propagation (bloXroute, Astralane). This bench measures which services actually carry the on-chain flow today.
Why observational? Why not measure landing rate directly?
Sending controlled tx through each service to measure landing rate costs real SOL (every tx = base fee + tip + compute units, all paid to validators, none recoverable). At a 30 s cadence across 5 services and 3 regions, that's ~$11,700/month. The observational approach costs $0 because we don't send anything, we watch the chain. Trade-off. observational tells you 'who is used' (market share, tip economics, growth); controlled tells you 'who lands best' (per-service success rate). Different questions, both useful. This is the observational answer.
How is each tx attributed to a service?
Each landing service publishes a list of known tip wallet addresses in its docs (Jito has 8, Nozomi has 17, etc.). When a user routes a tx through a service, the tx includes a transfer to that service's tip wallet. We watch all 72 tip wallets via `logsSubscribe(mentions=[wallet])` and attribute each notification to the owning service. Wallet sets are disjoint, no overlap between services, so attribution is unambiguous. The pattern is verified against real mainnet blocks: 95-97% of tip-paying tx attribute cleanly, zero multi-service overlaps observed.
Why does Jito have such dominant share?
Three reasons. (1) First-mover. Jito launched the tip+bundle pattern in 2022 and got every major wallet (Phantom, Backpack) + every major trading bot to integrate first. (2) Lowest tip floor, Jito accepts tips as low as 1,000 lamports versus 0.001 SOL minimums on most competitors. (3) Atomic bundles, only Jito offers the 5-tx atomic group that DEX aggregators (Jupiter, Raydium) use for sandwich-proof swaps. The result is structural: Jito carries the default flow even when competitors are technically faster on specific paths.
Why does Nozomi look small here?
Nozomi's share by tx count is small but its share by tip revenue is much larger. Nozomi targets serious traders who pay 0.001+ SOL per tx as guaranteed-inclusion insurance, while Jito averages ~0.0001 SOL per tx as casual usage. Blockworks Research's 'Solana Block Building Wars' (Feb 2026) documented Nozomi at ~$1M tips on 2M swaps vs Jito's $300k on 24M swaps, a 130x premium per swap. For 'who do serious traders use', track Nozomi. For 'who handles default flow', track Jito.
What about Syncro Sender and Slipstream?
Syncro Sender (P2P.org) uses per-customer tip wallets that aren't publicly documented, every customer gets a private address. We can't enumerate them, so Syncro flow is invisible to this bench. Estimated share: small (Syncro launched in 2025 and hasn't disclosed adoption metrics). Slipstream is a router that calls the underlying senders' SDKs, its tx land via Jito/Nozomi/0slot tip wallets and are attributed to those services. So Slipstream-originated flow shows up correctly counted, just under the underlying service's name. If you specifically want to know 'what % uses Slipstream as the router', this bench can't answer that, Slipstream itself doesn't add an identifying memo.
Source code github.com/OpenChainBench/OpenChainBench/tree/main/harnesses/solana-tx-landing
