Quicknode

April 14, 2026 — 6 min read

WebSockets are the default for Solana developers who need real-time onchain data, with broad compatibility across front-end and mobile applications and a simpler path than gRPC for event-driven backends.

But Solana's native WebSocket implementation was never built to handle large volumes of data at scale. A third of the API is officially marked unstable, the PubSub drops messages under load, and most applications are quietly compensating with workaround layers that shouldn't be necessary.

We built Blazar to fix that at the source.

What is Blazar?

Blazar is Quicknode's in-house Solana WebSocket engine, built from scratch and optimized specifically for the workloads Solana developers run in production. It is not a fork of any open source solution or a wrapper around Agave's native PubSub. It implements the complete set of Solana WebSocket subscription methods against your existing Quicknode Solana endpoint, with no SDK changes or migration required.

Blazar is faster, more reliable, and more complete than anything built on Agave's native PubSub. It handles large concurrent subscriber counts without degradation, and maintains consistent delivery where Agave's native PubSub would start dropping messages.

Beyond the performance fundamentals, it also brings stable support to subscription methods that most providers can't reliably offer.

Previously Unstable Methods, Now Production-Ready

Solana's WebSocket API offers nine subscription methods. Three of them, voteSubscribe, slotsUpdatesSubscribe, and blockSubscribe, are officially marked unstable in the latest Agave 3.x validator client and effectively inaccessible on standard Solana WebSocket connections.

For developers who need block data, vote information, or detailed slot status updates, these are essential methods, not edge cases.

voteSubscribe

voteSubscribe delivers vote transactions as they are executed at the processed commitment level, before the slot is confirmed and before any finality guarantee exists. Due to its instability, it has been largely inaccessible to most application developers. On Blazar it's available and reliable, opening up tooling for estimating optimistic confirmation, vote participation dashboards, or Stake-weighted block finality tracking.

slotsUpdatesSubscribe

slotsUpdatesSubscribe exposes the full lifecycle of a slot, from firstShredReceived through completed, optimisticConfirmation, and eventually rooted. That granularity matters if you're benchmarking end-to-end latency and need to know exactly when the network first saw a slot versus when your application did. It also lets you trigger logic at optimisticConfirmation, the earliest point where a slot is practically safe to act on, without polling or waiting for full finality. Previously, getting this kind of slot-level signal reliably meant running your own validator infrastructure. On Blazar it comes through your standard WebSocket connection.

blockSubscribe

blockSubscribe is effectively unavailable on native Solana WebSocket connections. When it does appear, high transaction volume routinely causes oversized message errors, disconnects, or silently dropped data. On Blazar, it's fully supported and stable, making block-level subscription data a viable option in a way it hasn't been before.

Extended Method Support

Blazar also supports transactionSubscribe, a method originally introduced by Triton as part of their Whirligig WebSocket proxy. It is not part of the standard Solana WebSocket API but has become a widely adopted extension for developers who need more granular transaction data than ログの購読 または accountSubscribe provide. The method lets you filter by account, transaction outcome, and commitment level, making it practical for tracking program activity in real time, alerting on failed transactions, or building a live swap feed without polling.

Performance Advantages

We benchmarked Blazar against the most widely used open-source Solana WebSocket proxy under real mainnet conditions. Here's what we found.

Reliable Delivery

Agave's native PubSub mechanism runs on a single worker thread by default, bottlenecking all subscription processing regardless of available cores. Under heavy network load, exactly when real-time data matters most, the native PubSub system will drop messages and introduce unpredictable latency spikes.

Blazar is purpose-built to eliminate these failure modes. Under the same heavy load conditions, Blazar delivered stable, consistent results:

Faster Data From the Source

Standard RPC infrastructure receives data through the broader Turbine network, which means events arrive further down the propagation path. Blazar's upstream data source is powered by ShredStream, receiving shreds from the top 100 Turbine leaders. A shredstream-enabled source delivers data roughly 200-250ms faster than a regular public Turbine source. That head start is built into every event before Blazar begins processing.

The latency Blazar adds between an onchain event and your application receiving it is under 1ms, even under heavy load. This applies to account updates, full blocks, and all other subscription types.

Blazar gives customers data significantly sooner than the most common WebSocket server in every scenario tested. 200 connection tests use the SysvarClock account to ensure the account is constantly updating.

Scales Without Degrading

Each Agave node handles a finite number of WebSocket subscribers before performance degrades for all of them, requiring additional hardware and more operational complexity. Blazar handles large numbers of concurrent subscriptions without degrading per-subscriber performance. Every subscriber receives consistent, low-latency delivery regardless of total subscription count.

Memory usage on Blazar is significantly reduced in all cases.

Blazar significantly reduces CPU usage in most cases.

Benchmarks ran in a controlled, isolated environment with clients connected directly to the server from a separate machine, with no load balancer or edge layer in between.

What This Means For Developers

For developers building on Quicknode, Blazar changes what you can assume about your WebSocket connection:

• Fewer workarounds. Retry logic, gap detection, and redundant connections exist to compensate for unreliable delivery. With Blazar handling reliability at the infrastructure level, that compensating code becomes unnecessary.

• Complete data streams. When your application receives a notification, the events preceding it arrive too. Build your logic on the assumption that the stream is continuous.

• Predictable performance at scale. Subscription performance does not degrade as connection count increases. Your application won't hit a performance cliff as it grows.

Blazar isn't a separate product, an add-on, or a premium tier feature. It's a free upgrade to every Quicknode Solana WebSocket endpoint, already rolled out across all plans. There's nothing to enable, nothing to migrate, and nothing extra to pay for.

はじめに

1. Log in to your Quicknode dashboard.

2. Select your Solana endpoint.

3. Copy your WSS endpoint URL and connect using your existing WebSocket client code.

New to Solana WebSockets? The How to Create WebSocket Subscriptions to Solana Blockchain Using TypeScript guide covers everything you need.

The Bottom Line

Blazar removes the reliability and performance ceilings that Solana's native WebSocket implementation imposes by delivering sub-millisecond processing overhead, stable support for all nine subscription methods, including the three marked unstable in Agave, and benchmark performance that holds at scale.

WebSockets remain one of the easiest ways for developers to get real-time onchain data. Now the infrastructure behind it matches what it actually demands. Log in to your Quicknode dashboard to get started.