Tatum WebSocket: Stream Blockchain Data in Real Time

Written by
Ted Bloquet
July 27, 2026
min. read
Futuristic Web3 portal connecting a laptop and blockchain nodes across a glowing purple digital landscape.

Modern blockchain applications are expected to react as soon as something happens on chain.

A wallet should show a transaction update without delay. A block explorer should display new blocks as they are produced. A DeFi backend may need to respond to a smart contract event, liquidation, or pending transaction almost immediately.

Polling can handle some of these use cases, but it is not an efficient foundation for live blockchain data. Applications repeatedly ask an RPC endpoint whether anything has changed. Most requests return no new information, while events that happen just after a request remain invisible until the next polling cycle.

Tatum now supports WebSocket subscriptions for Ethereum, Polygon, and Solana.

With one persistent connection, your application can subscribe to specific blockchain events and receive JSON data as soon as those events become available. Instead of repeatedly asking for updates, your application listens for them.

This makes it easier to build responsive wallets, explorers, monitoring systems, DeFi applications, and other products that depend on real time blockchain data.

Why polling is not ideal for real time blockchain data

HTTP RPC works well when your application needs a specific piece of information.

For example, you might request an account balance, retrieve a transaction, or query a historical block. The application sends a request, receives a response, and closes the interaction.

Live applications have a different requirement. They need to know when something changes, even if the application did not make a request at that exact moment.

A polling based wallet might check for a transaction update every five seconds. Most of those requests will return the same status. If the transaction is confirmed immediately after a request, the wallet may not display the update until the next interval.

Reducing the polling interval can improve responsiveness, but it also creates more requests, more empty responses, and more infrastructure overhead.

WebSockets use a different model. The application opens a connection, creates a subscription, and waits. When a matching event occurs, the server sends the update through the open connection.

The result is a more direct path between an on chain event and the application that needs to process it.

What is a blockchain WebSocket?

A WebSocket is a protocol for maintaining a persistent, two way connection between a client and a server.

The connection begins with an HTTP upgrade request. After the upgrade is accepted, both sides can send messages without opening a new connection for every request.

This is different from traditional HTTP, where the server generally responds only after receiving a request.

In blockchain systems, WebSockets are commonly used with JSON RPC subscription methods. The client sends a subscription request containing an event type and optional filters. The node or gateway then sends matching updates as they become available.

A WebSocket connection can be secured with TLS through the wss:// scheme. Tatum WebSocket endpoints use this secure connection format.

WebSockets do not make blocks arrive faster or change transaction finality. Their benefit is that your application does not need to wait for the next polling request to discover new data.

WebSockets vs. the traditional HTTP request/response model

WebSockets Vs gRPC Vs JSON-RPC

WebSockets are the simplest way to start consuming real time blockchain events through a standard web protocol.

For wallets, dashboards, explorers, DeFi applications, and moderate volume backend services, WebSockets are often the most practical choice. They use JSON payloads, work across common client environments, and do not require generated Protocol Buffers clients.

gRPC is designed for a different type of workload. It uses HTTP/2 and Protocol Buffers to provide strongly typed schemas, compact binary messages, and high throughput streaming.

That makes gRPC a better fit for indexers, trading infrastructure, analytics pipelines, and backend systems that process large volumes of blockchain data.

RequirementWebSocketsgRPC streamingTransportWebSocketHTTP/2Data formatJSONProtocol BuffersInteraction modelEvent subscriptionData streamType safetyRuntime payloadsStrongly typed schemasIntegration effortLowerHigherBest suited toWallets, dashboards, explorers, DeFi appsIndexers, trading systems, ingestion pipelinesRecoveryReconnect and resubscribeReconnect and restore stream state

The choice depends on the application rather than a universal performance ranking.

Use WebSockets when you need real time, filtered blockchain events with straightforward integration. Consider gRPC when high throughput, binary transport, generated clients, and strict schemas are central to your backend architecture.

Both approaches are push based and remove the need to rely on frequent polling for live data.

