Addresses
Every 40-hex account on Arc has a page — its USDC balance, the tokens it holds, everything it has done, and, if it is a contract, its code.
What an address page shows#
The header carries the full checksummed address with a copy control and a QR code, plus a pill for each thing the address is: Contract, Proxy, or a token standard. Below it are three cards, then a rail of tabs. Nothing on the page needs an account — Arcscan has none, which is why there are no private name tags anywhere in it. Public labels live in the label cloud and the directory.
| Card | What it holds |
|---|---|
| Overview | USDC Balance, USDC Value and Token Holdings. Every figure on the card is read at one block height, and that height is named in the balance's tooltip. |
| More Info | Token Approvals, the creator and the deployment transaction for a contract, a token tracker link when the address is itself a token contract, this address's first and last transaction, and what first funded it. |
| Multichain Info | One outbound link to DeBank, and a tooltip saying that DeBank does not index Arc — so nothing from Arc appears there. It is a link, not a portfolio total. |
The tab rail also carries a filter menu, which opens the advanced filter pre-filled with this address, and an API button pointing at the endpoints behind the page.
Balances#
The native USDC balance#
Arc pays gas in USDC, so the native balance is already dollars — the balance and its value are the same number, not a conversion at an exchange rate. The native unit carries 18 decimals. The ERC-20 USDC interface at 0x3600000000000000000000000000000000000000 reports the same money truncated to 6 decimals; the address page shows one USDC balance, never both.
A balance without a height cannot be checked
Arc produces a block roughly every half second — 506 ms on mainnet and 536 ms on testnet when measured — so two reads of “latest” land at different heights. Arcscan names the block it read the balance at, and every figure on the Overview card is read at that same height so the numbers agree with each other.Token holdings#
Token Holdings lists a balance for every token this address has sent or received inside the indexed range. Amounts are exact, but each one is derived — summed from the token's transfer log rather than read back from the contract — so a token that moves value without emitting a transfer can differ. The list is a floor, not an inventory: a token that never emitted a transfer this address was a party to cannot be discovered this way.
Dollar values appear only where Arcscan will name a price, which it does only when one of the token's pools holds at least 10,000 USDC of real liquidity — a thinner pool can be moved by a single trade, so the figure it quotes is not a price. A holding with no price says so; it never contributes a zero. The subtotal is therefore the sum of the priced holdings and nothing else, and it says how many holdings it left out.
It is not a portfolio total
Two different things can be unknown here, and neither is nothing: a token whose price Arcscan will not name, and a token whose balance could not be established at all. Both are stated as unknown rather than written as 0.The activity tabs#
A plain account gets four tabs; a contract gets a fifth. Each of the four feeds is paged by a cursor that reaches the whole history Arcscan holds, and each can download the rows it has loaded as CSV.
| Tab | What it lists | Where it comes from |
|---|---|---|
| Transactions | Transactions this address sent or received, newest first. | The address-to-transaction index. |
| Internal Transactions | Native USDC that moved inside a call rather than as the top-level transaction. | Event logs published by the system mirror contract — not trace_filter. |
| Token Transfers | Token movements this address was a party to. | The same address index, over the transfer table. |
| Logs | The events this address emitted. | The log index, filtered on the emitting address. |
| Contract | Bytecode, ABI, creation code, constructor arguments, and source when Arcscan holds it. Contracts only. | The chain, plus Sourcify where verification exists. |
Internal transactions on Arc do not come from traces
Reconstructing internal movements fromtrace_filter would bound this tab to a window of about a hundred blocks — under a minute of chain. It is not needed: every net native movement is published as a log, so this tab reads the whole history without a single trace call. That is also why the traces index stream holds no blocks on either chain while the tab still works.What is indexed, and what is not#
Both chains carry an address-to-transaction index and a holder index, so the lists above are index reads rather than scans. The two chains are not otherwise symmetric, and the differences change what an address page can answer.
| Mainnet — 5042 | Testnet — 5042002 | |
|---|---|---|
| Transaction index | Yes | Yes |
| Holder index | Yes | Yes |
| Index begins at block | 0 — the chain's first block | 53,500,000, not genesis |
| Historical state (archive) | Available | Not available |
| Trace index | No blocks indexed | No blocks indexed |
| Contract verification | Impossible today | Available via Sourcify |
Testnet history below block 53,500,000 is not held
Arcscan's testnet index starts at block 53,500,000. An address whose activity is entirely below that height will show an empty page, and that emptiness is Arcscan's missing history rather than the chain's. Mainnet is indexed from block 0.Arcscan does not publish a transaction count for an address: the API returns no total, and the tab shows no count badge rather than a number from a partial walk. The one true total on the page is the account nonce, shown as what this address has sent — it comes from account state, so it is exact even for transactions Arcscan cannot yet list. How far each index reaches right now is on Data coverage.
Contract source#
A contract address gains the Contract tab, with Code, Read Contract and Write Contract sections. The bytes the chain holds — deployed bytecode, creation code and constructor arguments — are always there, on both chains, because they need nobody's permission. Source code is a different matter, and the two chains differ completely.
Testnet — verified through Sourcify#
Sourcify lists chain 5042002, so a testnet contract can be verified and its source can be shown here. What Arcscan holds is a cache: it fetches a contract's source the first time somebody asks for it. So the number of contracts Arcscan has source for is a cache size and is far smaller than the number that are verified — a contract nobody has opened yet is fetched when somebody does. Submissions go through Verify Contract, and what has landed is listed under Verified Contracts.
Mainnet — no verification exists#
Quoted from what the mainnet service itself reports about its own capabilities:
Not something Arcscan is withholding
Sourcify does not list chain 5042, so no contract on this chain can be verified today — through Arcscan or through any other client of Sourcify. Nothing here is waiting on Arcscan; it is waiting on the chain being added upstream.In practice: on mainnet the Contract tab never shows source and never shows a verification tick, because there is nothing that could earn one. The submission form still loads and says plainly that a submission would be rejected. Read the bytecode as bytecode — do not treat it as matching source you were shown somewhere else.
The same data as JSON#
Everything an address page shows is also readable over the REST API. The overview, the holdings and each feed have their own endpoint — these three answered 200 on mainnet when this page was written:
curl -s https://api.arc-scan.io/v1/address/0xe8FdCA9547985c2Fb8bE4A3E509fe9fE77ecf61e curl -s https://api.arc-scan.io/v1/address/0xe8FdCA9547985c2Fb8bE4A3E509fe9fE77ecf61e/tokens curl -s https://api.arc-scan.io/v1/address/0xe8FdCA9547985c2Fb8bE4A3E509fe9fE77ecf61e/txs