From abba0861c35ba8dbd32c42269af9521a4aa43bcf Mon Sep 17 00:00:00 2001 From: Florent Tapponnier Date: Thu, 25 Jun 2026 14:47:07 +0200 Subject: [PATCH] chore(benchmarks): drop solana-tx-landing-latency (harness offline, 404 bleeding SEO) --- alternatives/helius.yml | 13 -- alternatives/jito.yml | 13 -- ...solana-rpc-lands-the-most-transactions.yml | 38 --- benchmarks/solana-tx-landing-latency.yml | 221 ------------------ docs/methodology/solana-tx-landing-active.md | 163 ------------- harnesses/solana-tx-landing/README.md | 7 +- .../cmd/script/active_metrics.go | 5 +- .../solana-tx-landing/cmd/script/main.go | 1 - .../solana-tx-landing/cmd/script/prober.go | 3 +- src/app/answers/[slug]/page.tsx | 8 +- src/app/answers/page.tsx | 7 +- src/data/bench-published.json | 1 - src/data/compare-pairs.ts | 9 - 13 files changed, 14 insertions(+), 475 deletions(-) delete mode 100644 alternatives/helius.yml delete mode 100644 alternatives/jito.yml delete mode 100644 answers/which-solana-rpc-lands-the-most-transactions.yml delete mode 100644 benchmarks/solana-tx-landing-latency.yml delete mode 100644 docs/methodology/solana-tx-landing-active.md diff --git a/alternatives/helius.yml b/alternatives/helius.yml deleted file mode 100644 index e5d9963b..00000000 --- a/alternatives/helius.yml +++ /dev/null @@ -1,13 +0,0 @@ -slug: helius -target_product: Helius -target_url: https://helius.dev -description: Solana RPC provider with a transaction landing service (Sender) -benchmark: solana-tx-landing-latency - -intro: | - Helius runs a Solana RPC provider with a dedicated transaction landing service called Sender, available in both default mode (with Jito fan-out) and `swqos_only=true` mode (own-path only, no Jito leg). The only question that matters to a Solana trader picking a landing service is how many slots a signed mainnet transaction takes to reach the confirmed state on chain, because Solana confirmation is a slot-level event and a 1-slot difference is roughly 400 ms (enough for a MEV bot to front-run a competitor). This benchmark probes five landing services from a us-east Railway region, once per hour, by submitting an identical signed mainnet transaction to each in parallel. The payload is a compute-budget instruction pair (50k CU limit, 50k micro-lamport/CU price), a 1-lamport self-transfer, the per-service tip transfer at a pre-registered floor and an OCB-prefixed memo for forensic traceability. The headline metric is slot delta (`land_slot` minus `submit_slot`) captured from the `signatureSubscribe` WebSocket notification's `context.slot` field at commitment level confirmed. Wall-clock milliseconds is published alongside as a derived approximation but the canonical RTT-independent number is the slot delta. Helius is probed in `swqos_only=true` mode against `ewr-sender.helius-rpc.com/fast` to isolate the own-path from the Jito leg, with a 10,000-lamport tip floor. Other services in the V0-Lean cohort: Jito (control baseline), Astralane Iris (tip-refund), Nozomi by Temporal Labs (1M-lamport hard floor) and the Mobula multi-RPC fan-out aggregator. p50 and p99 slot delta are computed over a rolling 7-day window (168 samples per service per cell). - -seo_title: Helius alternatives. Live Solana tx landing slot delta benchmark -seo_description: Compare Helius Sender against Jito, Astralane, Nozomi and Mobula on slot delta from submit to confirmed. Signed mainnet probes every hour from us-east, 7-day window. - -status: live diff --git a/alternatives/jito.yml b/alternatives/jito.yml deleted file mode 100644 index 08e00369..00000000 --- a/alternatives/jito.yml +++ /dev/null @@ -1,13 +0,0 @@ -slug: jito -target_product: Jito -target_url: https://jito.network -description: Solana block engine with atomic bundles and tip auction -benchmark: solana-tx-landing-latency - -intro: | - Jito operates a Solana block engine with atomic bundles and a tip auction, live since 2022, and acts as the baseline that every premium landing service must beat: Helius default mode, Astralane and Nozomi all internally route some flow through Jito, so a same-slot result against the Jito control on a given cycle means the suspect service is essentially using Jito as its inclusion path. The only question that matters when picking a landing service is how many slots a signed mainnet transaction takes to reach the confirmed state on chain, because Solana confirmation is a slot-level event and a 1-slot difference is roughly 400 ms (enough for a MEV bot to front-run a competitor). This benchmark probes five services from a us-east Railway region, once per hour, by submitting an identical signed mainnet transaction in parallel. The payload is a compute-budget instruction pair, a 1-lamport self-transfer, the per-service tip transfer at a pre-registered floor and an OCB-prefixed memo. Jito is probed at `ny.mainnet.block-engine.jito.wtf/api/v1/transactions` with a 10,000-lamport tip floor. The headline metric is slot delta (`land_slot` minus `submit_slot`) read from the `signatureSubscribe` notification's `context.slot` at commitment confirmed; wall-clock ms is published alongside as a derived approximation. p50 and p99 slot delta are computed over a rolling 7-day window (168 samples per service per cell). The cohort includes Helius Sender in `swqos_only` mode (isolated own-path), Astralane Iris (tip-refund mechanism), Nozomi by Temporal Labs (1M-lamport hard floor) and the Mobula multi-RPC fan-out aggregator. Each probe carries the same blockhash and a comparable tip so the slot delta column reads as a direct routing comparison rather than a tip-auction wallclock race. - -seo_title: Jito alternatives. Live Solana tx landing slot delta benchmark -seo_description: Compare Jito against Helius Sender, Astralane, Nozomi and Mobula on slot delta from submit to confirmed. Signed mainnet probes every hour from us-east, 7-day window. - -status: live diff --git a/answers/which-solana-rpc-lands-the-most-transactions.yml b/answers/which-solana-rpc-lands-the-most-transactions.yml deleted file mode 100644 index 6921b2f1..00000000 --- a/answers/which-solana-rpc-lands-the-most-transactions.yml +++ /dev/null @@ -1,38 +0,0 @@ -slug: which-solana-rpc-lands-the-most-transactions -question: "Which Solana RPC provider lands the most transactions in 2026?" -short_answer: | - {{best_name}} currently leads Solana transaction landing latency at {{best_p50}} (p50, 24h), the lowest slot-delta between transaction submission and confirmation across the measured RPC field. - -benchmark: solana-tx-landing-latency - -intro: | - Solana trading bots, MEV searchers and on-chain settlement all live or die on the same metric: how reliably and quickly does the RPC endpoint actually land the transaction on a leader's block. Marketing pages publish landing-rate numbers; almost none publish methodology or a live, neutral comparison. This page answers the question that wallet integrations, agent infrastructure and trading desks ask before pasting a URL into production. Which RPC provider is actually landing transactions the fastest right now, measured in slot delta between submission and confirmation, with a probe that runs continuously from multiple regions against the same canonical leader schedule. - -methodology: | - The harness submits a self-signed compute-unit-cheap transaction every few seconds through each RPC provider's submission endpoint, then watches a canonical archive node for the resulting confirmation. The landing latency is the wall-clock slot delta between submission and confirmation, expressed in milliseconds at Solana's 400 ms slot interval. The p50 over 24h is the headline metric; p99 captures the worst 1 percent of cases, where a provider's regional infrastructure or leader proximity surfaces clearly. Probes run from US-East, EU-West and Singapore against the same canonical archive node so any geographic asymmetry shows up as a per-region split, not as a noise floor on the aggregate. - -limitations: - - "Slot delta is not the same as fee. A provider can land transactions fastest while charging a per-transaction priority fee through Jito or a similar bundler; cost-per-landed-transaction is a composite metric the leaderboard does not currently surface." - - "Self-signed test transactions do not exercise the full priority-fee mempool. A real production transaction with a high priority fee and CU budget lands faster than the probes shown here, and the relative ordering can shift when paying for inclusion." - - "Provider landing performance shifts with Solana validator leader schedule. A provider with relayers physically close to today's leader can outperform on this window and lose its lead next epoch when the schedule rotates." - - "This is not a stake-weighted measurement. The harness measures wall-clock landing time at the canonical archive node level, not the share of stake reached at each submission." - -faq: - - q: "What does landing latency actually measure?" - a: "Wall-clock milliseconds between the moment a probe submits a self-signed transaction to a Solana RPC and the moment a canonical archive node sees the same transaction in a confirmed block. Lower is faster. The number is the time from your code calling send to the network treating the transaction as included." - - q: "Why is this different from Solana block time?" - a: "Solana block time is the chain's slot interval, fixed at 400 milliseconds. Landing latency is the time your transaction takes to reach the leader plus the leader's time to include it plus the propagation back to a canonical observer. The chain produces a slot every 400 milliseconds whether or not your transaction lands in it; the question this page answers is which provider's path gets you into the next available slot most consistently." - - q: "Does Jito's bundler beat raw RPC landing?" - a: "On the measured probes, Jito bundling is treated as a provider option, not as a separate metric. When the harness submits through a Jito-aware provider with bundle inclusion enabled, the path includes the bundler. The leaderboard surfaces both Jito and non-Jito providers in the same field so the relative cost of bundling is visible." - - q: "What regions are the probes from?" - a: "US-East, EU-West and Singapore. Cross-region probes catch providers whose landing performance is asymmetric across geography (an RPC fast from EU but slow from APAC is common). The leaderboard reports the cross-region p50; the per-region breakdown is on the bench page." - - q: "Why not measure with my own real workload?" - a: "Real workloads are the ground truth, but they are not comparable across providers because they carry different priority fees, different program calls, and run from different infrastructure. The harness controls for those variables to publish a fair cross-provider comparison; for your specific workload, run the same harness yourself (it is open source) and compare." - -related: - - which-blockchain-has-cheapest-transaction-fees - - which-l1-has-the-fastest-finality - -seo_title: "Which Solana RPC provider lands the most transactions in 2026?" -seo_description: "{{best_name}} leads Solana transaction landing at {{best_p50}} slot delta (p50, 24h) measured live by OpenChainBench. Methodology, regional probes and limitations on this page." -status: live diff --git a/benchmarks/solana-tx-landing-latency.yml b/benchmarks/solana-tx-landing-latency.yml deleted file mode 100644 index 8e1858b8..00000000 --- a/benchmarks/solana-tx-landing-latency.yml +++ /dev/null @@ -1,221 +0,0 @@ -# OpenChainBench. Bench № 027 - -slug: solana-tx-landing-latency -number: "027" -title: Fastest Solana RPC for tx landing, live slot delta benchmark -seo_title: "Fastest Solana RPC 2026: Helius, Jito, Mobula slot delta ranked" -seo_description: "{{best_name}} leads fastest Solana RPC for tx landing at {{best_p50}} (p50, 7d). Helius, Jito, Astralane, Mobula, Nozomi probed hourly with signed mainnet txs." -subtitle: How fast each landing service gets a signed mainnet tx confirmed. Slot delta = number of Solana slots between submit and confirmed (1 slot is roughly 400 ms). Active probing every hour from us-east. -category: Trading -status: live -metric: p50 slot delta to confirmed (7-day window) -unit: slots -higher_is_better: false - -disclaimer: | - 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. - -seo_intro: | - 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. - -abstract: | - 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. - -methodology: - - "Source endpoints (us-east Railway, base64 JSON-RPC sendTransaction unless noted). Jito `ny.mainnet.block-engine.jito.wtf/api/v1/transactions`. Helius Sender `ewr-sender.helius-rpc.com/fast?swqos_only=true` (skipPreflight + maxRetries=0). Nozomi `http://edge.nozomi.temporal.xyz/api/sendBatch?c=` (binary `[u16_BE_len][tx_bytes]`, HTTP per Temporal Labs). Astralane `ny.gateway.astralane.io/iris?api-key=` (3-elem params, mevProtect). 0slot `ny.0slot.trade?api-key=`." - - "Probe payload. 5 instructions in this exact order: SetComputeUnitLimit(50,000) + SetComputeUnitPrice(50,000 micro-lamports/CU) + SystemProgram.Transfer(payer→payer, 1 lamport) + SystemProgram.Transfer(payer→service tip wallet, floor lamports) + Memo(`ocb---`). cycle_id is an 8-byte random hex shared across the five parallel probes of one cycle, so the on-chain memos correlate." - - "Tip floors (pre-registered, methodology PR + 14-day window to change). Jito 10,000 lamports. Helius Sender 10,000. Astralane 500,000 net of refunds. Nozomi 1,000,000. 0slot 1,000,000." - - "Submission flow. One getLatestBlockhash(processed) shared across all five probes. One getSlot(processed) as submit_slot. For each service we subscribe to the signature via signatureSubscribe on the public WS BEFORE submission (otherwise a fast confirm could fire before we listen). Probes then fire in parallel goroutines, sign, POST. We block on the signatureNotification at commitment=confirmed; context.slot is land_slot; slot_delta = land_slot - submit_slot." - - "Why slot delta is canonical. Solana confirmation is slot-level. when a slot reaches supermajority, every tx in it becomes confirmed simultaneously. The WS pushes notifications for all subscribed sigs in that slot at the same instant. So sub-400 ms wallclock diffs between services in the same slot are artifacts (goroutine startup, RTT), not routing quality. slot_delta is what the chain records, what to cite in audits." - - "Wall-clock ms is a derived approximation. ms ≈ slot_delta × ~400 ms + HTTP submission RTT + variance. We publish it for intuition because traders think in seconds, not slots, but it should not be the sole metric in a sponsor pitch or audit. If a service argues 'your ms numbers are biased by your RTT', the answer is the slot delta column, which is RTT-independent." - - "Drop classification. timeout = no confirmation within 60 s. invalid = RPC error, on-chain Err, or BlockhashNotFound. network_error = transport-level (timeout, DNS, EOF, connection refused). rate_limited = HTTP 419 / 429 / 'rate limit' / 'too many requests'. landing_rate is published as success / (success + timeout), rate_limited and network_error are excluded so quota / transport issues don't bias the bench against a throttled service." - - "Jito control probe. Helius (default), Astralane, Nozomi route a portion of flow through Jito internally, conflating own-path vs Jito-caught-it. Jito is in the V0-Lean set so its control fires in the same cycle. Same slot_delta as Jito = no measurable own-path value. Suspect ahead by 1+ slot = real routing advantage." - - "Reproducibility. The full harness source is at github.com/ChainBench/OpenChainBench/tree/main/harnesses/solana-tx-landing. Anyone with a funded Solana keypair (~1 SOL) can clone, set SOLANA_PROBE_KEYPAIR_BASE58, run the binary, and reproduce these metrics. The bench does not rely on any private or internal service for measurement, the only RPC dependency is the public `api.mainnet-beta.solana.com` HTTP + WebSocket endpoints." - - "Methodology v1.3 pre-registered at github.com/ChainBench/OpenChainBench/blob/main/docs/methodology/solana-tx-landing-active.md. Any change (tip floor, probe payload, cadence, region, metric definitions) ships as a public PR with a 14-day comment window. Major version bumps run a 30-day shadow period publishing old and new metrics in parallel." - -findings: - - "{{best_name}} leads the V0-Lean probe set at p50 = {{best_p50}} slot delta over the rolling 7-day window. Lower = fewer Solana slots between submission and confirmation. The gap between fastest and slowest is the operational signal, every service claims '99 %+ landing rate' in marketing copy, but the chain doesn't lie about which slot included your tx. A 1-slot difference is ~400 ms, enough for a MEV bot to front-run a competitor." - - "{{name:jito}} is the baseline / control. Helius (default mode), Astralane, and Nozomi all internally fan out to Jito, so the Jito p50 is the floor any premium service must beat. Same slot_delta as Jito on a given cycle = the service is essentially using Jito as its inclusion path. {{name:jito}} sits at p50 = {{p50:jito}} slot delta." - - "{{name:helius-sender}} in `swqos_only` mode isolates Helius's own routing path from the Jito leg. p50 = {{p50:helius-sender}} slot delta. A v1.0.1 methodology update will publish Helius default mode (with Jito fan-out) side-by-side for direct comparison." - - "{{name:nozomi}} premium pricing (1M lamport hard floor, ~10 × Jito's competitive level) only makes economic sense if the slot_delta advantage is meaningful. p50 = {{p50:nozomi}} slot delta. The gap vs Jito quantifies whether the tip premium buys real slot priority." - - "{{worst_name}} trails at p50 = {{worst_p50}} slot delta. The worst slot delta in the V0-Lean set is not necessarily a bad service, it may be a service whose strength is in dimensions this bench doesn't measure (anti-MEV protection, durable nonce, fee-refund mechanics). Latency is one variable, not the whole product." - -faq: - - q: "Why is slot delta the headline metric instead of wall-clock latency?" - a: "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." - - q: "What does '1 slot' actually mean in time?" - a: "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." - - q: "Why an active bench when /benchmarks/solana-tx-landing already exists?" - a: "/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." - - q: "Why only 5 services, not the 8 you measure observationally?" - a: "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." - - q: "Why us-east only?" - a: "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." - - q: "What's the probe payload?" - a: "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." - - q: "How is fan-out handled?" - a: "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." - - q: "Can a service detect and prioritise our probes?" - a: "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." - - q: "Why is sample_size on the dashboard ~168 per service?" - a: "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." - - q: "How is the confirmation observed?" - a: "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: https://github.com/ChainBench/OpenChainBench/tree/main/harnesses/solana-tx-landing - -prometheus: - window: 7d - expected_freshness_seconds: 7200 - -# Real metrics emitted by the active prober in solana-tx-landing harness: -# solana_landing_probe_success_total{service, mode, region} counter -# solana_landing_probe_dropped_total{service, mode, region, reason} counter -# solana_landing_probe_latency_ms{service, mode, region} gauge (set every cycle) -# solana_landing_probe_latency_slots{service, mode, region} gauge (set every cycle) -# solana_landing_probe_latency_slots_histogram{service, mode, region} histogram (debug) -# solana_landing_probe_latency_ms_histogram{service, mode, region} histogram (debug) -# solana_landing_probe_keypair_balance_sol{region} gauge -# solana_landing_probe_cycle_total{region} counter -# solana_landing_probe_enabled{region} gauge -# -# Headline metric (canonical) = slot_p50 / slot_p99 read from the gauge. -# Wall-clock ms is published alongside via the standard p50/p90/p99 fields -# for reader intuition but is derived (slot_delta × ~400 ms + RTT + variance). -# Mode label is `swqos_only` for helius-sender, `default` for the rest. -# -# Why quantile_over_time(gauge) instead of histogram_quantile(histogram)? -# At V0-Lean cadence (1 probe / hour) we have ~168 samples per cell over 7d. -# Histogram buckets {100, 250, 500, 1000, 2000, 5000, 10000, 30000, 60000} ms -# have ~3 buckets in the 1-5s zone where probes actually land, so -# histogram_quantile collapses to bucket midpoints (1500, 3500 ms) and the -# series looks flat. quantile_over_time on the gauge takes the real sample -# at the 50th percentile, which is the accurate published number. - -providers: - - slug: jito - name: Jito - tag: Baseline + control probe; atomic bundles + tip auction since 2022 - formula: "50th percentile over 7d of slot delta (land_slot − submit_slot) for hourly signed mainnet probes submitted to Jito's `ny.mainnet.block-engine.jito.wtf` from us-east." - queries: - p50: quantile_over_time(0.5, solana_landing_probe_latency_slots{service="jito",region="us-east"}[7d]) - p90: quantile_over_time(0.9, solana_landing_probe_latency_slots{service="jito",region="us-east"}[7d]) - p99: quantile_over_time(0.99, solana_landing_probe_latency_slots{service="jito",region="us-east"}[7d]) - mean: avg_over_time(solana_landing_probe_latency_slots{service="jito",region="us-east"}[7d]) - success: sum(rate(solana_landing_probe_success_total{service="jito",region="us-east"}[7d])) / (sum(rate(solana_landing_probe_success_total{service="jito",region="us-east"}[7d])) + sum(rate(solana_landing_probe_dropped_total{service="jito",region="us-east",reason="timeout"}[7d]))) - sample_size: sum(increase(solana_landing_probe_success_total{service="jito",region="us-east"}[7d])) - series: solana_landing_probe_latency_slots{service="jito",region="us-east"} - - - slug: helius-sender - name: Helius - tag: Isolated Helius own-path (no Jito fan-out); anycast + 7 POPs - formula: "50th percentile over 7d of slot delta (land_slot − submit_slot) for hourly signed probes submitted to Helius Sender in `swqos_only=true` mode from us-east, isolating its own-path." - queries: - p50: quantile_over_time(0.5, solana_landing_probe_latency_slots{service="helius-sender",mode="swqos_only",region="us-east"}[7d]) - p90: quantile_over_time(0.9, solana_landing_probe_latency_slots{service="helius-sender",mode="swqos_only",region="us-east"}[7d]) - p99: quantile_over_time(0.99, solana_landing_probe_latency_slots{service="helius-sender",mode="swqos_only",region="us-east"}[7d]) - mean: avg_over_time(solana_landing_probe_latency_slots{service="helius-sender",mode="swqos_only",region="us-east"}[7d]) - success: sum(rate(solana_landing_probe_success_total{service="helius-sender",mode="swqos_only",region="us-east"}[7d])) / (sum(rate(solana_landing_probe_success_total{service="helius-sender",mode="swqos_only",region="us-east"}[7d])) + sum(rate(solana_landing_probe_dropped_total{service="helius-sender",mode="swqos_only",region="us-east",reason="timeout"}[7d]))) - sample_size: sum(increase(solana_landing_probe_success_total{service="helius-sender",mode="swqos_only",region="us-east"}[7d])) - series: solana_landing_probe_latency_slots{service="helius-sender",mode="swqos_only",region="us-east"} - - - slug: astralane - name: Astralane - tag: Tip-refund mechanism, sendBundle / sendIdeal modes, FRA + NY POPs - formula: "50th percentile over 7d of slot delta (land_slot − submit_slot) for hourly signed probes submitted with a 500k-lamport net tip to Astralane Iris's NY gateway from us-east." - queries: - p50: quantile_over_time(0.5, solana_landing_probe_latency_slots{service="astralane",region="us-east"}[7d]) - p90: quantile_over_time(0.9, solana_landing_probe_latency_slots{service="astralane",region="us-east"}[7d]) - p99: quantile_over_time(0.99, solana_landing_probe_latency_slots{service="astralane",region="us-east"}[7d]) - mean: avg_over_time(solana_landing_probe_latency_slots{service="astralane",region="us-east"}[7d]) - success: sum(rate(solana_landing_probe_success_total{service="astralane",region="us-east"}[7d])) / (sum(rate(solana_landing_probe_success_total{service="astralane",region="us-east"}[7d])) + sum(rate(solana_landing_probe_dropped_total{service="astralane",region="us-east",reason="timeout"}[7d]))) - sample_size: sum(increase(solana_landing_probe_success_total{service="astralane",region="us-east"}[7d])) - series: solana_landing_probe_latency_slots{service="astralane",region="us-east"} - - - slug: nozomi - name: Nozomi - tag: Temporal Labs, direct-to-leader, premium 1M-lamport hard floor - formula: "50th percentile over 7d of slot delta (land_slot − submit_slot) for hourly signed probes submitted with a 1M-lamport tip to Nozomi's `edge.nozomi.temporal.xyz` from us-east." - queries: - p50: quantile_over_time(0.5, solana_landing_probe_latency_slots{service="nozomi",region="us-east"}[7d]) - p90: quantile_over_time(0.9, solana_landing_probe_latency_slots{service="nozomi",region="us-east"}[7d]) - p99: quantile_over_time(0.99, solana_landing_probe_latency_slots{service="nozomi",region="us-east"}[7d]) - mean: avg_over_time(solana_landing_probe_latency_slots{service="nozomi",region="us-east"}[7d]) - success: sum(rate(solana_landing_probe_success_total{service="nozomi",region="us-east"}[7d])) / (sum(rate(solana_landing_probe_success_total{service="nozomi",region="us-east"}[7d])) + sum(rate(solana_landing_probe_dropped_total{service="nozomi",region="us-east",reason="timeout"}[7d]))) - sample_size: sum(increase(solana_landing_probe_success_total{service="nozomi",region="us-east"}[7d])) - series: solana_landing_probe_latency_slots{service="nozomi",region="us-east"} - - - slug: mobula - name: Mobula - tag: Multi-RPC fan-out aggregator (relays via Jito / Nozomi / zeroslot) - formula: "50th percentile over 7d of slot delta (land_slot − submit_slot) for hourly probes submitted via Mobula's `api.mobula.io/api/2/swap/send` multi-RPC fan-out from us-east, using a Jito tip wallet." - queries: - p50: quantile_over_time(0.5, solana_landing_probe_latency_slots{service="mobula",region="us-east"}[7d]) - p90: quantile_over_time(0.9, solana_landing_probe_latency_slots{service="mobula",region="us-east"}[7d]) - p99: quantile_over_time(0.99, solana_landing_probe_latency_slots{service="mobula",region="us-east"}[7d]) - mean: avg_over_time(solana_landing_probe_latency_slots{service="mobula",region="us-east"}[7d]) - success: sum(rate(solana_landing_probe_success_total{service="mobula",region="us-east"}[7d])) / (sum(rate(solana_landing_probe_success_total{service="mobula",region="us-east"}[7d])) + sum(rate(solana_landing_probe_dropped_total{service="mobula",region="us-east",reason="timeout"}[7d]))) - sample_size: sum(increase(solana_landing_probe_success_total{service="mobula",region="us-east"}[7d])) - series: solana_landing_probe_latency_slots{service="mobula",region="us-east"} diff --git a/docs/methodology/solana-tx-landing-active.md b/docs/methodology/solana-tx-landing-active.md deleted file mode 100644 index c0cb98ce..00000000 --- a/docs/methodology/solana-tx-landing-active.md +++ /dev/null @@ -1,163 +0,0 @@ -# Methodology - Solana TX Landing (Active Probing) - -> **Pre-registered methodology.** Pinned commit before any sponsor contract is signed. Changes ship as public PRs with a 14-day comment window. Disputes go through public GitHub issues. -> -> **Version :** v1.0 - first commit 2026-05-21. Bench № 016 (Solana TX Landing). -> **Replaces / extends :** the observational tip-wallet attribution methodology that ships with the same bench page (kept as the "Market Share" tab). - ---- - -## 1. Question we answer - -For each Solana transaction landing service, **how long does it take for a transaction submitted via that service to be confirmed on mainnet, and what fraction never confirms within a usable window** - measured from a single fixed geographic origin, on a uniform synthetic payload, at a uniform cadence. - -The bench does **not** answer "which service is best for your trading bot" - that requires modeling your own payload size, tip elasticity, and venue. The bench answers "what is the typical, comparable, reproducible time-to-land per service today." - -## 2. Scope (V0-Lean launch) - -| Dimension | Value | -|---|---| -| Services probed | 5 - Jito Block Engine, Helius Sender, Astralane Iris, Nozomi (Temporal), 0slot.trade | -| Region | 1 - Railway us-east (Newark / NY area) | -| Cadence | 1 cycle per hour | -| Duration | continuous, 24 / 7 | -| Window for headline metrics | rolling 7-day weekly leaderboard | -| Confirmation level | `confirmed` (1+ block confirmation) | - -Services and regions are added through a public PR with a 14-day comment window. Any expansion is a PR + 14-day window - never a silent change. - -## 3. Probe payload (exact) - -Every probe is a single Solana transaction containing three instructions, in this order : - -1. `ComputeBudgetProgram.SetComputeUnitLimit(50 000)` - caps compute units. -2. `ComputeBudgetProgram.SetComputeUnitPrice(50 000 micro-lamports)` - priority fee per CU. -3. `SystemProgram.Transfer(from = prober keypair, to = prober keypair, lamports = 1)` - the payload itself, self-transfer of 1 lamport. Solana requires non-zero state-touching for a tx to be valid; self-transfer is the minimum honest payload. -4. `SystemProgram.Transfer(from = prober keypair, to = , lamports = )` - the tip required by the landing service. -5. `MemoProgram.Memo("ocb---")` where `cycle_id` is a per-cycle 8-byte random hex generated once and shared across all per-service probes in the cycle. This lets us correlate the 5 simultaneous probes on-chain. - -The exact tip amount per service is published as part of this methodology and frozen unless a methodology PR amends it : - -| Service | Tip lamports | Source / justification | -|---|---:|---| -| Jito Block Engine | 10 000 | "Competitive" floor per docs.jito.wtf - above 1 000 doc minimum, below 50th-percentile observed real-traffic tip | -| Helius Sender | 10 000 | Same with `?swqos_only=true` (isolates Helius own path from Jito fan-out) | -| Astralane Iris | 500 000 | Mid-range net of refunds per astralane.gitbook.io | -| Nozomi (Temporal) | 1 000 000 | Hard floor per use.temporal.xyz/nozomi/tipping-and-faq | -| 0slot.trade | 1 000 000 | Hard floor per 0slot.trade | - -We do **not** vary tip amount across cycles. A "tip elasticity" experiment is a separate, sponsored methodology PR. - -## 4. Submission flow (per service, per cycle) - -1. Fetch a recent blockhash via the public mainnet RPC (`api.mainnet-beta.solana.com`) with `commitment = "processed"`. The same blockhash is used for all services in the same cycle so they share a chain-state reference point. `processed` is preferred over `confirmed` because the resulting blockhash is fresher (~400 ms vs ~6 s); the marginal fork risk is acceptable since landing services dedup on signature, not blockhash. -2. Build the transaction described in §3 for that service (the tip-transfer differs per service). -3. Sign with the region's persistent keypair. The signature is known at this point, before any network call. -4. **Subscribe to the signature via `signatureSubscribe` on the public mainnet WebSocket** (`wss://api.mainnet-beta.solana.com`) at `commitment = "confirmed"`. The subscription is registered **before submission** so a fast-confirming tx cannot complete before we are listening (otherwise we would miss the notification and incorrectly timeout). -5. Capture `submit_slot = getSlot(commitment="processed")` and `submit_wallclock = time.Now()`. -6. POST the base64-encoded signed transaction to the service's documented submission endpoint (exact URLs published in the harness source) with `skipPreflight = true`, `maxRetries = 0`, `encoding = "base64"`. Per-service auth headers / query params are applied as documented. -7. Capture the returned signature (or fail-fast on RPC error). -8. Block on the `signatureNotification` push from the WebSocket. On notification, record `land_slot` from the notification context and `land_wallclock = time.Now()`. Classify as **landed**. Resolution is RTT-bounded (~30-50 ms us-east → mainnet-beta) since the RPC pushes the notification the instant the commitment level is reached, with no client polling cadence floor. -9. **Fallback:** if the WebSocket connection fails to establish at the start of the cycle (transient network issue, RPC overload), every probe in that cycle falls back to HTTP polling of `getSignatureStatuses` every 200 ms. This preserves bench continuity but adds a ~200 ms quantization penalty for the affected cycle. The fallback path is logged. -10. If 60 seconds elapse without a notification (or without a non-null `confirmationStatus` on the polling fallback), abandon the wait. Classify as **dropped** with reason `timeout`. -11. If the original submission returned a transport error (HTTP timeout, DNS, EOF, connection refused), classify as **dropped** with reason `network_error`. If the upstream returned HTTP 419 / 429 or a JSON-RPC error containing "rate limit" / "too many requests", classify as `rate_limited`. If the submission was rejected with a structured RPC error (`InstructionError`, `BlockhashNotFound`, etc.) or the on-chain status comes back with an `Err`, classify as `invalid`. - -The 5 services for a given cycle are submitted **in parallel** (Go goroutines) so they sample the same congestion window. The order of `submit_slot` reads is arbitrary but all reads happen within 200 ms. - -## 5. Metrics (Prometheus, exposed at `:2112/metrics`) - -``` -solana_landing_probe_success_total{service, mode, region} counter -solana_landing_probe_dropped_total{service, mode, region, reason} counter - # reason: timeout | invalid | network_error | rate_limited - -solana_landing_probe_latency_slots{service, mode, region} gauge (last observed slot delta) -solana_landing_probe_latency_slots_histogram{service, mode, region} histogram - # buckets: 1, 2, 3, 5, 10, 20, 50, 100 - -solana_landing_probe_latency_ms{service, mode, region} gauge (last observed wall-clock ms) -solana_landing_probe_latency_ms_histogram{service, mode, region} histogram - # buckets: 100, 250, 500, 1000, 2000, 5000, 10000, 30000, 60000 - -solana_landing_probe_keypair_balance_sol{region} gauge -solana_landing_probe_keypair_low_balance_total{region} counter -solana_landing_probe_cycle_total{region} counter -solana_landing_probe_last_cycle_timestamp_seconds{region} gauge -solana_landing_probe_enabled{region} gauge - # 1 when prober configured + running, 0 in pure observational mode -``` - -The `rate_limited` reason groups responses where the upstream service returns HTTP 419 / 429 or a JSON-RPC error containing "rate limit" / "too many requests". Reported separately from `invalid` because rate-limiting is a quota/operational state, not a landing-quality signal. - -**Label semantics :** - -- `service` ∈ {jito, helius-sender, astralane, nozomi, 0slot} -- `mode` is set on `service = helius-sender` only and takes values `swqos_only` or `dual` (other services: `mode = "default"`) -- `region` ∈ {us-east} (V0-Lean); will expand under §7 - -**Headline metrics** displayed publicly on the bench page : - -- `landing_rate = success_total / (success_total + dropped_total{reason="timeout"})` over the last 7 days -- `p50_latency_ms` and `p99_latency_ms` over the last 7 days, per service, per region -- `p50_slot_delta` and `p99_slot_delta` over the last 7 days, per service, per region - -## 6. Jito control probe - -Three services (Helius default mode, Astralane Iris, Nozomi) submit a portion of their flow through Jito internally. Without controlling for this, their measured landing time conflates "this service's own path" with "Jito's auction outcome via this service". - -The Jito control probe is the standard Jito-direct probe **fired in the same cycle as the suspect services**, with the same tip floor (10 000 lamports) and same blockhash. If a suspect service consistently lands at the same `submit_slot + Δ` as the Jito control, the suspect service is interpreted as a Jito routing wrapper for that cycle. We do not currently publish a derived "service-net-of-Jito" metric, but the raw data supports such derivation. - -For Helius we additionally probe in `?swqos_only=true` mode in every cycle (see §3) to publish a clean Helius-only metric series. - -## 7. Versioning rules - -1. **Any** change to §3 (payload), §4 (submission flow), §5 (metric definitions), or the per-service URLs ships as a public PR against this file with a 14-day comment window before merge. -2. Adding a new service requires a PR that updates §2 + §3 + §5 and is announced on the OpenChainBench blog with a 14-day window. Removing a service same. -3. Tip-amount changes (§3) require a PR with a written explanation of why the new amount better reflects "competitive" floor. -4. Region additions and cadence changes are PR + 14-day window. -5. Metric removal or label rename is **prohibited within a version**. Such changes require a major version bump (v1 → v2) with a 30-day shadow-run period publishing both old and new metric families in parallel. - -## 8. Reproducibility - -The full harness source is published at `mobula-api/miniapps/solana-tx-landing/` (Go). Anyone with a funded Solana keypair (~1 SOL) can clone, set the `SOLANA_PROBE_KEYPAIR_BASE58` env var, run the binary, and reproduce all metrics. The bench does not rely on any internal Mobula service for measurement. - -Anyone replicating the bench from a different geographic origin will see different absolute latencies (since service POPs vary by region) but should see the same relative ranking trends over a 7-day window. Discrepancies of more than 1 percentile rank between independent replications should be filed as GitHub issues. - -## 9. Statistical power statement - -At V0-Lean cadence (1 / h × 1 region × 5 services) a single service accumulates 168 probes per rolling 7-day window. With this sample size : - -- `p50_latency_ms` standard error ≈ ±5 % at typical service variance -- `p99_latency_ms` standard error ≈ ±15 % (broad; published with confidence interval) -- Difference in `landing_rate` between two services detectable at 5 pp gap, p < 0.05, after ~18 days of data - -For sub-weekly resolution, cadence must increase. Any such change ships as a public PR + 14-day comment window. - -## 10. Limitations (explicit) - -- **Single-region**: latency reflects what a us-east client sees. Services with non-us-east-anchored POPs may rank differently from sgp or eu-west. -- **Synthetic payload**: a 1-lamport self-transfer + memo is the smallest valid mainnet tx. Real trading payloads (Jupiter swap, Raydium add-liquidity) are heavier and may behave differently in tip elasticity. The bench does not extrapolate. -- **Fixed tip per service**: the bench measures landing performance *at one tip level*. A service that lands at 99 % for 1 M lamports may land at 50 % for 100 k lamports. The bench does not characterize the tip elasticity curve in V0-Lean. -- **Fan-out attribution**: §6 partially handles Helius / Astralane / Nozomi fan-out via the Jito control probe, but does not produce a derived "service-net" published metric in V0-Lean. -- **Confirmation level**: we use `confirmed` (1+ confirmation). A service that lands at `processed` but never reaches `confirmed` would be undercounted. We do not currently publish a `processed` series. -- **Mainnet incidents**: when Solana mainnet halts or congests beyond 60-second confirmation, all services rank identically high in `dropped{reason=timeout}`. The bench page must surface a "chain health overlay" so readers can distinguish service problems from chain problems. -- **Geographic biases**: services with no us-east POP (none in the V0-Lean scope) are penalized vs services with one. We disclose POP locations in the bench page methodology block. - -## 11. Sponsor independence - -Sponsorship contracts (when present) follow a fixed public template with these clauses : - -- Sponsors fund operations and receive newsletter visibility, case studies, integration support. Never leaderboard influence, advance results, or methodology changes. -- The non-suppression clause grants the sponsor a single remedy for unfavorable results : terminate the agreement and receive a pro-rata refund. Never edit, delay, or selectively publish. -- Methodology changes (this document) ship as PRs and are independent of sponsor contracts. - -## 12. Change log - -| Version | Date | Change | -|---|---|---| -| v1.0 | 2026-05-21 | Initial pre-registration. V0-Lean scope : 5 services × 1 region × 1 / h. | -| v1.1 | 2026-05-21 | Pre-launch reconciliation with implementation : metric names from `ocb_solana_landing_*` to `solana_landing_probe_*` (matches sibling OCB benches), `rate_limited` added as 4th drop reason, latency_ms histogram bucket list adjusted to include 250 ms and 30 s, blockhash commitment rationale clarified, memo format clarified (`ocb---` where cycle_id is itself the 8-byte random hex shared across all per-service probes in the cycle), `solana_landing_probe_enabled` gauge added so dashboards distinguish "prober disabled" from "prober stuck". | -| v1.2 | 2026-05-23 | `getSignatureStatuses` poll interval reduced from 1 s to 200 ms after the first 7 days of live data showed all services collapsing to identical 1.0 s p50. The 1 s poll was the measurement floor (Solana confirmed status arrives in ~400 ms-1 s), so 200 ms restores 5x the resolution. Bench page queries also switched from `histogram_quantile` on the latency_ms histogram to `quantile_over_time` on the latency_ms gauge, since the histogram bucket list only had ~3 buckets in the 1-5 s zone where probes actually land, collapsing p50 to bucket midpoints. | -| v1.3 | 2026-05-23 | Primary observation path switched from HTTP polling to `signatureSubscribe` over the public mainnet WebSocket (`wss://api.mainnet-beta.solana.com`). The RPC pushes the notification at the instant the commitment level is reached, so resolution is RTT-bounded (~30-50 ms us-east → mainnet-beta) rather than poll-cadence-bounded. Subscription is registered BEFORE submission to prevent missing fast confirmations. HTTP polling at 200 ms remains an automatic fallback if the WebSocket connect fails. Validated locally against mainnet-beta with end-to-end slot and signature subscribe tests before deploy. | -| v1.4 | 2026-05-23 | Nozomi endpoint switched from `https://ewr.nozomi.temporal.xyz/` (Newark, region-pinned) to `http://edge.nozomi.temporal.xyz/` (geo-routed DNS, HTTP). Reason: Railway us-east is Ashburn, the previous endpoint forced a cross-region hop adding ~30 ms RTT. The geo-routed DNS resolves to the POP closest to the caller. HTTP instead of HTTPS skips the TLS handshake on the hot path (Solana tx is already signed so plain-text body is not a confidentiality risk - the signature is public the moment the tx is on chain). Change requested by Jakob @ Temporal Labs on 2026-05-23 and applied to all probes from the same region. The same review pass is open for Jito / Helius / Astralane / 0slot - any service whose **publicly-documented** best-practice configuration differs from what we currently probe is invited to file an issue or PR. We do NOT accept private deals to alter the probe surface for any single service; we DO apply optimisations that the service publishes as their standard production recommendation. | -| v1.5 | 2026-05-24 | Two further Nozomi refinements per Jakob @ Temporal Labs follow-up. (a) Endpoint moved from `edge.nozomi.temporal.xyz` (JSON-RPC sendTransaction) to `http://edge.nozomi.temporal.xyz/api/sendBatch?c=` (binary `[u16_BE_len][tx_bytes]` framing, `Content-Type: application/octet-stream`). Per Jakob, this batch endpoint handles single-tx submissions and is the path most clients use. Implementation: single-tx wrap in the batch container. (b) Tip wallet switched from the saturated main wallet `TEMPaMeCRFAS9EKF53Jd6KpHxgL47uWLcpFArU1Fanq` to a non-saturated wallet `nEFs3jph8HJt7honu3k7XtGUufMnwAvSXmXcKSPxryP` recommended by Jakob; the main wallets receive heavy MEV-load traffic and clients typically rotate over less-busy alternates. The `TEMPaMe...` wallet remains in the Nozomi tip-wallet list as a fallback for the v1 anti-fingerprint randomisation feature. No change to tip floor (1 000 000 lamports). | diff --git a/harnesses/solana-tx-landing/README.md b/harnesses/solana-tx-landing/README.md index 1ea5e8f4..9c69b4e5 100644 --- a/harnesses/solana-tx-landing/README.md +++ b/harnesses/solana-tx-landing/README.md @@ -1,9 +1,10 @@ # solana-tx-landing harness -Source for two OpenChainBench benches that share a single binary: +Source for the OpenChainBench bench: - [`solana-tx-landing`](https://openchainbench.com/benchmarks/solana-tx-landing) — observational market-share view of Solana transaction landing services (Jito, Helius Sender, Nozomi, Astralane, 0slot, etc.) measured via on-chain tip-wallet attribution. -- [`solana-tx-landing-latency`](https://openchainbench.com/benchmarks/solana-tx-landing-latency) — active probing: a synthetic 1-lamport self-transfer submitted through each service, timing the slot delta to confirmation. See [`docs/methodology/solana-tx-landing-active.md`](../../docs/methodology/solana-tx-landing-active.md) for the pre-registered methodology. + +The binary also embeds an opt-in active prober (slot-delta latency), kept around for re-enablement but not currently wired to a public bench page on OCB. Exposes Prometheus metrics on `:2112/metrics` (OCB Railway convention). @@ -56,7 +57,7 @@ curl localhost:2112/metrics | grep solana_landing | `LOGS_TOKEN` | (unset) | Optional, gates `/logs?tail=N` | | `SLACK_WEBHOOK_URL` | (unset) | Optional, posts probe failures + low-balance alerts | -See [`docs/methodology/solana-tx-landing-active.md`](../../docs/methodology/solana-tx-landing-active.md) for the exact probe payload, tip floors per service, and statistical thresholds. +The probe payload, tip floors per service, and statistical thresholds are documented inline in `cmd/script/prober.go` and `cmd/script/senders.go`. ## Reproducibility diff --git a/harnesses/solana-tx-landing/cmd/script/active_metrics.go b/harnesses/solana-tx-landing/cmd/script/active_metrics.go index 2f16dce5..ddca8171 100644 --- a/harnesses/solana-tx-landing/cmd/script/active_metrics.go +++ b/harnesses/solana-tx-landing/cmd/script/active_metrics.go @@ -16,9 +16,8 @@ import ( // • landing_rate = success_total / (success_total + dropped{reason=timeout}) // • p50 / p99 derived in Prom from the *_histogram series // -// Methodology pinned at docs/methodology/solana-tx-landing-active.md -// (OpenChainBench repo). Any label / metric change is a methodology PR -// with the 14-day comment window. +// Label / metric shape is stable; any change should ship as a public PR +// with a 14-day comment window before redeploy. var ( // One increment per landed (confirmed) probe. Headline numerator of diff --git a/harnesses/solana-tx-landing/cmd/script/main.go b/harnesses/solana-tx-landing/cmd/script/main.go index 2e1fdd05..73893eec 100644 --- a/harnesses/solana-tx-landing/cmd/script/main.go +++ b/harnesses/solana-tx-landing/cmd/script/main.go @@ -53,7 +53,6 @@ func main() { go runSubscriber(ctx, wsURL) // Active prober (opt-in: requires SOLANA_PROBE_KEYPAIR_BASE58). - // Methodology: docs/methodology/solana-tx-landing-active.md go runProber(ctx) sig := make(chan os.Signal, 1) diff --git a/harnesses/solana-tx-landing/cmd/script/prober.go b/harnesses/solana-tx-landing/cmd/script/prober.go index 42e127db..e5bbe1f5 100644 --- a/harnesses/solana-tx-landing/cmd/script/prober.go +++ b/harnesses/solana-tx-landing/cmd/script/prober.go @@ -22,8 +22,7 @@ import ( // Active prober — submits a synthetic mainnet tx through each landing // service every cycle, then polls confirmation. Headline metrics = -// landing_rate + p50/p99 latency per service. Methodology pinned at -// OpenChainBench/docs/methodology/solana-tx-landing-active.md. +// landing_rate + p50/p99 latency per service. // // The prober is OPT-IN. It only runs when SOLANA_PROBE_KEYPAIR_BASE58 // is set; absence keeps the harness in pure observational mode. diff --git a/src/app/answers/[slug]/page.tsx b/src/app/answers/[slug]/page.tsx index 5a31c97f..d6023f25 100644 --- a/src/app/answers/[slug]/page.tsx +++ b/src/app/answers/[slug]/page.tsx @@ -46,10 +46,10 @@ export async function generateMetadata({ if (!ans) return {}; const title = ans.seo_title ?? ans.question; const descSource = ans.seo_description ?? ans.short_answer; - // Clean leftover tokens AFTER renderTemplate so a draft bench - // (e.g. solana-tx-landing-latency mid-soak) never leaks a literal - // `{{best_name}}` into the meta description, og:description or - // twitter:description, all of which feed the SERP and social previews. + // Clean leftover tokens AFTER renderTemplate so a draft bench never + // leaks a literal `{{best_name}}` into the meta description, + // og:description or twitter:description, all of which feed the SERP + // and social previews. const description = capDescription( cleanLeftoverTokens(renderTemplate(descSource, ans.bench)), 158, diff --git a/src/app/answers/page.tsx b/src/app/answers/page.tsx index 5bcaa448..0a13c68f 100644 --- a/src/app/answers/page.tsx +++ b/src/app/answers/page.tsx @@ -28,10 +28,9 @@ export default async function AnswersHubPage() { // before the JSX touches the string. // // Tokens that renderTemplate can't resolve get a neutral fallback so - // a draft / awaiting-data bench (e.g. solana-tx-landing-latency mid-soak - // with every provider's p50 still at 0) never surfaces raw `{{best_name}}` - // to the SERP. Same pattern as resolveLeftoverPlaceholders on the - // per-chain bench page. + // a draft / awaiting-data bench (every provider's p50 still at 0) + // never surfaces raw `{{best_name}}` to the SERP. Same pattern as + // resolveLeftoverPlaceholders on the per-chain bench page. const rendered = await Promise.all( answers.map(async (a) => { const bench = await loadBenchmark(a.benchmark, { chain: a.chain }); diff --git a/src/data/bench-published.json b/src/data/bench-published.json index fc0f53c9..0dc2c4f1 100644 --- a/src/data/bench-published.json +++ b/src/data/bench-published.json @@ -13,7 +13,6 @@ "perp-fees": "2026-05-07T14:44:23.000Z", "pm-data-freshness": "2026-06-04T17:50:08.000Z", "rpc-capabilities": "2026-05-20T18:43:56.000Z", - "solana-tx-landing-latency": "2026-05-21T17:54:38.000Z", "stablecoin-peg": "2026-05-20T18:43:56.000Z", "stablecoin-peg-usdt-anchored": "2026-05-20T21:20:02.000Z", "token-deployment-cost": "2026-06-09T15:34:12.000Z", diff --git a/src/data/compare-pairs.ts b/src/data/compare-pairs.ts index a7a5148b..786994d1 100644 --- a/src/data/compare-pairs.ts +++ b/src/data/compare-pairs.ts @@ -157,15 +157,6 @@ export const COMPARE_PAIRS: ComparePair[] = [ providerB: "hyperliquid", publishedAt: "2026-06-17", }, - { - // solana-tx-landing-latency exposes the Helius RPC sender under the - // slug `helius-sender`, not bare `helius`, so the pair canonical - // slug uses helius-sender to match the bench provider id. - slug: "helius-sender-vs-jito", - providerA: "helius-sender", - providerB: "jito", - publishedAt: "2026-06-09", - }, { slug: "hyperliquid-vs-lighter", providerA: "hyperliquid",