WebSocket vs HTTP for Blockchain RPC: When to Use Each

Every dApp makes hundreds of RPC calls. The transport you choose (HTTP or WebSocket) determines latency, request efficiency, and whether your application can react to on-chain events in real time. Most guides explain the protocols in the abstract. This one tells you exactly which to use for each blockchain use case, with working code.

---

What is the Difference Between WebSocket and HTTP?

HTTP is a request-response protocol: your app asks, the node answers, the connection closes. WebSocket is a persistent connection: your app listens, and the node pushes updates the moment they happen.

Both carry JSON-RPC. The method names are identical. The difference is transport, not protocol.

HTTP RPC:

• One request, one response, connection closes
• Your app controls when to ask
• Simple to implement and debug
• No persistent state between calls

WebSocket RPC:

• One connection, stays open indefinitely
• The node can push data without being asked
• Required for subscriptions and real-time event monitoring
• More efficient when you need continuous data

This distinction drives every architectural decision in blockchain infrastructure.

---

HTTP RPC: How It Works for Blockchain

Your application sends a JSON-RPC request. The node processes it and returns the result. The connection closes. Next call starts fresh.

# Check ETH balance via HTTP
curl -X POST https://eu.endpoints.matrixed.link/rpc/ethereum?auth=YOUR_KEY \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "eth_getBalance",
    "params": ["0xYourAddress", "latest"],
    "id": 1
  }'

Response comes back immediately. Connection is done.

HTTP is the right choice when:

• Checking a wallet balance before displaying the UI
• Fetching a transaction receipt after submission
• Reading contract state on user action (eth_call)
• Running a batch of one-off queries at a point in time
• Anything where your application controls the timing of the request

HTTP is stateless by design. For most on-demand queries, that is a feature, not a limitation.

---

WebSocket RPC: How It Works for Blockchain

One connection opens and stays open. Instead of your app repeatedly asking “any new blocks?”, the node pushes a notification the moment a new block is produced. Your app receives it in milliseconds.

// Connect via WebSocket and subscribe to new blocks
const WebSocket = require('ws');

const ws = new WebSocket(
  'wss://eu.endpoints.matrixed.link/ws/ethereum?auth=YOUR_KEY'
);

ws.on('open', () => {
  // Subscribe to new block headers
  ws.send(JSON.stringify({
    jsonrpc: '2.0',
    method: 'eth_subscribe',
    params: ['newHeads'],
    id: 1
  }));
});

ws.on('message', (data) => {
  const response = JSON.parse(data);
  if (response.method === 'eth_subscription') {
    const block = response.params.result;
    console.log('New block:', parseInt(block.number, 16));
  }
});

You can also subscribe to pending transactions in the mempool:

// Subscribe to pending transactions
ws.send(JSON.stringify({
  jsonrpc: '2.0',
  method: 'eth_subscribe',
  params: ['newPendingTransactions'],
  id: 2
}));

Every pending transaction hash comes through the moment it hits the mempool: no polling, no delay, no wasted requests.

WebSocket is the right choice when:

• Watching for new blocks
• Monitoring the mempool for pending transactions
• Listening for smart contract events (logs)
• Building a real-time price feed or oracle monitoring system
• Any use case where you need the node to push data to you

---

Does RPC Use WebSocket?

Yes. JSON-RPC runs over both HTTP and WebSocket. The method namespace is identical: eth_getBalance, eth_call, eth_sendRawTransaction all work over either transport.

The key difference is eth_subscribe, which is WebSocket-only. It is a subscription method that requires a persistent connection because the node needs to send you data over time, not just once. You cannot subscribe to new blocks over HTTP. HTTP closes after each response.

Summary:

• All standard JSON-RPC methods: HTTP or WebSocket
• eth_subscribe / eth_unsubscribe: WebSocket only

---

WebSocket vs HTTP: Decision Guide by Use Case

This is the table most guides skip. Use it to pick the right transport for each part of your application:

Use Case	Protocol	Reason
Check wallet balance	HTTP	Single query, triggered by user
Submit a transaction	HTTP	One action, one confirmation
Read smart contract state	HTTP	On-demand, user-triggered
Batch multi-call queries	HTTP	One round trip for multiple reads
Watch for new blocks	WebSocket	Continuous push, zero polling overhead
Monitor mempool	WebSocket	Real-time, millisecond delivery
Listen for contract events	WebSocket	Node pushes on event, not on request
DeFi liquidation bot	WebSocket	Must react to blocks instantly
Trading bot execution	WebSocket	Block-by-block triggers, no polling lag
Wallet balance (display)	HTTP	Load once, refresh on user action
Wallet activity feed	WebSocket	Real-time incoming transaction alerts
Price oracle aggregation	WebSocket	Continuous block-by-block data

