Solana gRPC providers, sourced.

It's the wall-clock time between the Solana validator confirming a slot (the moment the block is finalized on the validator's side) and the gRPC client's Subscribe() callback receiving the corresponding message. This is the end-to-end number a trading bot actually cares about — it combines validator-to-Geyser-plugin latency, provider-to-edge network latency, and client-side gRPC decode. It does NOT include your bot's business logic or transaction submission time.

Three reasons stack: (1) we run Yellowstone directly on our own validators colocated in Amsterdam and Frankfurt, eliminating the validator-to-provider hop that shared-infrastructure providers incur. (2) We ship pre-parsed JSON server-side, so your client skips the Borsh decode on every transaction — we estimate 15–30ms for a typical instruction in a non-optimised client. (3) Our gRPC edge nodes run on bare metal with 10Gbps uplinks, so there is no shared Kubernetes pod noise. Our measured slot-to-client p50 on colocated routes sits at 30–80ms. That is a comparison against public RPC polling, not against another gRPC provider: we do not hold accounts on the other providers on this page and make no claim about beating them on wire latency, particularly outside Europe.

This is the right way to settle it, and it is why we would rather you ran it than took our word. Subscribe to the same Solana program (we use Pump.fun, program 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P) on two providers simultaneously from the same machine. Record the wall-clock time at Subscribe.Recv() for each incoming transaction, matched by transaction signature, and compute the delta. Run for at least 1 hour over the US market open, when Pump.fun activity peaks. The provider whose message arrives first won that transaction; aggregate win-rates across hundreds of samples. Because every provider here is Yellowstone wire-compatible, one client can point at both endpoints in turn with no code changes. Run it from your own region — results are location-dependent, and a provider with an endpoint near you will beat one without.

For Pump.fun bonding-curve tokens, absolutely. Prices can move 5–15% within a single slot during active trading. A 400ms latency delta translates directly to fill-price delta on fast-moving tokens. For mid-cap Raydium pairs or analytics pipelines, the difference is smaller — you can run on public RPC and still be profitable. Copy-trade users at scale (>20 SOL bankroll) consistently cite latency as the #1 reason they switch providers.

Bundle inclusion is a separate measurement: from the moment your bot submits a signed bundle to the Jito block engine, to the moment that bundle lands in a Solana slot. This is validator-side, not provider-side — but providers affect it indirectly because they determine how fast you can detect and sign your mirror trade. Subglow submits via our own Jito relay with additional tip auto-bidding logic; inclusion rates sit above 95% for tips above the current 40th-percentile.

Both, and the table labels which is which on every cell. The Subglow latency figures are measured in production over a 30-day rolling window from our own logs — but they are measured by us, on our own infrastructure, so they are a vendor claim like any other until the open harness lands. Everything attributed to another provider is taken from that provider's own documentation or pricing page and linked, or marked Unpublished because they do not publish it. We removed an earlier version of this page that printed p50 and p99 for every provider and described them as measured on a shared harness; we do not hold accounts on most of these providers and that claim was not true.