Arc RPC Documentation

Arc RPC

With Dwellir, you get access to our global Arc network which always routes your API requests to the nearest available location, ensuring low latency and the fastest speeds.

Get your API key

Why Build on Arc?

Arc is Circle's Layer 1 for programmable money. It is EVM compatible, so Solidity, Foundry, Hardhat, viem, and ethers all work unchanged. Two things make it behave differently from every other EVM chain you have integrated: USDC is the native gas token, and blocks are final the moment they commit.

Stablecoin-Native Economics

• USDC pays for gas - No separate gas asset to acquire, hold, or top up. Users transact in the same unit they hold.
• Predictable fees - An EIP-1559 market with EWMA smoothing targets roughly $0.01 per transaction, so short demand spikes do not propagate into sudden fee jumps.
• Dollar-denominated cost - Fee estimates convert directly to dollars, which simplifies checkout, treasury, and reconciliation logic.

Deterministic Finality

• Sub-second settlement - Malachite BFT consensus finalizes blocks in under a second on a Proof-of-Authority validator set.
• No reorgs - A transaction is either unconfirmed or final. One confirmation is enough; there is no confirmation-count threshold to tune and no rollback path to write.
• ~0.5 second blocks - Fast enough for point-of-sale flows and multi-step onchain workflows that would otherwise need polling between steps.

Standard EVM Tooling

• Osaka baseline - Arc targets the Osaka hard fork, including EIP-7702 set-code transactions, and ships EIP-7708 ahead of upstream.
• Reth execution - The execution layer is Reth, so standard Ethereum tooling works unchanged. Dwellir's launch endpoint runs Arc's documented full-provider profile: eth_*, net_*, and web3_*, plus Arc-specific reads such as arc_getCertificate.
• HTTPS and WebSocket - The same endpoint shape and authentication model as every other EVM network on Dwellir.

Quick Start with Arc

Connect to Arc mainnet through Dwellir's HTTPS and WebSocket endpoints:

Arc RPC Endpoints

HTTPShttps://api-arc-mainnet.n.dwellir.com/<API_Keys_Are_Not_Made_for_Bots>

WSSwss://api-arc-mainnet.n.dwellir.com/<API_Keys_Are_Not_Made_for_Bots>

curlJavaScriptPythonGo

curl -sS -X POST https://api-arc-mainnet.n.dwellir.com/<API_Keys_Are_Not_Made_for_Bots> \  -H 'Content-Type: application/json' \  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

Installation and Setup

Network Specifications

API Reference

Arc supports the standard Ethereum JSON-RPC surface. Dwellir's launch endpoint runs Arc's documented full-provider profile, so debug_*, trace_*, and txpool_* are not enabled yet; those calls return -32601 Method not found.

Mining methods are not documented for Arc. There is no proof-of-work and no miner: blocks are produced by a rotating proposer from the Proof-of-Authority validator set, so eth_mining, eth_hashrate, and eth_coinbase have no meaning on this network.

RPC Capabilities

What Changes When USDC Is the Gas Token

These are the Arc behaviors most likely to break an integration ported from another EVM chain. Each one is also documented on the individual method pages.

Two decimal precisions, one balance

USDC on Arc exposes the same balance through a native interface (18 decimals) and an ERC-20 interface (6 decimals) at 0x3600000000000000000000000000000000000000. There is no wrapper token and these are not two assets.

const native = await provider.getBalance(address);        // 18 decimals
const display = native / 10n ** 12n;                      // USDC, 6-decimal units

Credit and record balances from the 18-decimal value. The ERC-20 view truncates sub-USDC fractions, so crediting from balanceOf records less than was transferred, and a balanceOf of 0 does not prove the account is empty. Never mix msg.value with USDC.balanceOf() in pool or collateral math: the raw values differ by a factor of 10¹².

The 20 Gwei fee floor is a silent failure

Arc enforces a 20 Gwei minimum base fee. A transaction whose maxFeePerGas falls below it is dropped by the mempool: no error receipt, no block inclusion, no explanation. Clamp every estimate to the floor before signing.

const MIN_FEE = ethers.parseUnits('20', 'gwei');
const feeData = await provider.getFeeData();

const maxFeePerGas = feeData.maxFeePerGas > MIN_FEE ? feeData.maxFeePerGas : MIN_FEE;
const tx = await wallet.sendTransaction({ to, value, maxFeePerGas });

