How to get an Arc RPC endpoint (2026 guide)

TL;DR

On Arc, a stablecoin payment can land on-chain, show a successful receipt in your UI, and still be wrong — because USDC exposes an 18-decimal native balance and a 6-decimal ERC-20 view of the same funds, and because every native USDC movement emits a protocol-level Transfer log your indexer has to catch. Arc is Circle’s USDC-native, EVM-compatible L1 for stablecoin finance, running the Reth execution client under Malachite BFT consensus with sub-second deterministic finality. This guide covers how Arc RPC actually behaves, where public endpoints break for payment workloads, and how to get a production endpoint on Chainstack.

What is an Arc RPC endpoint

Arc’s RPC endpoint is the JSON-RPC interface your application uses to talk to an Arc node — submit signed transactions, read balances, call contracts, and subscribe to events. Because Chainstack runs Arc on the Reth client, the node exposes the full standard Ethereum surface across the eth, debug, trace, txpool, net, web3, and rpc namespaces, plus a custom arc namespace for consensus commit certificates. So ethers.js and viem work out of the box. The twist is what those methods return: USDC is the native gas token, so eth_getBalance reports a wallet’s spendable dollars in 18-decimal wei-style units, while the same balance viewed through the ERC-20 interface reads in 6 decimals. Both are the same money — the node just presents it two ways.

On Arc specifically, the endpoint is what backs every user-facing action in a stablecoin app:

• Broadcasting USDC and EURC payments with eth_sendRawTransaction (Arc requires EIP-155 replay-protected transactions)
• Reading dollar balances via eth_getBalance (18-decimal native) or the ERC-20 balanceOf view (6-decimal)
• Tracking settlement by streaming EIP-7708 native Transfer logs — Arc emits a standard Transfer event from a system address for every native USDC movement, not just ERC-20 token calls
• Batching reads through the deployed Multicall3 contract for wallet and balance dashboards
• Simulating fee, gas, and compliance outcomes with eth_call, eth_estimateGas, and the debug_*/trace_* methods before a payment leaves the wallet
• Confirming finality — Arc’s Malachite BFT consensus gives deterministic settlement on inclusion in ~0.48-second blocks, so one confirmation is final

You can review the full set of network parameters and supported methods in the Arc connect documentation.

Endpoint quality on Arc is not about raw throughput — it is about log fidelity. If your provider drops or lags on eth_getLogs, you don’t just miss an analytics event; you miss a payment, because on Arc the log is the payment record.

How Arc RPC differs from Ethereum RPC

Arc is EVM-compatible, so the method names match Ethereum — but several execution and fee-market behaviors diverge in ways that directly change how you build a payment backend. These are the differences that matter for RPC selection:

Property	Ethereum	Arc
Gas token	ETH (18 decimals)	USDC — native 18-decimal + ERC-20 6-decimal view of the same balance
Client / consensus	Geth/Reth/others, probabilistic finality	Reth + Malachite BFT, deterministic sub-second finality
Block time	~12s	~0.48s
Fee market	EIP-1559 with base-fee burn	Base fee paid to block beneficiary, no burn; next base fee in parent header extra_data
Native transfer logs	None (ETH sends emit no log)	EIP-7708: every native USDC movement emits a Transfer log from a system address
Pending mempool	Observable via pending filters/subscriptions	Not observable — eth_newPendingTransactionFilter and pending subscriptions return -32001
Value transfers	Succeed if balance is sufficient	Can revert on blocklisted addresses, zero-address, or precompile targets despite sufficient balance

Three of these drive provider choice more than anything else. First, EIP-7708 native transfer logging means your reconciliation pipeline depends entirely on complete, correctly-ordered eth_getLogs responses and reliable log subscriptions — a provider that truncates ranges or silently caps results will corrupt your ledger. Second, protocol-level blocklist and value-transfer rules mean a payment can revert for compliance reasons, so you need consistent eth_call simulation and the trace_* namespace to know why a transfer failed before you retry it. Third, because the pending mempool is not observable, any “transaction submitted” UX has to key off inclusion and finality, not a pending-pool watch that will never fire.

Arc RPC endpoint options

Public vs private Arc RPC endpoints

