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.

Frequently Asked Questions

Q: Can I use the same endpoint for reads and writes? Most commercial RPCs offer both — but for Arbitrum reads you specifically need the sequencer feed subscription, not eth_subscribe('newPendingTransactions'). Confirm your provider explicitly exposes the Arbitrum sequencer feed before committing it to a production read-side workflow.

Q: How often should I benchmark my endpoints? Run a 60-second latency sample daily during active sessions and save the result. Daily measurement is enough to detect gradual degradation over time; real-time monitoring of every individual call is usually unnecessary overhead unless you're operating at high volume where a 10ms regression costs measurable PnL.

Q: What region should I deploy in? For the Arbitrum sequencer, us-east-2 (AWS US East) is where the sequencer infrastructure currently sits. Co-locating your subscriber in the same region drives read latency to single-digit milliseconds. If your primary deployment is in another region, benchmark the cross-region latency before going live — it may be acceptable for the strategy you're running or may not.

Q: When should I run my own Nitro node vs using commercial RPCs? Self-hosted Nitro is worth the infrastructure cost when your daily attributable MEV volume is large enough that the marginal latency improvement (10–25 ms write vs 25–50 ms on commercial) translates to meaningful additional inclusion rate. For most operators below $5K/day attributable MEV, two tier-2 commercial RPCs cover the need without the operational overhead.

References

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