Most production applications use both. Not one or the other.

---

Why WebSocket Wins at Scale Over HTTP Polling

Some developers default to HTTP polling: hitting eth_blockNumber every second to detect new blocks. This works at small scale. At production scale, it creates unnecessary cost and latency.

Polling math:

• 1 HTTP poll per second for new blocks = 86,400 requests per day, per connection
• 10 connections monitoring blocks = 864,000 requests per day
• Each block arrives at most 1 second late (average poll interval)

WebSocket subscription:

• 1 persistent connection
• ~720 push events per day (one per Ethereum block, roughly every 12 seconds)
• Block notification arrives in milliseconds after production, not up to 1 second later

For a DeFi liquidation protocol watching collateral thresholds across thousands of positions, that latency gap is the difference between capturing and missing a liquidation. For a trading bot executing on price movement, polling delay is lost revenue.

WebSocket subscriptions also free up your request capacity. Those 864,000 polling requests represent capacity that can be used for actual data queries.

---

Using Both Protocols Together

The practical pattern for production blockchain applications is not “HTTP or WebSocket” but “WebSocket for triggers, HTTP for data.”

Example: DeFi liquidation protocol

WebSocket  → listens for new block (eth_subscribe newHeads)
On new block → HTTP batch call to check all positions (eth_call x N)
If position liquidatable → HTTP to submit liquidation tx (eth_sendRawTransaction)

Example: Trading bot

WebSocket  → listens for pending transactions (newPendingTransactions)
On relevant tx detected → HTTP call to read current state (eth_call)
Decision made → HTTP to submit counter-transaction (eth_sendRawTransaction)

WebSocket handles the trigger. HTTP handles the reads and writes.

With BoltRPC, both transports use the same endpoint format, the same auth key, and the same account. Switch between them by changing the protocol prefix:

HTTP:   https://eu.endpoints.matrixed.link/rpc/ethereum?auth=YOUR_KEY
WSS:    wss://eu.endpoints.matrixed.link/ws/ethereum?auth=YOUR_KEY

No separate accounts. No separate billing. Switch any network from HTTP to WebSocket by swapping the URL prefix.

---

FAQ: WebSocket vs HTTP RPC

What is the difference between WebSocket and RPC?

WebSocket and RPC are different concepts. RPC (Remote Procedure Call) is a communication pattern: calling a function on a remote server. WebSocket is a transport protocol: a persistent, bidirectional connection. JSON-RPC can run over both HTTP and WebSocket. When developers say “WebSocket RPC”, they mean JSON-RPC delivered over a WebSocket connection instead of HTTP.

Does RPC use WebSocket?

Yes. JSON-RPC runs over both HTTP and WebSocket. Standard methods like eth_getBalance and eth_call work over either transport. The eth_subscribe method is WebSocket-only because it requires a persistent connection for the node to push subscription events.

Why use WebSocket instead of HTTP for blockchain?

WebSocket eliminates polling. Instead of your application asking “any new blocks?” once per second, the node pushes a notification the moment a block is produced. This reduces request volume by 99% for block monitoring use cases, delivers events in milliseconds rather than up to one second late, and frees your request capacity for actual data queries.

Which is faster: WebSocket or HTTP RPC?

For real-time event monitoring, WebSocket is significantly faster. New block notifications arrive in milliseconds. HTTP polling adds up to the full polling interval as delay. For single on-demand queries (balance check, contract read), HTTP and WebSocket are comparable. The transport overhead difference for a single request is negligible.

Can I use both HTTP and WebSocket with the same RPC provider?

Yes, if your provider supports both. BoltRPC exposes both HTTP and WebSocket on all supported networks using the same auth key. Switch between them by changing the URL prefix from https:// to wss:// and /rpc/ to /ws/. No separate configuration required.

---

Conclusion

HTTP and WebSocket are not competing choices. They are complementary tools for different parts of the same application.

Use HTTP for on-demand queries: balance checks, contract reads, transaction submissions. Use WebSocket for continuous monitoring: new blocks, mempool events, contract logs. Most production dApps need both.

The RPC provider underneath needs to support both reliably. BoltRPC handles 2 billion RPC calls daily across HTTP and WebSocket, trusted by Chainlink, Tiingo, Gains Network, Enjin. ISO/IEC 27001:2022 certified via Matrixed.Link.

Start your free 2-week trial, no credit card required: trial.boltrpc.io

Explore supported networks: boltrpc.io/networks