The public vs private decision on Arc comes down to a single question: can the endpoint keep a complete, gap-free record of every USDC movement under real payment load? A shared endpoint answers fine for a wallet demo and poorly for a settlement service that reconciles thousands of transfers an hour.

Official public endpoints (Arc Testnet):

• Mainnet: Arc mainnet is rolling out through 2026
• Testnet: https://rpc.testnet.arc.io (WebSocket: wss://rpc.testnet.arc.io)

⚠️ The public Arc testnet endpoint is a shared, best-effort resource with no delivered rate-limit or log-range guarantees, and no archive retention SLA. For payment reconciliation — where a single dropped eth_getLogs page silently loses a transfer — this is the wrong foundation. The Arc EVM differences documentation spells out the native-transfer-log and value-revert behavior that makes complete log delivery non-negotiable, which is exactly why teams move to professional providers before launch.

Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
eth_getLogs reliability	Best-effort, may cap ranges	Full ranges, consistent delivery
Archive + debug/trace history	Not guaranteed	Available (Full + Archive, 19 debug/trace methods)
WebSocket log subscriptions	Unmetered, may drop	Stable with reconnect support

Because Arc records money movement as logs, a shared endpoint that caps or drops eth_getLogs doesn’t degrade gracefully — it under-reports settled payments, and you won’t notice until a reconciliation mismatch surfaces days later. That is the case for a managed endpoint with guaranteed log delivery.

Full node vs archive Arc node

On Arc, historical data access is not an analytics luxury — it is how you rebuild a payment history, because every settled transfer only exists as an EIP-7708 log in block history. A full node serves recent state; an archive node lets you replay the complete money trail. One Arc-specific detail worth budgeting for: Chainstack documents that most historical queries bill as archive once they reach ~127 blocks behind the tip — roughly a minute of history — because Arc’s sub-second blocks push data out of the recent-state window fast.

Full node access	Archive node access
Current USDC balances and live settlement status	Complete EIP-7708 transfer-log history for reconciliation
Real-time payment broadcasting and confirmation	Point-in-time balance reconstruction for audits
Recent eth_getLogs queries for active monitoring	Historical debug_traceTransaction / trace_replayTransaction of reverted payments

Chainstack supports Arc nodes in both Full and Archive modes, with the full debug_* and Parity-style trace_* namespaces available on each — so you can reconstruct exactly why a compliance-triggered transfer reverted months after it happened. For stablecoin operators facing audit, dispute, or regulatory-reporting requirements, that historical replay is the difference between a defensible ledger and a guess. When you need to backfill or audit the full transfer history, an archive node is the only source that has it.

HTTPS vs WebSockets

For a payment backend, the split is simple: HTTPS handles the request/response work — submitting transactions, checking balances, running historical eth_getLogs backfills — while WebSockets handle the thing Arc makes central, live settlement monitoring. When a customer is waiting on a payment confirmation, a persistent eth_subscribe stream on native Transfer logs and new heads beats polling every block.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	Payment submission, balance reads, archive log backfills	Live EIP-7708 transfer-log and new-head subscriptions
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

One caveat unique to Arc: pending-transaction subscriptions don’t work — the mempool is not observable, so eth_subscribe("newPendingTransactions") returns -32001. Subscribe to logs and new heads instead. And because shared public connections drop under load with no reconnect guarantees, any subscription-based settlement monitor needs reconnect logic plus an eth_getLogs backfill step to recover transfers missed during the gap.

How to get a private Arc RPC endpoint with Chainstack

Deploying a private Arc RPC node on Chainstack takes a few minutes and gives you an endpoint built for stablecoin payment reliability rather than best-effort testing:

1. Log in to the Chainstack console (or create an account).
2. Create a new project
3. Select Arc as your blockchain protocol
4. Choose network: Arc Testnet
5. Deploy the node — choose Full or Archive mode depending on whether you need full transfer-log history
6. Open Access/Credentials and copy your HTTPS and WebSocket endpoints
7. Run a quick connectivity check before wiring it into production code

Because Arc is EVM-compatible, you connect with standard tooling. Here is the viem chain definition from the Chainstack Arc tooling docs — note the 18-decimal USDC native currency and the pre-deployed Multicall3 address:

import { createPublicClient, http, defineChain, formatEther } from "viem";

