Frequently asked questions

Almost always the wrong chain. Arc mainnet and Arc Testnet are two networks, served by two hostnames, each with its own separate index — neither one holds a single block of the other. A mainnet hash pasted into the testnet site will not resolve, and the reverse is equally true.

Every page states which chain it belongs to in its footer, together with that chain's id, so check that before concluding a hash does not exist. An address, unlike a hash, is valid on both chains and both pages will load: they are two unrelated histories that happen to share twenty bytes.

Arcscan's index of Arc Testnet begins at block 53,500,000. The blocks beneath it were never indexed here, so no Arcscan surface can answer for them — as /v1/chain puts it, an empty result for that range is Arcscan's missing history, not the chain's.

Such a block still opens, because its header is read from the node rather than from the index, and the page says outright which half is missing:

Mainnet is not affected: its index reaches block 0 and is contiguous from there. The per-stream detail is in Data coverage.

Because no mainnet contract can be verified anywhere yet. Arcscan reads verified source from Sourcify, and /v1/chain reports verified_source: false for chain 5042 with this note:

So a mainnet contract page shows what the chain itself provides and stops there. The verify form loads on mainnet, but it opens by saying the same thing — that Sourcify does not list chain 5042 as supported, so a submission would be rejected — rather than accepting an upload that cannot succeed. Nothing here waits on Arcscan.

Testnet is different: Sourcify does list chain 5042002, and /v1/chain reports verified_source: true there. What Arcscan holds, though, is a cache rather than a mirror:

The practical consequence is that the first person to open a given contract's page is the one who causes its source to be fetched. A contract verified upstream but never yet requested here has no source on its page — and that is a cache miss, not a statement about the contract.

On a single transaction's own page, where the calls it made are read live from the node. There is no chain-wide list on mainnet: that needs Arcscan's traces index, and today that index holds no blocks at all. Asked for one, the API refuses in words instead of returning an empty page:

An empty list would have read as “no internal calls happened”, which is a different claim and a false one. This is the shape of every gap on the site: a sentence where the data is not held, never a zero.

No — treat them as indicative. A token price here is derived from an on-chain pool, and Arcscan publishes the pool it came from and the block it was observed at alongside it so the figure can be checked rather than believed. Where no pool clears the depth floor there is no price, and the page says so in prose instead of showing a dash that could be read as zero.

Every USD value on the site inherits that: it is exactly the arithmetic of a price and a balance, and where either is unknown the value is reported unknown rather than computed anyway. Market capitalisation is total supply times price — Arcscan holds no circulating-supply figure for this chain and will not estimate one.

Arcscan follows the tip. Arc produces a block roughly every half second — measured on Aug 10, 2026, /v1/chain reported 506 ms on mainnet and 536 ms on testnet — and finality is instant, so a block that exists can never be reorganised away. Indexing runs a small number of blocks behind the head and catches up continuously.

No live figure is printed on this page, because any number written here is wrong within seconds. The current head, the average block time and each stream's lag are on Network status, which reads them from the same document this answer quotes.

No, and neither is ever requested for reading. Arcscan has no accounts at all — the “Sign In” control in the header is deliberately rendered disabled, because there is nothing to sign in to and a control that looks live and is not would be a lie. There are no keys, no tiers and nothing to register.

The only place a wallet is involved is the optional contract interaction panel, which does nothing until you press “Connect to Web3”: it talks to the extension you already have, and Arcscan neither holds nor is shown a private key. Nothing you have to sign is required to read any page on this site.

Yes — https://rpc.arc-scan.io, for Arc mainnet only. It routes over HTTPS POST to several independent providers with failover, and it answers the ordinary read methods. One call confirms which chain you reached:

$ 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"
}

Several things are refused on purpose, and each refusal says so and why rather than failing vaguely: every signing method (“This endpoint holds no keys and will not forward a signing request”), the whole trace_ and debug_ namespaces, and eth_subscribe — there is no WebSocket transport here, so there is nothing to serve a subscription over. The full method list and the failover behaviour are in Public RPC.

Nothing, and no. The endpoint is public by intent: no authentication, no API keys, no per-caller quotas and no tier model. You do not have to tell us who you are to use it.

The only limits are flood limits applied per caller at the edge, so a client that hammers the endpoint is slowed down rather than billed or banned. What it will not do is invent an answer: when every provider that can serve a method is unavailable, the call returns an error saying so. See Public RPC.