WebSocket vs gRPC vs JSON-RPC
Real-Time Blockchain Data WebSocket vs gRPC vs JSON-RPC
Dimension WebSocket gRPC Streaming gRPC Structured Queries JSON-RPC over HTTP
Protocol WebSocket HTTP/2 + Protocol Buffers HTTP/2 + Protocol Buffers HTTP + JSON-RPC
Interaction model Subscription Streaming Request-response Request-response
Data format Usually JSON Protocol Buffers Protocol Buffers JSON
Real-time delivery Yes Yes No No, typically requires polling
Typical latency Low Very low Low Depends on polling frequency
Type safety Runtime payload structures Strongly typed Protobuf messages Strongly typed Protobuf messages Runtime JSON structures
Filtering Chain- and method-specific Service- and schema-specific Request fields Method parameters
Integration complexity Low Higher Moderate Low
Best for Wallets, dashboards, and DeFi Indexers, trading, and pipelines Balances, staking, and governance Individual blockchain requests
After a disconnection Reconnect and resubscribe Reconnect and restore stream state Retry the request Retry the request

Tatum WebSocket subscriptions are now available

Tatum WebSocket subscriptions are available for: Ethereum, Polygon & Solana.

Each network uses its native subscription model.

Ethereum and Polygon use the standard eth_subscribe method. Solana uses its native JSON RPC PubSub methods, which provide several subscription types for accounts, transactions, programs, slots, roots, and blocks.

NetworkSubscription modelMain data typesEthereumeth_subscribeBlock headers, pending transactions, contract logsPolygoneth_subscribeBlock headers, pending transactions, contract logsSolanaJSON RPC PubSubAccounts, logs, signatures, programs, slots, roots, blocks

The subscriptions use JSON payloads and standard WebSocket connections. This means they can be integrated with browser applications, backend services, scripts, and most modern programming languages without specialised streaming tooling.

Ethereum and Polygon WebSocket subscriptions

Ethereum and Polygon provide three main subscription types through eth_subscribe.

The newHeads subscription sends a notification when a new block header is available.

This is useful for:

  • Block explorers
  • Chain monitoring
  • Gas dashboards
  • Indexing services
  • Applications that trigger work after each new block

Ethereum typically produces new blocks roughly every 12 seconds, while Polygon has a shorter block interval of around two seconds. Exact timing can vary, but the subscription lets your application react as soon as the gateway observes a new block header.

The newPendingTransactions subscription provides transaction hashes as transactions enter the public mempool.

This can support:

  • Transaction monitoring
  • Gas estimation tools
  • Mempool analytic
  • Trading infrastructure
  • Security systems watching for specific activity

Pending transaction feeds can be extremely high volume, especially on busy networks. Applications should avoid performing expensive processing directly inside the WebSocket message handler. Instead, buffer incoming messages and process them through a controlled queue or worker system.

The logs subscription streams smart contract event logs that match your filters.

You can filter by contract address and topics, which allows your application to receive only events relevant to a particular protocol, token, or application.

This is useful for monitoring:

  • Token transfers
  • Decentralized exchange activity
  • Lending events
  • NFT marketplace activity
  • Governance actions
  • Protocol specific contract events

Ethereum and Polygon also expose the removed flag for logs affected by a chain reorganization. Your application should account for this field rather than treating every event as permanently final.

Solana WebSocket subscriptions

Solana uses native JSON RPC PubSub methods instead of eth_subscribe.

Tatum supports seven Solana subscription types:

  • accountSubscribe
  • logsSubscribe
  • signatureSubscribe
  • programSubscribe
  • slotSubscribe
  • rootSubscribe
  • blockSubscribe

These subscriptions cover different parts of Solana’s execution and confirmation flow.

accountSubscribe is useful when an application needs to monitor changes to a specific account. logsSubscribe streams transaction logs, while signatureSubscribe helps track the status of a particular transaction signature.

programSubscribe can monitor accounts owned by a program. slotSubscribe, rootSubscribe, and blockSubscribe provide information about slot progression, rooted slots, and blocks.

Solana subscriptions also accept commitment levels such as: processed, confirmed, finalized.

The right commitment level depends on the application. A trading interface may need early visibility with processeddata, while a payment workflow may wait for confirmed or finalized status.

What WebSockets change in your application

Adding WebSockets changes how your application receives blockchain data.

With polling, the application controls when it checks for updates. With a subscription, the application declares what it needs and waits for the server to deliver matching events.