export const arcTestnet = defineChain({
  id: 5042002,                          // Arc Testnet chain ID (hex 0x4cef52)
  name: "Arc Testnet",
  testnet: true,
  nativeCurrency: { decimals: 18, name: "USDC", symbol: "USDC" }, // native USDC is 18-decimal
  rpcUrls: { default: { http: ["YOUR_CHAINSTACK_ENDPOINT"] } },
  contracts: {
    multicall3: { address: "0xcA11bde05977b3631167028862bE2a173976CA11" },
  },
});

const client = createPublicClient({ chain: arcTestnet, transport: http() });
console.log("Balance:", formatEther(await client.getBalance({ address: "0xYourAddress" })), "USDC");

📖 For the full integration guide, chain configuration, and the custom arc_getCertificate example, see the Chainstack Arc tooling documentation.

You can also access Chainstack Arc RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP.

Arc isn’t on Chainlist yet — the network is still early in its rollout — so there is no wallet-import shortcut to lean on; you add the network manually using the chain ID (5042002) and your endpoint URL.

Chainstack pricing for Arc RPC

Chainstack bills on request units rather than opaque compute credits, so you can map payment volume to cost directly instead of reverse-engineering a credit multiplier. See the full Chainstack pricing page for plan details and overage rates.

Plan	Cost	Requests/Month	RPS	Overage (per 1M extra)
Developer	$0	3M RU	25	$20
Growth	$49	20M RU	250	$15
Pro	$199	80M RU	400	$12.50
Business	$499	200M RU	600	$10
Enterprise	$990+	400M+ RU	Unlimited	$5

Archive requests count as 2 RU each (versus 1 RU for full-node requests), which matters on Arc more than on most chains: because queries older than ~127 blocks bill as archive, even “recent” reconciliation lookups on a sub-second chain tip into archive rates quickly. For predictable high-volume payment traffic, the Unlimited Node add-on swaps per-request billing for flat-fee RPS tiers, and Dedicated Nodes start at $0.50/hour plus storage for isolated infrastructure.

How to estimate monthly cost

1. Estimate baseline read volume (balance checks, payment status polls) per day
2. Add write volume (payment broadcasts) and multiply by expected retries
3. Add reconciliation load — historical eth_getLogs backfills, doubled for archive RU
4. Convert to monthly request units and match against the plan tiers above
5. On Arc, transfer-log monitoring is your heaviest sustained cost, and the ~127-block archive cutoff means most reconciliation reads bill at 2 RU — size your archive RU budget around continuous transfer tracking, not one-off payment submission.

Production readiness checklist

• Primary + fallback RPC provider configured
• Request timeout policy set
• Retry logic with exponential backoff implemented
• Credentials stored in env/secret manager (never hardcoded)
• Monitoring for latency, error rate, and throttling
• Alerts for sustained degradation
• Decimal handling validated end-to-end — 18-decimal native USDC vs 6-decimal ERC-20 view reconciled in every balance display and accounting entry
• EIP-7708 native Transfer logs indexed alongside ERC-20 events so no settled payment is missed
• All transactions EIP-155 replay-protected before signing
• Confirmation UX keyed off inclusion/finality, not pending-mempool watches (which return -32001 on Arc)
• Blocklist/compliance revert handling — payments simulated with eth_call before broadcast, with a clear user path when a transfer reverts on policy grounds

Troubleshooting common Arc RPC issues

Issue	Cause	How to fix
429 Too Many Requests	Shared public endpoint throttling under payment load	Move to a managed endpoint with dedicated resources
WebSocket disconnects mid-settlement	Shared connection dropped, subscription lost	Add reconnect logic plus an eth_getLogs backfill for the gap window
-32001 on pending-tx filter/subscription	Arc mempool is not observable	Drop pending-pool watching; subscribe to logs and new heads, key UX off inclusion
Balance displays off by ~12 decimals	Mixing 18-decimal native USDC with the 6-decimal ERC-20 view	Standardize on one interface per code path; convert explicitly at boundaries
Reconciliation missing settled payments	Only indexing ERC-20 Transfer events, not EIP-7708 native transfer logs	Subscribe to and backfill native Transfer logs from the system address
Payment reverts despite sufficient balance	Blocklisted address, zero-address, or precompile-target transfer blocked by protocol	Simulate with eth_call/trace_call first; surface the revert reason instead of blind-retrying
Transaction rejected before broadcast	Missing EIP-155 replay protection	Sign with the Arc chain ID (5042002) so the transaction is replay-protected

