Arc RPC providers compared: public vs. private endpoints, and the mainnet gap

The most important fact in this entire category isn't about any single provider: official Arc mainnet RPC and explorer URLs were not published as of 2 September 2026. Every RPC provider comparison, including this one, is describing testnet-scoped infrastructure until Arc itself publishes a canonical mainnet endpoint. Read every claim below with that ceiling in mind.

What an RPC provider actually does, and why the choice matters

An RPC (remote procedure call) endpoint is the door an application knocks on to read Arc's chain state or submit a transaction. Every wallet, every dApp, every indexing job goes through one. The chain itself defines a public endpoint (Arc's testnet RPC is https://rpc.testnet.arc.io), but public endpoints are typically rate-limited and shared across everyone using them — fine for testing, risky for production traffic that needs consistent uptime.

That's the reason a market of third-party RPC providers exists at all: they offer private or dedicated endpoints with higher rate limits, service-level guarantees, geographic distribution, and often additional tooling (archive-node access for historical state, enhanced APIs, webhooks). The tradeoffs to actually evaluate, once mainnet endpoints exist, are rate limits (requests per second before throttling), archive vs. full-node access (whether you can query historical state or only recent blocks), and cost tiers — not just "does this provider list Arc," which as this guide shows, is a lower and less useful bar than it sounds.

What's actually confirmed, provider by provider

Circle's own Arc developer documentation publishes a dedicated node-providers reference page (docs.arc.io/arc/tools/node-providers) naming four vendors directly: Alchemy, Blockdaemon, dRPC, and QuickNode. That documentation listing is a primary-sourced confirmation for all four — Circle naming a vendor in its own developer reference, alongside the Arc-operated public endpoint (https://rpc.testnet.arc.io, chain ID 5042002). The page states these providers support HTTP and WebSocket access on the Arc testnet; it does not separately address mainnet availability for any of them.

QuickNode has published Arc-specific documentation at quicknode.com/docs/arc — independent confirmation beyond Circle's list, and the clearest tier of confirmation in this category, since a documentation page with real syntax and parameters is harder to fake than a name-drop.

Builds on Arc: Offers dedicated Arc RPC endpoints with published testnet documentation. · Role: Serves · Category: Developer Infrastructure → RPC

Alchemy publishes a dedicated Arc Testnet RPC page (alchemy.com/rpc/arc-testnet) with devtools, and Arc's own community channel has published a partnership post confirming the Arc-Alchemy relationship directly — independent confirmation beyond Circle's own documentation listing.

Builds on Arc: Runs dedicated Arc RPC endpoints with enhanced APIs for production apps. · Role: Serves · Category: Developer Infrastructure → RPC

Blockdaemon is named directly in Circle's node-providers documentation, described there as offering "institutional-grade, secure and compliant infrastructure" for Arc. Built on Arc found no additional independent Blockdaemon-published Arc documentation beyond Circle's listing as of 2 Sep 2026 — a real, primary-sourced confirmation, but currently a single-source one.

Builds on Arc: Offers dedicated Arc RPC endpoints for teams needing uptime guarantees. · Role: Serves · Category: Developer Infrastructure → RPC

dRPC is named in Circle's documentation and separately publishes its own specific testnet endpoint (arc-testnet.drpc.org) with chain ID, WebSocket support, and archive-node access listed, plus tiered pricing (a free tier and a paid tier starting around $10, offering higher request-per-second limits and priority support per dRPC's own published material) — independent confirmation with real technical detail attached, beyond appearing on Circle's list.

Builds on Arc: Provides Arc RPC access with built-in debugging tooling and archive-node support. · Role: Serves · Category: Developer Infrastructure → RPC

GetBlock and Chainstack are not named on Circle's official node-providers page, but each independently publishes its own Arc-specific material: GetBlock at docs.getblock.io/api-reference/arc, and Chainstack via a blog post specifically announcing Arc testnet support. Their absence from Circle's curated list doesn't outweigh their own published, checkable documentation — it just means their confirmation runs through a different, still-legitimate channel than Circle's own vendor page.

