Arbitrum One Websockets Real-Time Blockchain Data Streaming

Arbitrum One WebSocket interface (via eth_subscribe) pushes real-time notifications to your application over a persistent connection, with no polling required.

With Tatum's Arbitrum One WebSocket endpoint, you can subscribe to:

New block headers
Pending transactions
Smart contract event logs

Arbitrum One Mainnet WebSocket endpoint

Interface	Endpoint
Mainnet	`wss://arbitrum-one-mainnet.gateway.tatum.io`
Testnet	`wss://arbitrum-one-sepolia.gateway.tatum.io`

For JSON-RPC (HTTP) and the full network list, see Arbitrum One RPC.

Example request

Note: These are minimal examples. For production, implement reconnection with exponential backoff, track subscription IDs, and call eth_unsubscribe when a subscription is no longer needed.

1. `newHeads` block headers

Receive a notification every time a new block is added to the chain (~5 in second on Arbitrum One mainnet).

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

Notification payload:

{
  "jsonrpc": "2.0",
  "method": "eth_subscription",
  "params": {
    "subscription": "0x1a2b3c...",
        "result": {
            "parentHash": "0x659c3...",
            "sha3Uncles": "0x1dcc4...",
            "miner": "0xa4b00...",
            "stateRoot": "0x6ad3a...",
            "transactionsRoot": "0x15564...",
            "receiptsRoot": "0x073d2...",
            "logsBloom": "0x09400...",
            "difficulty": "0x1",
            "number": "0x4350d13",
            "gasLimit": "0x4000000000000",
            "gasUsed": "0x5bdfe9",
            "timestamp": "0x6ab3e269",
            "extraData": "0xfc1ac...",
            "mixHash": "0x00000...",
            "nonce": "0x00000...",
            "baseFeePerGas": "0x30a6970",
            "withdrawalsRoot": null,
            "blobGasUsed": null,
            "excessBlobGas": null,
            "parentBeaconBlockRoot": null,
            "requestsHash": null,
            "blockAccessListHash": null,
            "slotNumber": null,
            "hash": "0xe35e7..."
        }
  }
}

Key fields:

Field	Description	Example (decoded)
`number`	Block height (hex)	`20,200,935`
`hash`	Block hash	`0xabc123...`
`timestamp`	Unix timestamp (hex)	`1719795712`
`baseFeePerGas`	EIP-1559 base fee (hex, in wei)	`1 Gwei = 0x3b9aca00`
`gasUsed`	Total gas consumed (hex)	`15,000,000`
`gasLimit`	Block gas limit (hex)	`30,000,000`
`miner`	Fee recipient address	`0x...`

Best for: Block explorers, gas price dashboards, chain liveness monitoring.

Important: newHeads only delivers the block header. To get the full block with transactions, send a follow-up eth_getBlockByNumber call over the same WebSocket:

{
  "jsonrpc": "2.0",
  "id": 100,
  "method": "eth_getBlockByNumber",
  "params": [block.number, true] // true = include full transaction objects
}

To unsubscribe, call eth_unsubscribe with the subscription ID returned by the server:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "eth_unsubscribe",
  "params": [SUBSCRIPTION_ID]
}

2. `newPendingTransactions` mempool activity

Receive a notification for each transaction hash that enters the node's mempool. This is a high-volume subscription.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "eth_subscribe",
  "params": ["newPendingTransactions"]
}

Notification payload:

{
  "jsonrpc": "2.0",
  "method": "eth_subscription",
  "params": {
    "subscription": "0x4d5e6f...",
    "result": "0x9876543210abcdef..."
  }
}

The result is a transaction hash only, not the full transaction object. To get transaction details, make a follow-up RPC call:

{
  "jsonrpc": "2.0",
  "id": 200,
  "method": "eth_getTransactionByHash",
  "params": ["0x9876543210abcdef..."]
}

