Websocket Event Subscriptions

WebSocket subscriptions enable real-time access to blockchain data over a standard web protocol. Subscribe to blocks, transactions, accounts, and smart contract events, and receive updates the moment they occur on-chain, without polling.

Instead of repeatedly requesting data from RPC endpoints, your application keeps a persistent bidirectional connection and the server pushes events to your client as they happen. This removes polling loops, reduces wasted requests, and keeps your application in sync with current chain state.

Because WebSockets are natively supported by browsers and virtually every language ecosystem, they are the easiest way to consume real-time blockchain data. No gRPC tooling, Protobuf schemas, or code generation required.

WebSocket Pricing

background credit
WebSocket PricingCredits are charged based on WebSocket messages sent and received over your connection.

What this page covers

This guide explains when WebSocket subscriptions are the right choice for real-time blockchain data, how they compare to HTTP polling and gRPC streaming, and what to plan for in production.

🚀

Ready to connect?

Tatum provides WebSocket subscriptions on Solana, Ethereum, and Polygon for real-time, event-level updates with minimal setup.

👉 Check Solana WebSockets, Ethereum WebSockets, or Polygon WebSockets

Why Use WebSockets for Blockchain Data

WebSockets hit the sweet spot between simplicity and real-time capability. They deliver push-based updates like gRPC streaming, but over a protocol your stack already speaks.

Key Benefits

  • Real-time push delivery
    Receive events the moment they occur on-chain, with no polling intervals
  • Standard web protocol
    Native support in browsers, Node.js, Python, Go, and every major language, with no special tooling
  • Server-side filtering
    Subscribe only to the addresses, programs, contract events, or transaction types you care about
  • Human-readable payloads
    JSON messages that are easy to inspect, debug, and process
  • Subscriptions and queries on one connection
    On EVM chains, execute standard JSON-RPC calls over the same socket used for subscriptions
  • Auto-cleanup
    Subscriptions close automatically when the connection drops, with no orphaned server state

Common Use Cases

WebSocket subscriptions are ideal for applications that need live updates at moderate volume:

  • Wallet frontends tracking balances and transaction confirmations
  • Block explorers and real-time dashboards
  • DeFi interfaces reacting to swaps, liquidations, and pool changes
  • NFT marketplaces monitoring mints, listings, and sales
  • Mempool monitoring and gas price tracking (EVM chains)
  • Notification services triggering alerts on on-chain activity

Supported Chains

Tatum currently offers WebSocket subscriptions on three chains. Each implements its native PubSub interface:

ChainInterfaceSubscription typesNetworksReference
SolanaSolana JSON-RPC 2.0 PubSub7 methods: accounts, programs, logs, signatures, slots, roots, slot updatesMainnet, Devnet, TestnetSolana WebSockets
EthereumJSON-RPC 2.0 PubSub (eth_subscribe)newHeads, newPendingTransactions, logs, plus full eth_* RPC access over the same connectionMainnetEthereum WebSockets
PolygonJSON-RPC 2.0 PubSub (eth_subscribe)newHeads, newPendingTransactions, logs, plus full eth_* RPC access over the same connectionMainnetPolygon WebSockets
ℹ️

One Connection for Subscriptions and Queries

On Ethereum and Polygon, the WebSocket endpoint supports both subscriptions and standard JSON-RPC calls on the same connection. You can subscribe to newHeads, then immediately call eth_getBlockByNumber to fetch full block details, all over a single WebSocket.

On Solana, subscriptions additionally accept a commitment parameter (processed, confirmed, or finalized) to control the trade-off between latency and finality. See the chain reference pages for full method details and endpoints.

WebSocket vs. HTTP Polling

Traditional RPC APIs require constant polling to detect changes, which introduces latency and wasted requests. WebSockets remove this limitation by pushing data directly to your application.

FeatureWebSocketHTTP Polling
Data deliveryPush-based (persistent connection)Request-based (repeated calls)
LatencyReal-time (~0ms after node processes)Poll interval dependent (1s–15s typical)
BandwidthEfficient (events only)Wasteful (many empty responses)
ComplexityModerate (connection management)Simple (stateless requests)
Event filtering✅ Server-side subscription filters❌ Client must poll and filter
Best forDashboards, real-time UIs, event-driven backendsSimple scripts, serverless functions, one-off queries

Recommendation:

  • Use WebSocket for: real-time dashboards, wallet UIs, event-driven architectures, transaction confirmation tracking.
  • Use HTTP RPC for: serverless functions, one-off queries, simple scripts, environments where persistent connections aren't possible.

WebSocket vs. gRPC Streaming

Both deliver push-based real-time data. The right choice depends on your throughput needs and operational constraints:

FeatureWebSocketgRPC Streaming
ProtocolJSON-RPC 2.0 over WSProtocol Buffers over HTTP/2
Data formatJSON (human-readable)Binary (compact)
ThroughputModerateHigh
FilteringMethod-specific subscription filtersAdvanced schema-level filtering
ToolingNone required (native browser support)gRPC libraries and generated clients
Best forWallet UIs, dashboards, moderate-volume monitoringIndexers, trading infrastructure, ingestion pipelines

Recommendation:

  • Use WebSocket for: frontends, prototyping, transaction confirmations, and moderate-volume event monitoring.
  • Use gRPC Data Streams for: indexers, high-frequency trading, analytics, and high-volume ingestion.

Operational Best Practices

For production-grade WebSocket consumers, implement:

  • Automatic reconnection with exponential backoff
  • Resubscription logic on reconnect, since subscriptions do not survive a dropped connection
  • Backfill after gaps, for example using eth_getLogs or equivalent historical queries to recover events missed while disconnected
  • Idempotent downstream processing to handle duplicate deliveries safely
  • Heartbeat or ping/pong handling to detect stale connections early
  • Monitoring for disconnect rates, message lag, and subscription health

Common pitfalls

Avoid these implementation issues:

  • Assuming subscriptions persist across reconnects; they must be re-established every time
  • Skipping backfill logic and silently missing events that occurred during a disconnect
  • Processing notifications synchronously in one hot path without buffering
  • Ignoring subscription confirmation IDs, which are needed to route notifications and unsubscribe cleanly

Next steps

To start streaming on a supported chain, visit the reference documentation:



Did this page help you?