Build on Circle's Arc: docs, RPCs, funding and going to mainnet

Building on Circle's Arc is ordinary EVM work with two differences that matter. Gas is paid in USDC rather than a native coin, which changes how you fund and monitor accounts; and the chain is new enough that several production values — the mainnet RPC endpoint and block explorer among them — had not been published as of 6 September 2026. Everything else is Solidity, standard RPC methods and the tooling you already use.

Start with the documentation

docs.arc.io is the primary source and the only one worth trusting for values you will hardcode. It carries the connection reference, the contract-address reference, the EVM-differences page, and Circle's own vendor lists for node providers, data indexers, oracles, account abstraction and compliance.

The EVM-differences page is the one teams skip and should not. As documented for testnet: there is no EIP-1559 base-fee burn, with both the base fee and the priority fee going to the block proposer; PREVRANDAO always returns zero; value transfers to already-destructed contracts or to precompile addresses revert; and native USDC transfers emit Transfer logs from a system address that an indexer has to de-duplicate against ERC-20 contract events. Circle also flags that the testnet fee-bound parameters — minimum and maximum base fee, throughput limits — may change before mainnet, so any fee assumption derived from testnet is provisional.

The values

Testnet is fully documented and stable: RPC https://rpc.testnet.arc.io, chain ID 5042002, explorer testnet.arcscan.app, faucet at faucet.circle.com. Mainnet chain ID is 1243 (hex 0x4db) per ChainList.

The mainnet RPC and explorer URLs were not published as of 6 September 2026. Take them from docs.arc.io the moment they appear and from no other source — not from a provider dashboard that has guessed, not from a launch-day thread, not from a search result. Any URL circulating as "the Arc mainnet RPC" before Circle publishes one is, at best, unverified.

RPC endpoints

Arc's own public endpoint is shared and rate-limited: fine for development, wrong for production traffic. Circle's node-providers documentation names four vendors directly — Alchemy, Blockdaemon, dRPC and QuickNode — and each publishes HTTP and WebSocket access for the testnet. QuickNode, Alchemy and dRPC each publish their own Arc documentation beyond Circle's listing, which is a stronger signal than a name on a list. GetBlock and Chainstack publish Arc material of their own without appearing on Circle's page; that is a different route to the same confirmation, not a lesser one. Ankr and Infura had published nothing Arc-specific as of 6 September 2026.

What to compare, once mainnet endpoints exist: rate limits in requests per second, whether archive-node access is available (you need it for indexing, analytics and anything historical), WebSocket support for event subscriptions, and price tiers. Do not compare on "lists Arc", which every provider will do by October.

Running your own node is the other option, and Circle publishes node software at circlefin/arc-node. That is a real operational commitment rather than a config change, but it removes provider rate limits and third-party dependency entirely, which some institutions will need.

Circle's App Kit, and what it is not

Circle publishes an SDK under the @circle-fin namespace bundling four capabilities — Send, Bridge (over CCTP and Gateway), Swap between USDC and EURC, and Unified Balance — with adapters for viem, ethers, Solana and Circle's own developer-controlled wallets. It is a library you install into an application, not a scaffolded starter project you clone and run; no CLI generator or pre-wired frontend template ships under that name.

Circle separately publishes open-source reference applications — commerce checkout, peer-to-peer payments with passkey wallets, escrow, x402 micropayments, a multichain treasury console — which are useful to read and are demonstrations rather than maintained products.

You do not need any of it. Arc is a standard EVM chain and ordinary Ethereum tooling works. The App Kit is a convenience layer over Circle-specific rails, worth taking if your application is mostly stablecoin movement and worth skipping if it is not.

What the kit does not cover

Account abstraction and gas sponsorship, indexing, monitoring and audits are all separate vendor choices. Circle's own documentation names third-party providers for account abstraction and data indexing, which is where to start rather than a general search — a vendor named in Arc's docs has at minimum been through Circle's own listing process, though it means Circle names them for Arc, not that a mainnet deployment exists.

Funding

Circle's Developer Grants programme is the documented path, applied for at circle.com/grant. It relaunched on 14 May 2026 and runs as a multi-stage review — grants team, then a technical review involving Circle Ventures, Product and Business Development — ending in a tailored milestone plan, with tiered USDC funding released as milestones are met rather than paid up front. Recipients also get co-marketing, technical guidance and partner introductions.

Six priority areas are named: agentic economic activity, stablecoin FX, peer-to-peer payments, treasury management, prediction markets, and lending and borrowing. The eligibility language is about alignment — Arc should be core to your flow of value, liquidity or settlement, with Circle products such as USDC, Circle Wallets, CCTP or Gateway as real building blocks rather than incidental — and Circle says it prioritises teams that can show shipping ability, usage, pilots, partnerships or revenue.

Circle has published no grant amounts, no funding ranges, no cohort size and no recipient list. Any specific figure you see attached to a Circle grant comes from a recipient's own disclosure or from press coverage, not from Circle. Circle also publishes Builders Fund material on circle.com alongside its pressroom and blog; check that page directly for its current terms rather than assuming they match the grants programme, because the two are presented separately and the fund's mechanics are not documented in the same detail.

The mainnet cutover checklist

Everything below is a value or an assumption that does not survive the move from testnet to mainnet.

• Chain ID 5042002 → 1243. Add a branch, not a substitution; testnet keeps running.
• RPC and explorer URLs. New, and not yet issued. Nothing you can prepare except the code path that reads them from config rather than from a constant.
• Contract addresses. Circle's published USDC, EURC, USYC, CCTP messenger and Gateway addresses are testnet-only, with mainnet marked not yet available. Every address in your source, subgraph manifest or indexer config is a value to replace.
• Gas. Faucet USDC becomes real USDC. That converts a five-minute faucet claim into a funded treasury operation: an owned gas wallet, a monitored balance, an alert before it hits zero, and gas booked as an operating cost.
• Fee assumptions. Re-verify against the mainnet reference rather than carrying testnet numbers forward.
• Your dependencies' timelines. Every third-party infrastructure vendor documented for Arc describes testnet in its own materials. Ask each one, in writing, when its mainnet endpoint or deployment lands, and have a fallback for the ones that answer vaguely.

Freeze your config a few days before the 16th, keep one person responsible for entering the mainnet endpoint values when Circle publishes them, and have that person verify against docs.arc.io rather than a forwarded message. Launch-day phishing works precisely because everybody is copying and pasting under time pressure.

When you have something running

Once you have something working on testnet or mainnet, add it to the Built on Arc directory — it is an independently maintained record of what is actually deployed on Arc, with a dated status and a source on each entry, and it is where people looking for what you have built will go before they find your homepage. Have your contract address, network, and a link to your own announcement ready; the whole value of that listing to a reader is the evidence attached to it.