Conclusion

The failure mode on Arc is quiet. A payment reverts because the counterparty landed on a compliance blocklist, but your retry loop just keeps firing; or your dashboard shows a customer $1,000,000 in the black because a 6-decimal ERC-20 read got formatted as 18-decimal native; or your month-end reconciliation is short three payments because your indexer only watched ERC-20 events and never subscribed to the EIP-7708 native transfer logs where the money actually moved. None of these throw a loud error. They surface as a mismatch days later, in an audit or a support ticket.

The pattern that works: treat log delivery as the core reliability requirement, not an afterthought. Run a managed endpoint with full, un-truncated eth_getLogs and stable WebSocket subscriptions as your primary, keep a fallback provider configured, and put an archive node with debug/trace behind your reconciliation pipeline so you can always rebuild — and explain — the complete transfer history. Simulate every payment before broadcast, sign everything EIP-155, and reconcile the 18/6-decimal split at every boundary. These are not optimizations — on a chain where the log is the ledger, they are the baseline.

Start on the free Developer tier to test against Arc Testnet, and move to dedicated infrastructure before you handle real settlement volume.

FAQ

Does ethers.js and viem work on Arc without changes? Yes for connection and method calls — Chainstack runs Arc on the Reth client with the standard eth, debug, trace, txpool, net, web3, and rpc namespaces, so ethers.js and viem connect the same way they do on Ethereum. The change is in how you interpret results: the native balance is 18-decimal USDC rather than ETH, you must index EIP-7708 native Transfer logs, and pending-transaction watching is unavailable — so your parsing and monitoring logic needs Arc-specific handling even though the SDK does not.

Why can’t I see pending transactions on Arc? Arc does not expose the mempool through RPC. eth_newPendingTransactionFilter and the newPendingTransactions subscription return a -32001 error. With sub-second deterministic finality there is little practical window to watch anyway — build confirmation UX around block inclusion and finality instead of a pending-pool watch.

Why can a payment revert on Arc when the sender clearly has enough USDC? Arc enforces transfer rules at the protocol level. A value transfer reverts if the source or destination is on a blocklist, if it targets the zero address or a precompile, or if it would burn funds in a forbidden way — regardless of balance. Simulate payments with eth_call or trace_call before broadcasting and surface the revert reason to the user instead of retrying blindly.

Do I need an archive node for a stablecoin app on Arc? If you reconcile payments, serve transaction history, or face audit and compliance reporting, yes. Because settled transfers exist only as EIP-7708 logs in block history — and because queries older than ~127 blocks already bill as archive on Arc’s sub-second chain — rebuilding a complete payment record requires archive access with debug/trace. A full node is enough for live balance reads and payment submission alone.

How does Arc’s finality affect payment confirmation UX? Arc pairs the Reth execution client with Malachite BFT consensus for deterministic finality on inclusion, so a transaction is final in under a second (~0.48s blocks) and does not need multiple confirmations. You can show a settled state to the user as soon as the transaction is included, without the multi-block confirmation waits Ethereum requires.

What’s the difference between the 18-decimal and 6-decimal USDC views? They are two interfaces to the same balance. The native interface (used for gas and msg.value) represents USDC in 18 decimals, while the ERC-20 balanceOf view uses the standard 6 decimals and truncates amounts below one-millionth of a dollar. Pick one representation per code path and convert explicitly at the boundaries — mixing them is the most common source of wrong balance displays on Arc.

Additional resources

• Arc API reference: JSON-RPC quickstart on Chainstack — network details, namespaces, and the Arc-specific quirks documented above
• Arc tooling documentation — viem/ethers chain configuration, Multicall3, and the custom arc namespace
• Ethereum logs tutorial series: logs and filters — the eth_getLogs and filter patterns you’ll use to track Arc’s EIP-7708 native transfer logs
• Chainstack stablecoin infrastructure — SOC 2 Type II infrastructure for cross-border settlement, treasury, and tokenized assets