⚠️
High Volume Warning
newPendingTransactions can emits hundreds of hashes per second. Always implement throttling on the client side, don't attempt to fetch details for every hash. A typical approach:

Cap concurrent eth_getTransactionByHash lookups (e.g., 3 to 5 at a time)

Skip hashes while at capacity

Keep only the N most recent pending transactions in your UI

Best for: Mempool dashboards, gas estimation, MEV monitoring, pending transaction previews.

To unsubscribe:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "eth_unsubscribe",
  "params": [SUBSCRIPTION_ID]
}

3. `logs` smart contract events

Subscribe to filtered event logs emitted by smart contract transactions. This is the most flexible subscription type, supporting filtering by contract address and event topics. You can ommit address to obtain all logs for topic (This will emit high volume of messages per second)

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "eth_subscribe",
  "params": [
    "logs",
    {
      "address": "0xdAC17F958D2ee523a2206206994597C13D831ec7",
      "topics": [
        "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"
      ]
    }
  ]
}

Notification payload:

{
  "jsonrpc": "2.0",
  "method": "eth_subscription",
  "params": {
    "subscription": "0x7a8b9c...",
    "result": {
      "address": "0xdac17f958d2ee523a2206206994597c13d831ec7",
      "topics": [
        "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
        "0x000000000000000000000000sender_address_here",
        "0x000000000000000000000000recipient_address_here"
      ],
      "data": "0x00000000000000000000000000000000000000000000000000000000003d0900",
      "blockNumber": "0x131a5e7",
      "transactionHash": "0x...",
      "transactionIndex": "0x0",
      "blockHash": "0x...",
      "logIndex": "0x0",
      "removed": false
    }
  }
}

Filter options:

Parameter	Type	Description
`address`	`string` or `string[]`	Contract address(es) to filter. Omit for all contracts.
`topics`	`(string \| string[] \| null)[]`	Up to 4 indexed topic filters. Supports OR within a position (`[null, [topicA, topicB]]`).

ℹ️
Understanding the removed Field
When a chain reorganization (reorg) occurs, previously emitted logs may become invalid. In that case, the same log is re-emitted with "removed": true. Your application should handle this by reverting any state changes derived from that log.

Best for: Token transfer feeds, DEX swap monitoring, NFT marketplace tracking, protocol-specific event streaming.

To unsubscribe:

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "eth_unsubscribe",
  "params": [SUBSCRIPTION_ID]
}

WebSocket vs. HTTP Polling

Feature	WebSocket	HTTP Polling
Protocol	Persistent WS connection	Repeated HTTP requests
Latency	Real-time push (~0ms after node processes)	Poll interval dependent (1s to 15s typical)
Bandwidth	Efficient (events only)	Wasteful (many empty responses)
Complexity	Moderate (connection management)	Simple (stateless requests)
Mempool access	✅ `newPendingTransactions`	❌ Not available
Event streaming	✅ `logs` subscription with filters	❌ Must poll `eth_getLogs`
Best for	Dashboards, real-time UIs, event-driven backends	Simple scripts, serverless functions, one-off queries

Recommendation:

Use WebSocket for: real-time dashboards, block explorers, mempool monitoring, event-driven architectures
Use HTTP RPC for: serverless functions, one-off queries, simple scripts, environments where persistent connections aren't possible

Arbitrum One - WebSocket

Arbitrum One Mainnet WebSocket endpoint

Example request

1. `newHeads` block headers

2. `newPendingTransactions` mempool activity

High Volume Warning

3. `logs` smart contract events

Understanding the `removed` Field

WebSocket vs. HTTP Polling

Arbitrum One Mainnet WebSocket endpoint

Example request

1. newHeads block headers

2. newPendingTransactions mempool activity

High Volume Warning

3. logs smart contract events

Understanding the removed Field

WebSocket vs. HTTP Polling

1. `newHeads` block headers

2. `newPendingTransactions` mempool activity

3. `logs` smart contract events

Understanding the `removed` Field