Measured, not marketed. The headline number below is computed live from production — we reconcile every detected launch against its on-chain confirmation, continuously — and the one-off comparisons are dated, sampled, and described down to their error bars.
Measured 8 October 2026 · four separate measurement categories
+314.1 ms
median lead over confirmed notifications for 215,877 trades; earlier in 98.5% (2026-10-08, one client in OVH, Limburg (Germany))
+16.4 ms
median lead over processed notifications for the same trades; earlier in 62.7%, with long tails both ways
4 of 6 channels
had enough matches to time in 10 minutes; the rest are reported as not (sufficiently) measured
One client in OVH, Limburg (Germany) (a server at a different provider and network from our production server) connected to wss://madeonsol.com/ws/v1/early with a normal ULTRA stream token and subscribed to all six channels (server early-stream 52b97bf0 (six channels, outcomes from the finalized-status stream)). On the same machine it received Kaldera Yellowstone gRPC transaction notifications (transactions_status) from Frankfurt, received on the same client: one stream at PROCESSED and a separate one at CONFIRMED. Filter: accountInclude: pump.fun, PumpSwap, Streamflow, Jupiter Lock, Bonfida, Token-2022, Raydium LaunchLab; failed transactions included; vote transactions excluded. 10 minutes measured after a 60 s warm-up, with a 30 s tail buffer.
Every receipt was stamped on the same monotonic clock and written to disk during the run. Only early observations are compared (never the later outcomes), matched to the reference by transaction signature and slot, first receipt per channel and signature. Lead = reference receipt minus early receipt: positive means our observation arrived first. Negative results are kept, and percentiles are shown only with at least 30 matched pairs.
| Channel | Observations | vs processed: earlier | vs processed: lead | vs confirmed: earlier | vs confirmed: lead |
|---|---|---|---|---|---|
| Trades | 215,877 | 62.7% | -94.7 ms / +16.4 ms / +553.3 ms | 98.5% | +106.5 ms / +314.1 ms / +749.3 ms |
| Launches | 605 | 60.5% | -92.7 ms / +9.9 ms / +508.5 ms | 98.3% | +104.6 ms / +312.3 ms / +759.2 ms |
| Token changes (Token-2022) | 3,268 | 47.9% | -105.5 ms / -2.0 ms / +553.8 ms | 99% | +119.1 ms / +331.6 ms / +796.4 ms |
| Liquidity | 37 | 40.5% | -231.2 ms / -7.2 ms / +305.9 ms | 94.6% | -3.1 ms / +272.8 ms / +535.9 ms |
| Migrations | 24 | Not sufficiently measured (24 matched) | Not sufficiently measured (24 matched) | ||
| Locks | 3 | Not sufficiently measured (3 matched) | Not sufficiently measured (3 matched) | ||
| Token changes (SPL Token) | 326 | Not measured: no reference: the provider refuses an SPL Token transaction-notification filter | |||
Matched pairs: every observation in the measured channels had a reference with the same signature and slot (unmatched 0), except SPL Token token changes, which have no reference. SPL Token (TokenkegQ...): the provider refuses this filter for transactions_status, so SPL Token token changes have no reference and are not measured.
What this shows: against confirmed notifications the early observation arrived first in 94.6% to 99% of matched pairs per channel, with medians of +272.8 ms to +331.6 ms. Against processed notifications the medians are close to zero (-7.2 ms to +16.4 ms), with long tails in both directions: early was first in 62.7% of trades and 60.5% of launches. This is not an "always before processed" result.
These are customer-side leads measured over the public internet. They are not the internal processing time on our server (receive to publish, separately reported on the solution page). During the run the client received 38 queue_stale gap frames (one burst) and 0 disconnects. The benchmark client was not a bottleneck: event-loop delay at most 34 ms on the early feed, no write backpressure.
Customer benchmark by channel, summary (JSON) · Matched pairs: all non-trade observations, every 20th trade (CSV) · Method for this run
One client in the Netherlands (residential ISP, through Cloudflare to madeonsol.com), Node v24.12.0, ws 8.21.3, against early-stream 84ea4aec (six channels). 30 minutes of admission in 3 separate windows. Early observations and the MadeOnSol DEX firehose (Kaldera Yellowstone gRPC, confirmed commitment, successful transactions only) arrived in the same process and were timestamped on one monotonic clock, then matched by transaction signature and slot.
| Compared with | p50 | p95 | p99 | Matched / ref. unmatched | Result |
|---|---|---|---|---|---|
| Processed | Not measured in this run | ||||
| Confirmed | 290.0 ms | 458.9 ms | 1448.9 ms * | 515 / not countable | 100% earlier |
Processed: Not measured on the customer path: our processed-commitment feed is only reachable inside our production network, and a measurement there would not be customer-side.
* p99 is uncertain: uncertain: n=515 (p99 rests on 6 sample(s)).
| Window | Early | Matched | Earlier | p50 | p95 | p99 |
|---|---|---|---|---|---|---|
| Window 1 (08:04 to 08:14 UTC) | 277 | 189 | 100% | 279.1 ms | 448.2 ms | 730.2 ms |
| Window 2 (08:15 to 08:25 UTC) | 221 | 162 | 100% | 303.0 ms | 424.8 ms | 762.7 ms |
| Window 3 (08:27 to 08:37 UTC) | 209 | 164 | 100% | 287.0 ms | 479.3 ms | 1832.2 ms |
192 early launches had no reference match (23 failed on chain, 169 succeeded). Failed launches never appear in the reference, which carries successful transactions only. Successful launches without a developer buy in the create transaction produce no trade frame, the likely reason for the rest (not proven per transaction).
| Sampled early trades | Matched | Earlier | p50 | p95 | p99 |
|---|---|---|---|---|---|
| 41,928 | 9,784 | 99.49% | 297.7 ms | 481.1 ms | 1668.6 ms |
Matched pairs only, from a 1-in-10 sample of pump.fun and PumpSwap transactions. 32,144 sampled early trades and 4,187 reference trades stayed unmatched (early trade intent includes failed instructions; venue tagging and outer-instruction scope differ), so this is not a coverage figure.
| Channel | Observations | Outcomes |
|---|---|---|
| early:trades | 496,191 | 494,708 |
| early:token_changes | 81,661 | 83,305 |
| early:deploys | 813 | 1,782 |
| early:liquidity | 140 | 138 |
| early:migrations | 47 | 47 |
| early:locks | 5 | 5 |
A channel with few or no events in a short window is no sample, not a broken channel or proof of coverage.
0 duplicate observations, 5 gap frames. All gap frames were lookup-table timeouts scoped to the trade-side channels, none for launches. Both sockets dropped once at the same moment (08:27:57 UTC, close code 1006, likely the client network path) and reconnected without resume, so window 3 has a short blind interval.
Download the raw customer measurement. One client, region and window: not a fixed or guaranteed head start.
A probe on our production host consumed the early stream and the confirmed DEX firehose over local ports with one clock. It shows the relative arrival of the two feeds inside our network, without Cloudflare or a customer connection. Per-transaction samples were not kept for these release checks; the file holds the summary distributions.
| Run | Matched | Earlier | Lead p5 | Lead p50 | Lead p95 | Receive to publish p50 |
|---|---|---|---|---|---|---|
| Deploys-only release check after the HTTP/2 flow-control window fix (2c4828ad, deploys) | 98 | 100% | 183 ms | 306 ms | 486 ms | 1 ms |
| Six-channel final validation (84ea4aec, all) | 118 | 100% | 172 ms | 303 ms | 445 ms | 1 ms |
Go-live monitor 2026-10-08T05:55:19Z to 2026-10-08T06:12:55Z: 0 restarts, no gap reasons, receive-to-publish p50 at most 1.981 ms, 511 launches and 312,153 other channel events decoded. Internal host path: no Cloudflare, no WAN, no customer network. Not a customer head start.
| Mode | p50 | p99 |
|---|---|---|
| Sniper / reference codec | 0.402 ms | 1.385 ms |
| Six families / reference codec | 1.753 ms | 3.037 ms |
| Six families / optimized codec | 0.422 ms | 1.060 ms |
300 measured batches, 19,200 unsigned synthetic transactions per mode after 30 warmups, mixed legacy/v0/v1 and identical output hashes for the six-channel modes. Node v24.19.0, INTEL(R) XEON(R) PLATINUM 8573C. Excludes provider transport, worker queues, sockets, real DB/RPC and cold address lookups. This measures decoder work, not the time a user receives a signal.
| Format / checkpoint | Run 1 | Run 2 | Run 3 | Observation bytes |
|---|---|---|---|---|
| Before / full | 73.823 ms | 179.848 ms | 110.826 ms | Not recorded |
| After / full | 54.727 ms | 65.468 ms | 60.448 ms | 3,894,756 |
| After / compact-v1 | 67.557 ms | 63.422 ms | 76.516 ms | 3,221,476 |
| After / mixed | 72.877 ms | 69.947 ms | 62.721 ms | 3,558,116 |
Each run submits eight simultaneous 60-transaction batches to a real worker/gateway/journal, with eight healthy clients plus one paused socket, mock DB/status RPC and no provider or WAN. Timing ends in a separate client message handler, including JSON parsing and compact expansion. All expected healthy-client observations arrived with zero reported gaps. Accounting success does not prove a production latency target; eight batches cannot establish sustained peak capacity.
Compact saved 17.3% of observation bytes in this corpus. Its median of the three p99 samples was 67.557 ms, versus 60.448 ms for full JSON. This is a bandwidth option, not a demonstrated latency improvement. Cold-host variance and all baseline outliers are retained.
The client-side benchmark used the public discovery and WebSocket endpoints from a machine outside our network; the core probe ran on our production host; the local checkpoints ran on a development machine with synthetic input. lead_ms = reference receipt minus early receipt on one monotonic clock; positive means the early observation arrived first. Solscan block timestamps provide chain context, not millisecond receipt evidence.
The launch reconciliation and historical feed races below are not a customer-receipt benchmark for the six-family ShredPrism expansion. Do not transfer their lead figures to the new stream. The dated customer benchmark for ShredPrism, per channel against processed and confirmed notifications, is on the solution page.
Our pre-execution pipeline reconstructs pump.fun deploys from shred-level data before the validator has executed them. Every detection is stamped, then reconciled against the confirmed stream's arrival — so this head start is a continuously self-audited production metric, not a benchmark we ran once. The figures below cover every reconciled deploy of the last 24 hours, including the launches where the confirmed stream reached us first — those count as a negative head start, and the “detected first” figure shows how often we win the race.
Live stats are momentarily unavailable — refresh shortly.
We raced our detection stream against a leading specialist pump.fun shred-feed provider (the class of feed sniper bots build on), live, on the same machine clock: their public WebSocket delivery vs our detection timestamp, per token.
Races won
91%
155 of 170 launches
Median lead
164ms
we delivered first
Internal overhead
1ms
detection → delivery bus, p50 (n=204)
Sample
170
consecutive live launches
For freshly created tokens, we polled the most widely used public aggregator's token API every 3 seconds from the moment our pipeline detected each launch, until the token became visible there.
Median lead
~61s
until aggregator visibility
Fastest aggregator case
+30s
slowest +63s (±3s sampling)
Sample
15
consecutive launches, zero misses
Probed every 5 minutes from an independent server at a different provider, over the public internet, with a real API key — the customer path, not localhost.
REST p50
84ms
authenticated request
REST p95
143ms
WebSocket p50
114ms
connect + first frame
WebSocket p95
176ms
sniper:deploysWebSocket channel and webhooks; REST endpoints serve confirmed, committed state.