Robinhood Chain RPC & WebSocket: Endpoints and Production Setup

Connecting to Robinhood Chain takes one JSON-RPC URL. A production setup adds a separate set of decisions on top of that: HTTP or WebSocket, public or managed infrastructure, how much historical state to keep, and how to tell Robinhood's public Sequencer Feed apart from a standard JSON-RPC WebSocket endpoint.

Introduction

Robinhood Chain went live on July 1, 2026. Within the first week, the network cleared over a billion dollars in DEX volume and roughly 17 million transactions, putting real load on the RPC layer from the start. It's an Ethereum-compatible Arbitrum rollup, so the application interface is familiar: standard JSON-RPC over HTTP for reads and transaction submission, WebSocket endpoints for event-driven workloads. Mainnet uses chain ID 4663, testnet 46630, and ETH for gas on both.

Production reliability comes down to the infrastructure behind that interface. Robinhood's public RPC is rate-limited and, by Robinhood's own terms, unsuited to production-grade or latency-sensitive traffic. WebSocket also adds connection-state handling, since subscriptions disappear with the connection that created them.

Robinhood Chain RPC and WebSocket at a Glance

Mainnet runs on chain ID 4663 (0x1237), with the public RPC at https://rpc.mainnet.chain.robinhood.com and the explorer at https://robinhoodchain.blockscout.com. Testnet uses chain ID 46630 (0xb626), RPC at https://rpc.testnet.chain.robinhood.com, explorer at https://explorer.testnet.chain.robinhood.com. Gas token is ETH on both.

Which endpoint and protocol to use depends on the workload:

How Robinhood Chain JSON-RPC Works

At the protocol level, Robinhood Chain uses standard JSON-RPC 2.0 — method name, params array, an id to match the reply. Because the chain is EVM-compatible, common Ethereum JSON-RPC methods and tooling carry over without a Robinhood-specific dialect — though not every method or namespace is necessarily enabled on every endpoint. Most integrations rely on a small set of methods: eth_chainId to confirm the endpoint is serving 4663, eth_blockNumber for current head and lag, eth_call for read-only execution, eth_getBalance, eth_getLogs for range queries and backfill, eth_getTransactionReceipt, and eth_sendRawTransaction for broadcasting signed transactions.

A minimal check against the public endpoint:

curl -s https://rpc.mainnet.chain.robinhood.com \
 -H 'Content-Type: application/json' \
 -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

The expected reply is "result":"0x1237" — hex for 4663. Verify this at startup, before the application sends any real read or transaction through the endpoint.

Endpoint capacity, block retention, batch limits, and enabled namespaces depend on the implementation behind the endpoint. EVM compatibility guarantees a shared execution model and request format — it doesn't extend to how a specific endpoint is provisioned or operated.

When to Use WebSocket Instead of HTTP RPC

HTTP and WebSocket fit different request patterns. HTTP works well when the application knows exactly what it needs: a balance, a receipt, a specific historical range, a transaction to submit. WebSocket fits event streams whose timing isn't known in advance, such as new blocks or contract events matching a filter, where polling on a timer would just waste requests. A minimal subscription over a standard JSON-RPC WSS endpoint:

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

The node replies with a subscription id, and every new head after that arrives as an eth_subscription push. Filtered logs work the same way, swapping in ["logs", { "address": ..., "topics": [...] }].

For event-driven workloads built on WebSocket subscriptions, HTTP RPC still needs to sit underneath as the recovery path. A subscription only lasts as long as the connection that created it, and it reports events going forward rather than filling in whatever happened while a consumer was offline. A read-heavy backend, or a service that mostly submits transactions and checks receipts, may reasonably skip WebSocket altogether.

Transaction Submission on Robinhood Chain

Submitting a transaction is a single HTTP call: sign it locally, then broadcast the raw payload with eth_sendRawTransaction.

curl -s https://rpc.mainnet.chain.robinhood.com \
 -H 'Content-Type: application/json' \
 -d '{"jsonrpc":"2.0","id":1,"method":"eth_sendRawTransaction","params":["0xSIGNED_TX_HEX"]}'

