A WebSocket connection keeps one channel open between your app and a blockchain endpoint, so the endpoint pushes new blocks, logs and account changes to you instead of waiting to be asked. HTTP polling works the other way round: your code asks every few seconds and mostly hears “nothing new.” For anything that has to react to a new Ethereum block or Solana slot, a persistent connection is the standard tool, and it is what people mean when they search for low-latency WebSocket RPC for Ethereum and Solana.
Speed is only half the question, though. The most reliable WebSocket RPC for production is the one that keeps delivering after a drop, and reliability here depends on how you reconnect and backfill as much as on the provider. This guide covers how the protocol differs from HTTP, which subscriptions each chain offers, what drives delay, how providers compare on documented limits, and how to test one before you depend on it.
What Is a WSS Endpoint and How Does It Differ From Request-Response Access?
A WSS endpoint is a wss:// address that upgrades a normal web connection into a long-lived, two-way channel. Once it is open, the client sends JSON-RPC requests and the node sends notifications back on the same connection, without a new handshake each time.
NOWNodes documents the split plainly: HTTP RPC processes each request independently and the client must poll, while WSS keeps a continuous connection and pushes events when they occur. The trade-off is state. Subscriptions live on the connection, so they need more care than a stateless request.
| HTTP RPC | WebSocket (WSS) | |
|---|---|---|
| Connection model | New request per call | One persistent connection |
| Who starts a message | Always the client | Client or node |
| Typical use | Reads, one-off calls, sending transactions | Live blocks, logs, account changes |
| Failure mode | A failed request is retried | A dropped connection silently ends every subscription |
The last row matters most in production, and the second half of this guide returns to it. A dropped socket does not raise an error on its own; it just goes quiet.
Who Needs Real-Time Subscriptions?
Four groups account for most WebSocket traffic: wallets, monitoring and analytics tools, trading and MEV bots, and event-driven backends. Each uses the feed for a different reason.
- Wallets and notification services update balances and alert users when a transfer confirms, without polling every address.
- Monitoring and analytics tools follow block production and aggregate confirmed transactions as they land.
- Trading and MEV bots act on new blocks, pending transactions or account changes, where seconds decide the outcome.
- Event-driven backends run a job when a contract emits a specific log, such as a deposit or a liquidation.
Bots are the audience for whom timing is a hard requirement rather than a convenience. Geth’s own documentation is direct about what subscriptions are and are not for: notifications are sent for current events and not for past events, so use cases that cannot afford to miss any notifications are probably not well served by subscriptions alone. That sentence, from the go-ethereum authors, shapes the production design covered below.
Which Subscriptions Does Each Chain Offer?
Ethereum exposes three main streams through eth_subscribe, and Solana exposes a separate family of *Subscribe methods. They are not interchangeable, and neither chain’s methods work on the other.
Ethereum: eth_subscribe
Ethereum’s subscription API is defined in the go-ethereum documentation. The three types most apps use are:
newHeadsfires each time a new block header is appended to the chain, including during reorganizations, so one height can produce more than one header.logsreturns logs from newly imported blocks that match an address and topic filter. After a reorganization, logs on the old chain are resent withremoved: true, which your code must treat as a retraction.newPendingTransactionsstreams transactions entering the pending pool, before they are in a block.
Two of these have dedicated guides on this blog: contract event logs and the Ethereum mempool. The Ethereum execution API specification also lists eth_subscribe and confirms that removed logs are pushed with removed: true.
Solana: PubSub methods and commitment
Solana’s RPC WebSocket reference lists the native methods. Three cover most needs:
accountSubscribenotifies you when one account’s lamports or data change.logsSubscribestreams transaction log messages that match a filter.slotSubscribesignals each time the validator processes a new slot.
Many of these accept a commitment parameter, and the same reference notes that subscriptions default to finalized when it is left out. That default changes what “real time” means.
| Commitment | What it means | Trade-off |
|---|---|---|
processed | Node has seen the block | Earliest signal, can sit on a fork that is later dropped |
confirmed | Supermajority has voted on the block | Balanced, a few slots behind processed |
finalized | Block is rooted by consensus | Safest, slowest |
Solana’s own guidance is that roughly 5% of blocks do not end up finalized, and that the gap between the latest confirmed and finalized block is typically at least 32 slots, about 13 seconds. Picking finalized by accident can add more delay than any network hop.
What Affects Delay on a Persistent Connection?
Distance, infrastructure type, commitment level, filter size and connection handling all move the number more than the protocol itself does. No single figure applies to every setup, so this guide does not publish one.
- Distance to the endpoint. Every network hop adds delay. A server in Frankfurt reading from a US endpoint pays that cost on each message.
- Shared or dedicated infrastructure. Shared gateways serve many customers at once. Chainstack notes that on shared gateways a WebSocket can close with code 1006 and
ECONNRESET, and suggests reconnect logic or a dedicated gateway. - Node sync and peering. A node that trails the network delivers old data quickly, which is worse than delivering current data a moment later.
- Commitment level. On Solana this is the largest single lever, as the table above shows.
- Filter and payload size. Unfiltered log or program streams are large. Alchemy warns that broad Solana streams, especially unfiltered
programSubscribe, can produce very high bandwidth. - Connection reuse. Opening one connection and reusing it avoids repeated handshakes.
Chain timing sets a floor. Ethereum measures time in 12-second slots, with 32 slots making an epoch, so a new block cannot arrive faster than the slot cadence allows. Solana slots are configured to last about 400 ms but may fluctuate between 400 and 600 ms. Sub-second delivery therefore matters far more on Solana than on Ethereum.
Vendors publish their own latency figures, and they are worth reading as claims rather than facts. Helius states that its Solana WebSocket is up to 200 ms faster than standard Agave RPC-based WebSockets. NOWNodes lists a stream latency of under 200 ms on its gRPC product page, which is a separate product from WebSocket. Neither number substitutes for measuring your own route.
Which Providers Offer Streaming Access on Both Chains?
Several major providers offer WSS for both Ethereum and Solana, but they differ sharply in how they meter it, and most do not publish hard connection caps for every plan. The table below records only what each provider’s own documentation states. It compares WebSocket features and does not rank providers.
Checked on 28 September 2026 against the linked official pages. “Not specified” means the cited page did not state a value.
| Provider | WSS: Ethereum | WSS: Solana | Documented limits | Pricing model |
|---|---|---|---|---|
| NOWNodes | Yes | Yes | Connection and subscription caps not specified. WebSocket not available on the Start plan (pricing) | Request allowance per plan, paid plans from Pro |
| Alchemy | Yes | Yes (docs) | 100 connections on Free, 2,000 on other tiers, 1,000 subscriptions per connection | Billed by bandwidth delivered |
| QuickNode | Yes | Yes (docs) | Response size capped, value “subject to change” | Credits, per response received |
| Chainstack | Yes | Yes (docs) | Connection caps not specified | Each pushed notification counts as one request unit |
| Ankr | Premium plans | Paid plans only (docs) | Not specified | API credits per subscription and per notification |
Two providers are left out on purpose. Infura documents WebSocket subscriptions for Ethereum but does not list Solana among its supported networks. Helius publishes detailed WebSocket limits, including 5 simultaneous connections on Free and up to 1,000 on Professional, but its documentation is Solana-specific, so it does not belong in a both-chains table.
Where each option fits
- NOWNodes covers both chains through one key, with WSS URLs in the form
wss://eth.nownodes.io/wss/{YOUR_API_KEY}andwss://sol.nownodes.io/wss/{YOUR_API_KEY}. It lists WebSocket coverage across 30+ networks, so a team that expands to other chains does not change vendor. The limit to know: the free Start plan excludes WebSocket, and dedicated WSS nodes are available on request for networks or performance needs outside the shared plans. - Alchemy is the only one here that publishes explicit per-connection and per-tier caps, which makes capacity planning simpler. Bandwidth billing rewards tight filters and punishes broad streams.
- QuickNode bills per response received, so cost tracks message volume. Its documentation states a response-size cap without giving the number.
- Chainstack counts each pushed notification as one request unit, and offers a flat-fee Unlimited Node for sustained, high-volume subscriptions.
- Ankr meters both the subscribe action and each notification, with Solana notifications priced higher than other chains, so noisy Solana streams cost more.
How NOWNodes fits into the picture
Beyond WebSocket, NOWNodes also offers gRPC streaming, which is a separate product covering 25+ chains, and dedicated nodes. Webhooks on the platform currently cover only address balance changes on a small set of UTXO chains, so they are not an alternative to WebSocket for Ethereum or Solana. The same account also includes the Blockbook-based WebSocket interfaces documented for several networks, which follow a different subscription model than the JSON-RPC methods described in this guide.
How Do You Test a Streaming Provider Before Production?
Test the connection under the conditions you will run it in: same region, two providers side by side, your real filters. A vendor’s benchmark cannot tell you how your route performs.
- Pick one region for the test client. Run it from the same data center or cloud region your production service will use.
- Open two or more providers at once. Subscribe each to the same stream, for example
newHeadson Ethereum orslotSubscribeon Solana. - Record arrival time for the same event. For a given block hash or slot number, note when each provider first delivers it. The difference between providers is your real latency gap.
- Repeat over hours, not minutes. Include busy periods. Averages hide the slow tail.
- Kill the connection on purpose. Measure how long reconnecting and re-subscribing takes, and whether any events are missed in between.
- Apply your own filters. A
logssubscription for one contract behaves very differently from an unfiltered one.
A minimal Ethereum subscription against a NOWNodes endpoint looks like the example below. Replace YOUR_API_KEY with a key from your dashboard.
import WebSocket from "ws";
const ws = new WebSocket("wss://eth.nownodes.io/wss/YOUR_API_KEY");
ws.on("open", () => {
ws.send(JSON.stringify({
jsonrpc: "2.0",
id: 1,
method: "eth_subscribe",
params: ["newHeads"]
}));
});
ws.on("message", (data) => {
console.log(Date.now(), data.toString());
});For Solana, swap the URL to wss://sol.nownodes.io/wss/YOUR_API_KEY and send slotSubscribe with a commitment where the method accepts one. Log Date.now() on arrival so the two providers’ timestamps can be compared afterwards.
What Should a Production Setup Include?
Assume every connection will drop, and design so that a drop loses nothing. The general practices, including heartbeats, backoff and session replay, are covered in the WebSocket production best practices guide. Only the chain-specific points are covered here.
- Re-create subscriptions after every reconnect. Geth states that subscriptions are coupled to a connection, and closing the connection removes all subscriptions created over it. Reconnecting alone restores nothing.
- Backfill the gap over HTTP. On Ethereum, fetch the missed blocks by number after reconnecting. On Solana, fetch by slot, remembering that some slots produce no block. Notifications are never replayed for you.
- Handle reorganizations. On Ethereum, treat a log with
removed: trueas a reversal. On Solana, choose a commitment level that matches how much rollback you can tolerate. - Keep a fallback provider. A second endpoint on a different provider protects you when one has an outage.
Conclusion
Choosing a WebSocket provider is less about a headline speed number than about three practical questions: which commitment level or filter your workload needs, how the provider meters messages, and how your own route performs. Read the documented limits, test in your own region against at least two options, and build reconnection and backfill on day one. A subscription that silently stops is a bigger risk than one that is a few tens of milliseconds slower.
FAQ
Can I run several subscriptions on one connection?
Yes. Both chains allow multiple subscriptions over a single WebSocket connection, and reusing one connection is usually better than opening many. Providers set their own caps, such as Alchemy’s 1,000 subscriptions per connection.
Do subscriptions consume credits or requests?
Usually, yes, and the rules differ by provider. Some meter by message received, some by bandwidth, and some also charge for the subscribe action, so check the pricing model in the table above before you subscribe to a busy stream.
How does WebSocket compare with gRPC streaming on Solana?
Both push data as it happens. WebSocket carries JSON and is the simplest to adopt, while gRPC carries typed binary messages and suits high-volume pipelines. On NOWNodes the two are separate products, and gRPC is listed for 25+ chains.
Does a WebSocket give me events I missed while disconnected?
No. Notifications describe current events only, so anything that happens during a disconnect must be recovered with a normal HTTP query after you reconnect.
