Tokens

Arcscan indexes every token contract that has emitted a transfer, ranks them by activity, and builds a full holder list from balances it folds up itself.

The token list#

Tokens is the whole registry, one row per contract. It is ordered by transfer count over the indexed history — the API states that basis with every page — and not by market capitalisation, because Arcscan publishes no market capitalisation for this chain. Rank 1 is the busiest token, not the largest.

Column	What it is
#	Rank in the current ordering. It moves as transfers accumulate.
Token	Name and symbol read from the contract, with its address alongside.
Standard	`ERC-20`, `ERC-721`, `ERC-1155`, or unclassified when the contract answers none of the three interfaces.
Transfers	Transfer logs over the indexed history. Links to the filtered feed.
Transfers (24H)	The same count over the last day, where it can be computed.
Holders	Distinct addresses with a non-zero balance. See below.
Total Supply	Total supply, scaled by that contract’s own decimals. Not circulating supply — Arcscan holds no circulating figure and will not estimate one.
Contract	The contract address, copyable.

The standard filter narrows the list to one of those four. Mainnet is overwhelmingly ERC-20: NFT contracts exist but are a rounding error beside them, so a filtered ERC-1155 view is a very short page rather than an empty one.

A token’s page#

/token/<address> is the canonical URL for a token and opens on Holders. Four tabs, in this order:

Tab	URL	Holds
Transfers	`/token/<address>/transfers`	Every transfer of this token, newest first.
Holders	`/token/<address>`	The ranked balance list, plus concentration.
Info	`/token/<address>/info`	Links, description and logo — only where the token’s owner has submitted them. Almost nothing has been submitted yet (not even by the three busiest tokens on mainnet), and the tab says nothing was submitted rather than showing empty fields.
Contract	`/address/<address>/contract`	The contract itself, on the address surface.

Old links still resolve

Holders used to live at /token/<address>/holders and Transfers at /token/<address>. Both old paths still resolve and land on the same content they always did, carrying your page position with them, so a bookmark or an EIP-3091 link written before 2026-08-03 is not broken.

Holders#

A holder list is a full-history aggregation: every transfer the token ever emitted, folded into balances. Arcscan builds one itself, in its balances stream, and where that stream covers the history the table is a real ranked list rather than a sample. Each row carries the rank, the address, the balance at that token’s decimals, the share of supply it represents, and the block the balance was last changed at.

Coverage is not the same on the two chains, and it decides which questions the tab can answer:

Chain	Balances indexed from	What that means for a holder list
Arc mainnet (5042)	Block `0`, contiguous to the head	The list is the whole history. No balance is missing because a range was skipped.
Arc testnet (5042002)	Block `53,500,000`, contiguous to the head	Balances moved only in blocks below that point are not in the index at all, so a holder whose last activity predates it is not on the list.

An empty holders table is never a silent one

Three different things can leave the table with no rows, and Arcscan distinguishes them instead of printing one sentence for all three: every balance it read is genuinely zero; the index holds no transfer of this token at all; or Arcscan could not enumerate it, in which case the page says so and names the reason rather than rendering an empty list. “No holders” is a measurement here, not a default.

Concentration#

Below the list, the same balances are summarised: the share of supply held by the top 5, top 10 and top 100 addresses, how many addresses hold over 1%, a Gini coefficient over every enumerated holder, and the supply split into rank bands (1–5, 6–10, 11–25, 26–50, 51–100, everything outside 100). All of it is a share of total supply. Enumeration has an upper bound, and where a token has more holders than Arcscan will scan in one pass the payload says it was truncated instead of quietly ranking a subset.

The gas token has no holder list#

Ask for the holders of 0x3600…0000 and the API refuses, in these words:

CAPABILITY_UNAVAILABLE

“The native gas token has no separate holder list: its balances are account balances, and indexing them again would double-count every account.”

This is not a gap. Holding the ERC-20 face of USDC and holding Arc’s native balance are the same thing — see below — so a “token holder” list for it would be a second copy of the account list. Use the address surface for a native balance, and Total Supply on the token page for the aggregate.

Transfers#