A response here confirms only that the endpoint accepted the payload for sequencing. Robinhood's documented finality model breaks what happens next into three stages: a sub-second soft confirmation once the sequencer accepts, orders, and executes the transaction, a batch posting to Ethereum within minutes that locks in the ordering, and full finality roughly 13 minutes after that batch posts to Ethereum, following Ethereum's own finality window. Applications should track actual inclusion with eth_getTransactionReceipt rather than treating the initial RPC response as confirmation.

Robinhood Chain orders transactions first-come, first-served based on their arrival at the sequencer; priority fees play no role in that order. For most workloads that detail doesn't affect anything downstream. For latency-sensitive ones — arbitrage, liquidations, racing another actor into the same block — arrival time makes the network path to the sequencer one of the relevant latency variables. Third-party infrastructure providers have benchmarked Robinhood's sequencer feed from AWS us-east-2, and public sequencer IP ranges have been observed in that region — though Robinhood hasn't confirmed the sequencer's physical hosting location. That's enough to make US East a reasonable starting point when benchmarking latency-sensitive RPC paths.

Public vs Managed vs Dedicated RPC

Public, managed, and dedicated RPC fit different workload profiles.

Public RPC

Fits development, one-off scripts, wallet configuration, and low-volume reads where occasional throttling or a retry is acceptable. No numeric rate limit is published anywhere, so treat the limit as unspecified rather than picking a number.

Managed RPC

Becomes relevant when a workload needs higher or more predictable capacity than the public endpoint offers, authenticated access, standard WebSocket support, or operational guarantees that the public endpoint does not offer. Our Robinhood Chain RPC and WebSocket provides authenticated HTTPS and WSS access from US East, with full block, transaction, and log history from genesis and a limited window of recent state. Workloads that need state further back can add archive access separately — through a managed archive endpoint or a dedicated archive node — rather than assuming one is bundled by default.

Dedicated node

Makes sense once shared infrastructure itself is the constraint — sustained volume against a shared rate ceiling, a region requirement, or an archive workload that needs predictable CPU, memory, and storage capacity. Dedicated capacity provides isolation and predictable resource allocation; actual latency still comes down to node configuration, caching, and network path, the same variables that govern a managed endpoint.

What to Check in a Production Robinhood Chain RPC

The main comparison points:

• endpoint region relative to where the application runs;
• which RPC methods and namespaces are actually enabled;
• HTTP and WebSocket support — some endpoints only expose one of the two;
• block and log history retention;
• historical state or archive availability;
• range restrictions on eth_getLogs;
• batch call limits;
• rate limits and burst behavior under load;
• p50/p95/p99 latency by the specific methods the application calls;
• timeout and error rates;
• WebSocket disconnect and reconnect behavior;
• support responsiveness and SLA terms.

These properties are endpoint-specific and should be measured against the workload itself.

Archive RPC vs Indexed Historical Data

Historical access usually means one of two things: historical chain state, or decoded, queryable application data.

Archive RPC answers state questions pinned to a specific block — what a balance, a storage slot, or an eth_call result looked like at block N. Robinhood's own documentation recommends an archive endpoint for these state queries, offered through managed infrastructure providers rather than requiring a dedicated node by default. Full block, transaction, and log history is usually retained separately from state history and can go back much further than a typical state-retention window.

An indexer answers something else — transfers for an account, swaps for a pair over a date range, decoded events shaped around application logic rather than a raw state trie. The same data can be reconstructed from low-level RPC calls, but the application then owns backfill, decoding, normalization, storage, and query logic itself. Our Robinhood Chain indexer applies this model to DEX activity on the chain — Uniswap v3/v4 swaps and pool data decoded into a queryable SQL warehouse, covering the chain's history since launch.

Archive RPC keeps the chain's historical state model intact. An indexer reshapes that history into application-oriented tables. Workloads that need both state lookups and decoded analytics can use both for different queries.