Builds on Arc: Publishes its own Arc API reference for RPC access. · Role: Serves · Category: Developer Infrastructure → RPC

Builds on Arc: Announced Arc testnet RPC support via its own node infrastructure platform. · Role: Serves · Category: Developer Infrastructure → RPC

Ankr — despite operating one of the broadest general-purpose RPC directories in the industry (70-plus networks per its own marketing), no Arc-specific listing, documentation, or announcement was found as of 2 Sep 2026, and it does not appear on Circle's node-providers page. Not yet confirmed.

Infura — no Arc-specific documentation, chain listing, or announcement was found as of 2 Sep 2026, and it does not appear on Circle's node-providers page. Not yet confirmed.

What actually separates one confirmed provider from another

Once a provider clears the bar of "has published Arc-specific documentation," the differences that matter operationally are worth naming even at the testnet stage, because they carry forward into how each provider will likely handle mainnet. Archive-node access — the ability to query historical chain state rather than only recent blocks — matters for indexing, analytics, and auditing use cases, and dRPC explicitly lists archive-node support in its published Arc testnet material; not every provider states this as clearly. Rate limits and pricing tiers vary by provider and by plan, and are worth checking directly rather than assumed equivalent — dRPC, for instance, publishes a specific free-tier and paid-tier structure with stated request-per-second limits, which is more transparency than some competitors offer pre-mainnet. WebSocket support (for real-time event subscriptions rather than repeated polling) is listed by dRPC specifically; whether other confirmed providers support it for Arc is worth checking against their own current documentation, since testnet-stage feature sets can change quickly as providers build out mainnet readiness.

Self-hosted nodes: the option this comparison doesn't cover

Everything above assumes using a third-party RPC provider rather than running Arc node software directly. Circle publishes its own node-running documentation (circlefin/arc-node on GitHub), for teams that want direct infrastructure control rather than depending on a third party — relevant for institutions with existing node-operations capacity, or for anyone who wants to avoid provider-specific rate limits and dependency entirely. That's a materially different operational commitment than picking a provider from the table below, and outside this guide's scope, but worth knowing the option exists before assuming a third-party RPC provider is the only path onto Arc. For the broader infrastructure picture beyond RPC specifically — oracles, indexers, wallet infra — see Built on Arc's infrastructure providers overview.

The directory

Every "testnet" status in that table means exactly that — testnet — because nothing in this category has a mainnet equivalent to point to yet. Treat any provider claiming "Arc mainnet support" before Arc itself has published mainnet RPC details with real skepticism: they would be building against an endpoint that does not yet officially exist.

The safety point worth repeating on its own

Because Arc has not published an official mainnet RPC or explorer URL as of 2 Sep 2026, any URL circulating claiming to be "the Arc mainnet RPC" or "the Arc mainnet explorer" ahead of the 16 September launch should be treated as unverified at best. This is exactly the kind of gap opportunistic phishing infrastructure exploits around a major chain launch — a fake "official" endpoint designed to intercept transactions or credentials before the real one is public. Confirm any mainnet endpoint against Arc's own official channels once mainnet actually launches, not against a third-party post claiming to have early access to it.

What changes once Arc publishes a mainnet RPC

Once Arc's own canonical mainnet endpoint exists, the useful comparison work actually starts: which third-party providers stand up a mainnet-equivalent endpoint quickly, what rate limits and pricing they attach to it, and whether archive-node access (needed for historical queries, analytics, and some indexing use cases) is available at launch or added later. None of that is answerable yet — this guide will be updated once it is.

Built on Arc is an independent directory. Arc is a Circle product; we are not affiliated with, endorsed by, or operated by Circle.

Sources: - Arc node providers documentation - Arc RPC | QuickNode Docs - ARC | GetBlock Docs - Arc Testnet RPC URL & devtools | Alchemy - Arc RPC Endpoints | dRPC - Chainstack introduces Arc testnet support - RPC endpoints - Arc Docs - ARC Mainnet RPC and Chain settings | ChainList