The next block's base fee is published in the parent header's extraData as an 8-byte big-endian value, so you can price for the block you are about to land in rather than extrapolating from history.

Native transfers emit logs, from two emitters

Arc implements EIP-7708, so native USDC movement emits a standard ERC-20 Transfer log. USDC activity therefore arrives from two emitters that share the same topic0:

Filter on the emitter address, not topic0 alone. An ERC-20 transfer() produces a log from both emitters for one movement, so an indexer that matches on topic0 double-counts it. A plain native send produces only the system log. Gas is not emitted as a Transfer, so derive it from the receipt.

// Native USDC movement only, 18 decimals
const logs = await provider.send('eth_getLogs', [{
  address: '0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE',
  topics: ['0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef'],
  fromBlock: '0x0',
  toBlock: 'latest',
}]);

A value transfer can revert with a funded sender

Because the native token is USDC, value movement is subject to rules that do not exist on a standard EVM chain:

• A value-bearing transfer to 0x0 reverts with Zero address not allowed. A zero-value transfer to 0x0 succeeds.
• Transfers to or from a blocklisted address revert. The transaction is still included and still consumes gas.
• Burning is forbidden: self-destructing to yourself with a balance, or sending value to an already self-destructed account, reverts.
• Sending value to a precompile address reverts. Sending to an address with no code succeeds and emits a Transfer log.

Forwarding native value to a contract is not guaranteed to succeed, which breaks a common DeFi assumption. Simulate value-bearing calls before signing.

Header fields that do not behave like Ethereum

• mixHash / PREVRANDAO is always 0. There is no onchain randomness, so use an oracle or VRF.
• parentBeaconBlockRoot is the parent execution block hash, and the EIP-4788 beacon-roots contract is omitted, so reads return empty.
• timestamp is non-decreasing rather than strictly increasing. Sub-second blocks can share a timestamp, so order events by block number.
• withdrawals is always empty.

The EIP-2935 historical block hash contract is deployed and functional, as are CREATE2 and EIP-7702.

Common Integration Patterns

Verify the Network Before Sending Transactions

import { JsonRpcProvider } from 'ethers';

const provider = new JsonRpcProvider(
  'https://api-arc-mainnet.n.dwellir.com/YOUR_API_KEY'
);

const network = await provider.getNetwork();
if (network.chainId !== 5042n) {
  throw new Error(`Expected Arc (5042), received ${network.chainId}`);
}

Settle on One Confirmation

Deterministic finality removes the confirmation-count logic that probabilistic chains require. Once a receipt exists, the transaction is irreversible:

const receipt = await provider.waitForTransaction(txHash, 1);
console.log('Final in block', receipt.blockNumber);

Persist the block number and hash for auditability, then act on the receipt. There is no reorg path to handle.

Keep Stateful Filters on One Backend

Filter IDs belong to the backend that created them. Create, poll, and uninstall a filter over one persistent WebSocket connection. For HTTP, preserve the DWSESSION cookie between requests; connection reuse alone does not pin requests to one backend. If a filter expires or the backend changes, recreate it and backfill with eth_getLogs from the last processed block.

Troubleshooting

Transaction submitted, no receipt, no error

The most likely cause is a maxFeePerGas below the 20 Gwei floor. Underpriced transactions are dropped by the mempool without producing an error receipt. Raise maxFeePerGas to at least 20 Gwei and resubmit.

transaction underpriced

Same root cause, surfaced at submission instead of silently. Set maxFeePerGas to at least ethers.parseUnits('20', 'gwei').

insufficient funds for gas * price + value

On Arc, gas and value are paid from the same USDC balance. Fund the account to cover value + maxFeePerGas × gasLimit, not just the transfer amount.

Balances look 10¹² times too large or too small

You are mixing the 18-decimal native value with the 6-decimal ERC-20 value. Pick one interface per code path and convert explicitly at the boundary.

Duplicate transfers in an indexer

You are counting Transfer logs from both the system emitter and the ERC-20 contract. Filter on the emitter address.

method not found for a mining method

Arc has no mining. Use eth_getBlockByNumber and read miner if you need the block proposer.

Official Resources

• Arc documentation
• RPC endpoints
• EVM differences
• Gas and fees
• USDC system events
• Contract addresses
• Arc mainnet explorer
• Arc network status
• Dwellir dashboard