Skip to main content

RPC endpoints and providers

Arbitrum public RPC endpoints

caution
  • Unlike the RPC Urls, the Sequencer endpoints only support eth_sendRawTransaction and eth_sendRawTransactionConditional calls.
  • Arbitrum public RPCs do not provide Websocket support.
  • IPv6 is not supported.

This section provides an overview of the available public RPC endpoints for different Arbitrum chains and necessary details to interact with them.

NameRPC Url(s)Chain IDBlock explorerUnderlying chainTech stackSequencer feed URLSequencer endpoint⚠️
Arbitrum Onehttps://arb1.arbitrum.io/rpc42161Arbiscan, BlockscoutEthereumNitro (Rollup)wss://arb1-feed.arbitrum.io/feedhttps://arb1-sequencer.arbitrum.io/rpc
Arbitrum Novahttps://nova.arbitrum.io/rpc42170BlockscoutEthereumNitro (AnyTrust)wss://nova-feed.arbitrum.io/feedhttps://nova-sequencer.arbitrum.io/rpc
Arbitrum Sepolia (Testnet)https://sepolia-rollup.arbitrum.io/rpc421614Arbiscan, BlockscoutSepoliaNitro (Rollup)wss://sepolia-rollup.arbitrum.io/feedhttps://sepolia-rollup-sequencer.arbitrum.io/rpc
More RPC endpoints

More Arbitrum chain RPC endpoints can be found in Chain Connect: Arbitrum One and Arbitrum Nova.

Alternatively, to interact with public Arbitrum chains, you can rely on many of the same popular node providers that you are already using on Ethereum:

Third-party RPC providers

WANT TO BE LISTED HERE?

Complete this form , if you'd like to see your project added to this list (and the Arbitrum portal).

Need support for Nova 3rd party tooling?

Complete this form to submit a support request.

ProviderArb One?Arb Nova?Arb Sepolia?Websocket?Stylus Tracing?
1RPC
AlchemyAvailable on paid plans
Allnodes
All That Node
AnkrAvailable on paid plans
BlockPi
Chainbase
Chainnodes
ChainstackAvailable on paid plans
dRPC
GetBlock
InfuraEnabled on request
Lava
Moralis
Nirvana Labs
NodeReal
NOWNodes
Pocket Network
PublicNode
QuicknodeTestnet supported in free tier
TenderlyTestnet supported in free tier
Unifra
Validation CloudTestnet supported in free tier

Sequencer endpoint behavior

Arbitrum One exposes two public endpoints with different roles, shown below: a general-purpose public RPC URL, and a direct sequencer endpoint that accepts only eth_sendRawTransaction and eth_sendRawTransactionConditional. The table below summarizes how they differ in purpose and operational guarantees.

The two endpoints at a glance

EndpointPurposeOperational guarantees
https://arb1.arbitrum.io/rpc (public RPC URL)General-purpose read/write endpoint, useful for development and low-volume reads.No uptime, latency, or rate-limit guarantees. Any application that depends on availability should use a third-party node provider or run its own node.
https://arb1-sequencer.arbitrum.io/rpc (sequencer endpoint)Direct submission path to the chain's sequencer for write traffic. Accepts only eth_sendRawTransaction and eth_sendRawTransactionConditional.Exposes the defined queueing and timeout behavior described below, but it is still a best-effort public endpoint with no formal SLA.

Latency and timeout behavior

Under nominal load, transactions submitted to the sequencer endpoint are accepted in well under a second. Internally, the sequencer places submissions into a bounded in-memory queue (default capacity 1024). The queue timeout (default 12 seconds) bounds how long a submitted transaction may remain pending in the sequencer's background queue before being picked up or rejected; it does not provide a formal end-to-end inclusion latency guarantee. If the transaction is not picked up within that window, eth_sendRawTransaction returns context deadline exceeded, and the transaction was not accepted—it is safe to retry.

  • Use a third-party node provider as your primary endpoint, or as a fallback when a direct sequencer submission fails.
  • Retry on transient errors only—context deadline exceeded and network/connection errors are safe to retry with backoff. Do not retry terminal errors such as nonce too low or contract reverts.

Monitoring and alerting

A successful eth_sendRawTransaction response means the sequencer has already sequenced your transaction into an L2 block—the call blocks until the block is created and returns only then, not merely when the transaction is enqueued. Treat this as the sequencer's soft confirmation that your transaction has been ordered and executed. It does not by itself mean the transaction has been posted to the parent chain in a batch or finalized there; if your application needs parent-chain finality guarantees, track that separately. For monitoring, alert on submission calls that return errors or exceed your expected latency ceiling rather than assuming a pending-but-unconfirmed state.