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
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:
| Chain | Interface | Subscription types | Networks | Reference |
|---|---|---|---|---|
| Solana | Solana JSON-RPC 2.0 PubSub | 7 methods: accounts, programs, logs, signatures, slots, roots, slot updates | Mainnet, Devnet, Testnet | Solana WebSockets |
| Ethereum | JSON-RPC 2.0 PubSub (eth_subscribe) | newHeads, newPendingTransactions, logs, plus full eth_* RPC access over the same connection | Mainnet | Ethereum WebSockets |
| Polygon | JSON-RPC 2.0 PubSub (eth_subscribe) | newHeads, newPendingTransactions, logs, plus full eth_* RPC access over the same connection | Mainnet | Polygon WebSockets |
One Connection for Subscriptions and QueriesOn 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 calleth_getBlockByNumberto fetch full block details, all over a single WebSocket.On Solana, subscriptions additionally accept a
commitmentparameter (processed,confirmed, orfinalized) 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.
| Feature | WebSocket | HTTP Polling |
|---|---|---|
| Data delivery | Push-based (persistent connection) | Request-based (repeated calls) |
| Latency | Real-time (~0ms after node processes) | Poll interval dependent (1s–15s typical) |
| Bandwidth | Efficient (events only) | Wasteful (many empty responses) |
| Complexity | Moderate (connection management) | Simple (stateless requests) |
| Event filtering | ✅ Server-side subscription filters | ❌ Client must poll and filter |
| Best for | Dashboards, real-time UIs, event-driven backends | Simple 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:
| Feature | WebSocket | gRPC Streaming |
|---|---|---|
| Protocol | JSON-RPC 2.0 over WS | Protocol Buffers over HTTP/2 |
| Data format | JSON (human-readable) | Binary (compact) |
| Throughput | Moderate | High |
| Filtering | Method-specific subscription filters | Advanced schema-level filtering |
| Tooling | None required (native browser support) | gRPC libraries and generated clients |
| Best for | Wallet UIs, dashboards, moderate-volume monitoring | Indexers, 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_getLogsor 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:
Updated 24 minutes ago