A transfer row is a Transfer log. That has one consequence worth stating outright: a row in a transfer feed proves its transaction succeeded. The EVM discards the logs of a reverted transaction along with its state changes, so there is no failed transfer to show and no status column that could mark one.

Token transfers is the chain-wide feed, newest first in log order; the Transfers tab on a token page is the same feed narrowed to one contract. The transfer count in the token list is a link — it opens the chain-wide feed already filtered to that token.

Every native movement exists twice, and the feed says so

Gas on Arc is USDC, and the chain publishes each native movement twice: once from the execution-layer mirror emitter at 18 decimals, once from the ERC-20 face at 0x3600…0000 at 6 decimals. The feed keeps one of the pair so every dollar appears exactly once, and marks the surviving row — that marker is how the page tells you the other log exists rather than implying the chain emitted one. A bare native value transfer emits no token log at all and so is not in this feed; look for it on the transaction.

One token’s transfer history is paginated to a hard ceiling of 100,000 rows, and the response flags itself as capped when it hits it. For USDC that ceiling is far below the real count, so the total on that tab is a page budget rather than a measurement of the token. To walk further back, or to slice by counterparty and block range, use the advanced filter.

Decimals: two faces of USDC#

This is the easiest thing on Arc to get wrong, and the most expensive. USDC is both the chain’s gas token and an ERC-20 contract at 0x3600…0000, and the two faces report different decimals:

Face	Decimals	Where you meet it
Native balance	`18`	`eth_getBalance`, a transaction’s `value`, gas costs, the account balance on an address page.
ERC-20 at `0x3600…0000`	`6`	`balanceOf`, `Transfer` logs, token amounts, total supply.

They are not two balances. The 6-decimal figure is a lossy projection of the 18-decimal one — the same money, truncated by twelve digits:

erc20_balanceOf(a) == eth_getBalance(a) / 10**12   # integer division, truncating

# Verified on mainnet, 2026-08-10:
#   eth_getBalance(0xba75546acd56b3a9142f94f179b03970ee4283fd) = 10670017543856915492
#   balanceOf   (0xba75546acd56b3a9142f94f179b03970ee4283fd) =           10670017
#   10670017543856915492 // 10**12                           =           10670017
#
# Read as money: 10.670017543856915492 USDC natively,
#                10.670017            USDC through the ERC-20 face.

Adding Arc to a wallet: use 18, not 6

A wallet configured with 6 decimals for the native currency displays every balance a trillion times too large, and the reader blames the wallet. Arc’s native currency is USDC with 18 decimals; the 6 belongs to the token contract only. Public RPC has the exact chain parameters.

Every other token carries its own decimals, read from its own contract. Arcscan never assumes 18: a token whose decimals() call reverts arrives with no amount at all and renders as not decodable, never as a number produced by guessing.

USD values#

Where Arcscan shows a USD figure beside a token amount it is a derived value, computed from on-chain pool reserves, and it is published only when the deepest pool holding that token clears a stated depth floor. It can be stale, and for the great majority of tokens it does not exist at all — the payload carries no price and names the reason, which is usually that no pool is deep enough to quote from.

Never authoritative, and never zero

A USD value here is Arcscan’s arithmetic over what the chain shows, not a quote and not a market price. An unpriced holding contributes nothing to any subtotal — it is never counted as zero — and a subtotal is labelled with how many holdings it could not include. Do not settle anything against these numbers.

What Arcscan does not have#

Stated plainly, because guessing at an absent feature wastes more time than reading about one:

Not available	Why
A market-capitalisation ranking	There is no price for most tokens to compute one from, and Arcscan holds no circulating-supply figure. The list is ranked by transfers instead.
Price charts, quotes or a price API	The only money figures Arcscan derives are the pool-derived values described above.
Risk scores, token ratings or holder scoring	Arcscan publishes measurements, not judgements. Concentration is a share of supply, not a verdict.
Verified source for a mainnet token contract	Sourcify does not list chain 5042, so no contract on this chain can be verified today — through Arcscan or any other client of Sourcify. Testnet contracts can be verified; mainnet ones cannot, and that is waiting on the chain being added upstream.
Internal-call attribution for token movements	Traces are not indexed on mainnet — zero blocks, no ranges. See Data coverage for exactly what each stream covers.