WebSocket Reliability in Production

A connected socket only proves the stream works right now. Ethereum's subscription model ties subscriptions to the connection that created them and only delivers current events, not backfilled ones. Once the socket closes, the subscription id goes with it, and reconnecting means creating an entirely new subscription rather than resuming the old one.

• Reconnect with backoff after a dropped socket, rather than retrying immediately.
• Create fresh subscriptions. The previous ones ended with the old connection.
• Backfill over HTTP using eth_getLogs, overlapping slightly into the range already processed instead of resuming exactly at lastBlock + 1.
• Deduplicate and reconcile the overlap against canonical eth_getLogs results.

The overlap also catches reorgs that happen while the socket is disconnected, when no removed: true notification ever arrives because there was no connection to receive it. Re-checking a bounded window of recently processed blocks against canonical results lets the application detect those reorgs after reconnecting.

Standard WebSocket vs the Robinhood Sequencer Feed

wss://feed.mainnet.chain.robinhood.com is Robinhood's Nitro Sequencer Feed. It functions as node input rather than an application-facing interface — Robinhood's own full-node guide shows it consumed via --node.feed.input.url, feeding data into a Nitro node instead of answering eth_subscribe requests from an application. As of late September 2026, node operators have also started configuring a second, delayed backup feed alongside the primary one for failover — it sits at the same node-input layer and doesn't change anything on the application-facing side.

A standard WebSocket endpoint, whether from a provider or from a managed Robinhood Chain node, is the one built to accept eth_subscribe and push back newHeads or filtered logs. Both addresses use the wss:// scheme, but they expose different protocols and serve different consumers.

When a Dedicated Robinhood Chain Node Makes Sense

Self-hosting is a real option. Robinhood Chain runs on Arbitrum Nitro, and Robinhood documents the operational cost: 8+ CPU cores, 64 GB RAM with 128 GB recommended, local NVMe, several terabytes of storage, plus both an Ethereum execution endpoint and a beacon endpoint since the chain posts data back to L1. Archive mode needs meaningfully more disk. It's workable, though it adds a second infrastructure stack to patch and monitor going forward.

Teams that want isolation without running Nitro themselves can order dedicated capacity instead. Our dedicated Robinhood Chain node is single-tenant, full or archive, with private RPC and WebSocket and no shared rate caps, deployed in the region required by the workload. The benefit depends on whether the bottleneck is shared capacity, region placement, storage, or something elsewhere in the stack.

Robinhood Chain RPC Production Checklist

• Validate eth_chainId === 0x1237 on mainnet at startup, before sending real reads or transactions.
• Match protocol to workload: HTTP for deterministic reads and submissions, WebSocket for event-driven consumers that would otherwise poll.
• Use a standard JSON-RPC WSS endpoint for eth_subscribe — the Sequencer Feed serves node infrastructure, not application code.
• Treat the public RPC as best-effort development infrastructure, because Robinhood does not publish an uptime SLA for it.
• Confirm which methods and namespaces are enabled on the specific endpoint instead of inferring them from EVM compatibility.
• Track transaction status with eth_getTransactionReceipt, and include sequencer distance in latency-sensitive path design instead of relying on gas-price tuning alone.
• Decide whether "historical" means old state, decoded queryable history, or both, before choosing infrastructure for it.
• On disconnect, open a new socket and new subscriptions rather than expecting the old ones to resume.
• Backfill with a reorg-aware overlap instead of resuming directly from the last saved block.
• Make event processing idempotent and handle removed: true logs explicitly.
• Measure p50/p95/p99 by method, from the region the application runs in, not just an average.
• Use dedicated capacity when measurements show that shared infrastructure is the constraint.

Supanode operates Robinhood Chain infrastructure end to end — managed RPC and WebSocket access, dedicated full and archive nodes, and an indexer for decoded historical queries. Endpoint configuration and method support are covered in the Robinhood Chain documentation, with current plans on the Robinhood pricing page.