- Category
- Networks
- Reading time
- 10 minutes
- Published
- Updated
Arc Testnet RPC: public endpoint and developer guide
Arc Testnet is now available through SolidRPC with a keyless public RPC endpoint at https://rpc.solidrpc.io/public/evm/5042002. Developers can connect a wallet, deploy contracts, send transactions, and test standard EVM JSON-RPC calls without creating an account or managing an API key.
Arc is a stablecoin-native Layer 1 built for financial applications. It combines EVM tooling with USDC-denominated gas and deterministic finality, making its testnet especially relevant for teams building payments, lending, foreign-exchange, treasury, and agentic-commerce products.
This guide gives you the Arc Testnet chain ID, a copy-paste RPC request, the public endpoint policy, the cases that need an authenticated SolidRPC endpoint, and the Arc-specific EVM differences to test before shipping.
Arc Testnet RPC quick reference
- Public RPC URL:
https://rpc.solidrpc.io/public/evm/5042002 - Chain ID:
5042002(0x4cef52) - Network type: Testnet Layer 1
- Native gas currency: USDC
- Transport: HTTPS JSON-RPC 2.0
- WebSocket: Not currently available through SolidRPC
- Block explorer: ArcScan Testnet
- Faucet: Circle Faucet
The public RPC is designed for wallets, development, testing, and lightweight application traffic. Testnet USDC has no monetary value, and developers should treat every Testnet address, endpoint, and chain parameter as separate from any future Arc mainnet configuration.
Why Arc Testnet matters for stablecoin applications
Arc is purpose-built for stablecoin-native financial applications rather than adding stablecoins as an afterthought. USDC is the native gas token, so fees are denominated in a unit that developers and users can reason about without holding a separate volatile token solely to transact. Arc also supports stablecoin-oriented assets including EURC and USYC.
The network pairs that model with sub-second deterministic finality and EVM compatibility. Solidity contracts and familiar tools such as Foundry, Hardhat, Viem, ethers.js, and standard Ethereum wallets can be used for most development workflows. According to Arc's current documentation, testnet blocks are produced in roughly 0.48 seconds and transactions finalize when included.
That combination is relevant to products where settlement speed and fee legibility matter: cross-border payments, merchant settlement, lending, foreign exchange, treasury operations, and autonomous software agents that pay for services. Arc Testnet gives teams a place to validate those workflows before using real funds or relying on production infrastructure. See the official Arc overview for the network model and current feature set.
How to call the SolidRPC Arc Testnet public RPC
Send a standard JSON-RPC request to the public endpoint. This example verifies the network identity:
curl -s -X POST 'https://rpc.solidrpc.io/public/evm/5042002' -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
A healthy Arc Testnet endpoint returns 0x4cef52, the hexadecimal representation of chain ID 5042002. You can then replace eth_chainId with standard methods such as eth_blockNumber, eth_getBalance, eth_call, or eth_sendRawTransaction.
For a wallet or application configuration, use the public RPC URL, chain ID 5042002, currency symbol USDC, and the ArcScan Testnet explorer URL. Keep the chain ID check in automated setup tests so a copied endpoint cannot silently point the application at the wrong network.
What the keyless public Arc RPC supports
SolidRPC's keyless endpoint accepts standard eth_*, net_*, and web3_* methods, including eth_sendRawTransaction. It supports HTTPS POST requests and browser CORS, with one JSON-RPC call per request — multi-call batches return JSON-RPC -32600 and need an authenticated endpoint instead. Policy refusals arrive as JSON-RPC errors over HTTP 200, so branch on error.code and error.data.reason rather than on the status code. The public method policy rejects debug_*, trace_*, Arc-specific arc_*, client-specific namespaces, and node-control methods.
Public eth_getLogs requests are bounded per chain, and 2,000 blocks is the maximum any listed chain receives. Arc Testnet currently has its own published provisional limit. A blockHash filter addresses one known block, so it neither counts toward a range budget nor narrows it. An oversized range is refused with -32602 and a suggested range you can re-send as-is. Split longer scans into bounded ranges and persist the last processed block number and hash so retries do not create gaps or duplicates.
The keyless endpoint also has published request, response-size, and shared-capacity limits. On HTTP 429, honor Retry-After and use exponential backoff with jitter. These boundaries make it useful for setup and lightweight traffic, but not for an unbounded indexer backfill. Check the SolidRPC public RPC policy for the current limits and error shapes instead of copying fixed values into application code.
When to use an authenticated Arc Testnet endpoint
Use an authenticated SolidRPC endpoint when the workload needs higher sustained throughput, account-level quotas, long historical scans, or Arc-specific RPC methods. The endpoint format is:
https://rpc.solidrpc.io/YOUR_API_KEY/evm/5042002
The Arc Testnet catalog includes archive-backed historical state, arc_getVersion, arc_getCertificate, debug_*, Parity-style trace_*, and read-only txpool_* methods on authenticated HTTPS endpoints. Debug, trace, and txpool calls require the self-hosted archive; the public fallback endpoints cannot serve them. The pending-transaction view may be incomplete because this follow node has no trusted transaction peers. WebSocket transport is not advertised. Customers use the same managed integration without operating a separate node or provider pool.
Do not infer method support from the word “archive.” Archive describes retained historical state; tracing namespaces are separate capabilities. Review the SolidRPC Arc Testnet documentation and probe every method and block depth your application requires before a sustained test or migration.
Arc EVM differences developers should test
Arc is EVM-compatible, but it is not behaviorally identical to Ethereum. A standard local EVM simulator cannot reproduce every Arc-specific rule, so contract ports need end-to-end tests against an Arc RPC endpoint.
The most important differences include:
- Native USDC has two decimal views. Native balance and
msg.valueaccounting use 18 decimals, while the ERC-20 USDC interface uses 6. Both interfaces represent the same underlying asset. Convert before comparing raw values; a zero 6-decimal ERC-20 view can still hide a smaller native balance. - Native transfers have additional rules. Transfers involving the zero address, blocklisted addresses, forbidden burns, or certain self-destructed accounts can revert even when the sender appears to have enough balance.
- `PREVRANDAO` returns zero. Contracts must not treat it as an onchain randomness source; use a suitable oracle or verifiable random function.
- Blob transactions are not supported. Arc Testnet rejects EIP-4844 type-3 transactions.
- Block timestamps are not strictly increasing. Sub-second blocks can share a one-second timestamp, so offchain systems should order by block number rather than assuming every block has a newer timestamp.
- Native value transfers emit logs. Arc implements EIP-7708-style
Transferevents for native USDC movements. Indexers must distinguish the 18-decimal system-emitter log from the ERC-20 contract's 6-decimal event to avoid double counting.
Arc maintains a detailed EVM differences reference. Treat that page as part of the protocol specification and repeat compatibility tests when Arc upgrades the testnet.
Arc Testnet deployment checklist
- Add chain ID
5042002and the correct RPC URL to the application and wallet configuration. - Request testnet USDC from the Circle Faucet and confirm the native balance on ArcScan.
- Verify
eth_chainId,eth_blockNumber, fee estimation, transaction submission, and receipt polling. - Deploy the real Solidity bytecode with the same compiler and optimizer settings intended for production.
- Test native USDC sends, ERC-20-style USDC calls, decimal conversion, revert handling, and any blocklist-sensitive path.
- Test Arc-specific behavior on the live testnet instead of relying only on Anvil or another standard local EVM.
- Validate event indexing, especially native USDC
Transferlogs, duplicate handling, and block-number ordering. - Split
eth_getLogsscans into public-policy-sized ranges or move sustained historical work to an authenticated endpoint. - Implement HTTP 429 handling, bounded retries, and a total request deadline.
- Keep Testnet keys, addresses, chain parameters, and assets isolated from production configuration.
The checklist is intentionally broader than “the contract deployed.” Financial applications also need to prove fee handling, accounting, indexing, failure recovery, and RPC-limit behavior under realistic traffic.
Arc Testnet RPC FAQ
Is there a free Arc Testnet RPC?
Yes. SolidRPC provides a keyless public HTTPS endpoint at https://rpc.solidrpc.io/public/evm/5042002. It is intended for wallets, development, testing, and lightweight traffic.
What is the Arc Testnet chain ID?
The decimal chain ID is 5042002; in hexadecimal it is 0x4cef52.
Does Arc use ETH for gas?
No. Arc uses USDC as its native gas token. Testnet USDC has no monetary value.
Does the SolidRPC public Arc endpoint support WebSocket or tracing?
No. The public endpoint is HTTPS only and rejects debug_*, trace_*, and arc_* methods. The authenticated endpoint adds Arc-specific methods, archive-backed historical state, debug_*, trace_*, and read-only txpool_* calls over HTTPS. Arc Mainnet is a separate paid-only network with these method families on its authenticated route. SolidRPC does not advertise WebSocket transport for either route.
Is Arc fully identical to Ethereum?
No. Arc supports standard EVM development tools and most Solidity contracts, but its native USDC model, value-transfer rules, opcode behavior, fee market, block timing, and event behavior include documented differences. Test contracts against Arc Testnet before assuming a port is complete.
Start building with Arc Testnet on SolidRPC
Use https://rpc.solidrpc.io/public/evm/5042002 for a quick wallet connection, contract deployment, or bounded application test. Move to https://rpc.solidrpc.io/YOUR_API_KEY/evm/5042002 when the workload needs authenticated quotas, archive-backed historical access, or Arc-specific RPC methods.
Before launch, read the official Arc RPC endpoint reference, the SolidRPC Arc Testnet guide, and the public RPC policy. Then test the exact calls your application will make—including failure cases—against the endpoint you plan to use.