That can reduce unnecessary requests and shorten the time between an event being observed and your application acting on it.

Consider a payment backend. Instead of checking a transaction status every few seconds, it can listen for relevant activity and begin processing when the transaction appears. A wallet can update its interface when a transaction reaches a new status. A block explorer can begin fetching block details immediately after receiving a new block header.

The same approach applies to DeFi applications. A monitoring service can subscribe to contract logs and trigger internal workflows when a liquidation, swap, deposit, or withdrawal event is emitted.

WebSockets are especially useful for applications that need:

  • Live wallet updates
  • Transaction status tracking
  • Smart contract event monitoring
  • Block explorer updates
  • Gas and network dashboards
  • Payment confirmation workflows
  • DeFi activity monitoring
  • Security and compliance alerts
  • Real time blockchain analytics

The key benefit is not simply lower latency. It is a simpler event driven architecture for applications that need to respond to blockchain activity continuously.

Ready to Stream Blockchain Data in Real Time?

Move beyond polling with Tatum WebSocket subscriptions for Ethereum, Polygon, and Solana. Receive blockchain events as they happen and build more responsive wallets, dashboards, DeFi applications, and monitoring tools.

Get Your Free API Keys

WebSocket endpoints

Tatum provides the following WebSocket endpoints:

Solana
wss://solana-mainnet.gateway.tatum.io

Ethereum
wss://ethereum-mainnet.gateway.tatum.io

Polygon
wss://polygon-mainnet.gateway.tatum.io

After connecting, your application sends the appropriate JSON RPC subscription request for the network and event type it needs.

For Ethereum and Polygon, a subscription request follows the eth_subscribe model:

{
 "jsonrpc": "2.0",
 "id": 1,
 "method": "eth_subscribe",
 "params": ["newHeads"]
}

The server returns a subscription identifier. Future event notifications include that identifier so your application can associate each message with the correct subscription.

The exact request structure differs between Ethereum, Polygon, and Solana. Refer to the relevant network documentation when configuring filters, commitment levels, and subscription parameters.

Building reliable WebSocket integrations

A WebSocket connection is persistent, but it is not permanent.

Networks, gateways, proxies, and client environments can all interrupt a connection. When the connection closes, active subscriptions are lost. A production application therefore needs more than a basic connect and subscribe function.

The first requirement is automatic reconnection. Use exponential backoff with jitter so that many clients do not reconnect at exactly the same time after an outage.

After reconnecting, recreate every active subscription. The server does not automatically restore subscriptions from the previous connection.

Your application should also account for events that occurred while the connection was unavailable. Depending on the network and use case, this may involve querying recent blocks, retrieving transaction history, or using a stored cursor, slot, block number, or checkpoint.

Do not assume that a WebSocket provides exactly once delivery. Messages may be duplicated, delivered out of order, or missed during a connection failure. Downstream processing should be idempotent, meaning the same event can be processed more than once without causing an incorrect result.

High volume subscriptions require additional controls. Pending transaction feeds can generate a large number of messages, so applications should use buffering, queueing, throttling, and backpressure handling. Processing every message synchronously inside one callback can cause memory growth and application instability.

Solana clients should also manage connection keep alive behaviour. In particular, sending regular ping messages can help prevent an idle connection from being closed.

Monitoring is equally important. Track connection status, reconnect attempts, stream lag, message throughput, processing errors, and the age of the latest received event. These signals help distinguish a quiet network from a broken integration.

Getting started with Tatum WebSockets

Tatum WebSocket subscriptions are now available for Ethereum, Polygon, and Solana.

To get started, create a Tatum API key, open the WebSocket endpoint for your network, and send the subscription request for the data your application needs.

The most important design decision is to subscribe narrowly. Server side filtering helps reduce bandwidth and keeps your application focused on relevant events. It is better to create targeted subscriptions than to consume a broad high volume feed and discard most of the messages locally.

Once the connection is working, add reconnection, resubscription, recovery, deduplication, and monitoring before deploying the integration to production.

For network specific examples, see the Tatum documentation for:

Real time blockchain applications need a reliable way to observe changing network state. Tatum WebSocket subscriptions provide that connection for Ethereum, Polygon, and Solana, helping developers move beyond polling and build applications that respond to blockchain events as they happen.