Best WSS Endpoints for Arbitrum (2026)

Answer first — On Arbitrum, "best WSS endpoint" is actually two questions. For reads (mempool-equivalent visibility) the right subscription is the Arbitrum sequencer feed, which broadcasts every accepted transaction over WebSocket before it lands in a confirmed block — this replaces the public mempool concept that doesn't exist here. For writes (sending your own transactions) you want a low-latency JSON-RPC endpoint, ideally a commercial private RPC (QuickNode, Alchemy, Chainstack) under ~50 ms p95 from your deployment region, or a self-hosted Nitro node co-located near the sequencer for serious volume. Mixing them up — or trying to backrun off a normal eth_subscribe('newPendingTransactions') against the public RPC — costs latency you can't recover. This guide covers both halves.

Mastery path

• Arbitrum playbook: private bundles
• Arbitrum MEV latency & routing
• WSS endpoints guide (current)
• Best Ethereum private RPCs

Why Arbitrum's WSS landscape is different

On Ethereum mainnet, mempool subscription via eth_subscribe('newPendingTransactions') against any node gives you the same view (modulo peer connectivity). On Arbitrum the public mempool doesn't exist as a peer-to-peer broadcast layer — transactions go directly to the centralised sequencer. So:

• Reads: the canonical low-latency source is the sequencer feed, an Arbitrum-specific WebSocket that publishes accepted transactions. Most commercial providers do not expose this directly. You either subscribe to it via the official endpoint or run your own Nitro node and pull the feed locally.
• Writes: standard JSON-RPC over WSS works as expected. Latency to your write endpoint matters because the sequencer accepts on first-come basis within each window.

Treating the chain like Ethereum mainnet (and chasing pending-tx subs on a commercial RPC) is the most common Arbitrum WSS mistake. You'll see something — but not the live signal you need to backrun, because most pending txs you'd see have already been sequenced.

Read-side: sequencer feed providers

The official feed is free; the bottleneck is your subscriber's region. Latency from a feed subscriber in us-east-2 (where the sequencer infrastructure currently sits) is single-digit milliseconds; from ap-southeast-1 it's tens to hundreds. Co-location matters more here than on Ethereum.

Write-side: JSON-RPC providers

For sending transactions back to the network, the conventional commercial RPC providers all work. Realistic positioning in 2026:

(Tier names and exact latency numbers vary by region, contract, and time — benchmark against your actual deployment region with the WSS latency test before committing.)

What to measure on Arbitrum specifically

Generic "p50/p95 latency" matters, but two Arbitrum-specific signals are more predictive of real trade outcomes:

1. Time from feed event to sequenced block. If your feed subscriber sees a tx, how long until that tx appears in a confirmed block? Steady-state is sub-second; if it's dragging, the sequencer is degraded and your simulations are likely stale by the time you sign.
2. Round-trip on eth_chainId against the write endpoint. This is the cheapest possible RPC call. If it's slow, every other call you make will be slow too — and eth_chainId slowness usually correlates with the provider over-subscribing capacity.

A daily 30-second sample of both, recorded with timestamps, is enough to spot regressions before they cost a session.

Rotation policy

• Set a baseline for your endpoint set during a calm period. Document p50/p95 per provider per region.
• Alert when current p95 exceeds baseline by 50%+ for 5+ minutes. That's degradation, not noise.
• On rotation, switch both the read and write endpoint to the standby — most operators forget the read side and end up with a fast write endpoint backrunning stale data.
• Keep the rotated-out endpoint warm at low rps for 30 minutes so a quick rollback is cheap.

Common Arbitrum WSS mistakes

• Subscribing to newPendingTransactions instead of the sequencer feed. You get a feed that technically contains transactions, but it's a stale derivative — the sequencer has already accepted them.
• Using free-tier writes for time-sensitive sends. Free tiers throttle aggressively during volatility. The first 50 sends look fine; the 51st sits in a queue until the rate window resets.
• Cross-region fallback that quietly doubles latency. Falling over from us-east-2 to eu-west-1 adds ~80 ms each direction. If your strategy needed sub-50 ms, the failover state is unprofitable. Alarm on latency, not just on hard failures.
• Outbound bandwidth saturation. A backrun fan-out across 4 endpoints can spike outbound bandwidth on a small VPS during a storm. Test under synthetic load before relying on the configuration.

Working configuration in 2026

Realistic Arbitrum-MEV endpoint stack for a serious operator:

• Read: Self-hosted Nitro node co-located in us-east-2, subscribed to the official sequencer feed locally.
• Primary write: Tier-1 commercial RPC in the same region (sub-50 ms p95).
• Secondary write: Different commercial provider in the same region for fan-out / rotation.
• Tertiary write: A different cloud region to hedge a regional outage. Lower tier acceptable; this is for "stay alive" not "stay fast."

For lower-volume operators (under ~$5K/day attributable MEV), drop the self-hosted node and run two tier-2 commercial RPCs. The marginal cost-vs-edge math doesn't justify hardware until volume is meaningful.

References

• Arbitrum sequencer feed format & WebSocket subscription
• Arbitrum Nitro node operator documentation
• WSS latency test tool