Skip to content
USDC Price:$1.0000Gas:
Arcscan

Arc blockchain explorer

Arcscan documentation

How to read Circle’s Arc chain in Arcscan — what each screen shows, where the numbers on it come from, and exactly where our coverage ends.
Read-only by designArcscan reads the chain and does nothing else. Reading any page here needs no account, no wallet and nothing to approve; the few optional tools that can send a transaction — the write tab on a verified contract, the approval revoker — hand it to your own browser wallet, which is the only thing that ever holds a key, and only after you click. No screen here will ever ask you for a private key or a seed phrase. Anything that does is not us.

Start with what you need#

Six places worth reading first. Each one is a page of this documentation, not a screen of the explorer.

Understand the data#

Every figure in Arcscan is either read from a node or derived from our own index of the chain. The difference is the only thing you need to carry around: the chain has no edges and the index has several.

Following the tip#

Arc produces a block about every half second — 506 ms on mainnet and 536 ms on testnet, measured 2026-08-10 — and reports finality as instant, so a block that exists is settled and there are no reorganisations to wait out. The indexer follows the head rather than sitting on it, so the newest blocks can exist on chain a moment before Arcscan can answer about them: at the time of measurement the mainnet index sat 13 blocks behind the head, roughly seven seconds. Nothing is hidden while that gap closes; a block Arcscan has not reached yet reads as not indexed, never as empty.

Indexed history#

On mainnet the index reaches the beginning of the chain: one contiguous range from block 0 through 14,852,068 with no gaps in it, measured 2026-08-10. On testnet it does not — Arcscan’s testnet history begins at block 53,500,000, and the 53,500,000 blocks below that point are not indexed here at all, so no Arcscan surface can answer for them. An empty result for that range is our missing history, not the chain’s. A third stream, traces, has no blocks indexed on mainnet at all, so mainnet internal-call history is not available from the index today.

Derived values#

Holder counts, token balances, transfer histories and address activity are computed from the index, not read from a node on demand. That makes them fast and it makes them fallible in one specific way: a value can be behind the head, and a value that depends on a range we do not hold cannot be computed at all.

A missing value is shown as missing

Where Arcscan cannot compute or retrieve something — a pruned block body, an unindexed range, a stream with no data — the field says so in words. It is never filled with a zero, and a blank is never an assertion that the true answer is nothing.

Every boundary above is written out per chain and per stream in Data coverage, and the live per-stream lag is on the explorer’s own node status page if you need today’s figure rather than the one measured above.

Network details#

Both chains, side by side, as measured from our own API on 2026-08-10.

MainnetTestnet
Chain id5042 · 0x13b25042002 · 0x4cef52
Native currencyUSDC, 18 decimals — gas is paid in USDC on this chain, not in etherUSDC, 18 decimals
Block time506 ms536 ms
Finalityinstantinstant
Public JSON-RPChttps://rpc.arc-scan.ioOpens in a new tabnot offered by Arcscan
Explorerhttps://arc-scan.ioOpens in a new tabhttps://testnet.arc-scan.ioOpens in a new tab
Contract verificationnot available — Sourcify does not list chain 5042available

Each hostname serves exactly one chain: arc-scan.io is mainnet 5042 and nothing else, testnet.arc-scan.io is 5042002 and nothing else. Contract verification is unavailable on mainnet because Sourcify does not list chain 5042, so no contract on that chain can be verified today — through Arcscan or through any other Sourcify client. Nothing there is waiting on us; it is waiting on the chain being added upstream. On testnet, verification does work, but what Arcscan holds is a cache filled on first request, so the number of contracts it has source for is much smaller than the number that are verified.

Our public RPC is mainnet-only, read-only, and answers the ordinary read methods behind several independent upstream providers with failover. Confirming which chain you have reached takes one call:

$ curl -s -X POST https://rpc.arc-scan.io \
    -H 'content-type: application/json' \
    --data '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x13b2"
}

The methods, the limits and the failover behaviour are in Public RPC; the HTTP data API the explorer itself runs on is in REST API.

Know the boundaries#

Arcscan documents what it can show and refuses the rest out loud. Three pages carry every limit we know about, and reading them is faster than discovering one at the point you need it.

  • Data coverage — what is indexed, per chain and per stream, and what each surface answers when it is asked past the edge.
  • Glossary — the words this explorer uses, and the few Arc uses differently from the chains you already know.
  • FAQ — the questions readers actually arrive with, answered short.

Need a quick answer?

Paste a hash, an address or a block number into the search box and the explorer will work out what it is — Search lists every input it accepts. If the question is about Arcscan rather than about a value, the FAQ is the shorter path.
Overview · Arcscan docs | Arcscan