Glossary

A – B#

Address

A twenty-byte account identifier, written as 0x followed by forty hexadecimal characters. Arcscan displays and links the mixed-case EIP-55 checksummed form, so a mistyped character is usually visible rather than silent. An address on Arc holds a USDC balance, not an ETH balance — see Native currency.

Archive node

A node that keeps historical state, so a question like “what was this balance two million blocks ago” can still be answered. The two Arc chains differ here and it is the reverse of what you might expect: /v1/chain reports archive: true for mainnet and archive: false for testnet, so a historical-state question that mainnet answers can be refused on testnet.

Base fee

The per-gas price the protocol itself sets for a block, carried in the header as baseFeePerGas exactly as on Ethereum, and shown in gwei on every block Arcscan lists. Arcscan reports a block’s burnt fees separately from its total: the burnt figure is the block’s gas used multiplied by its base fee, and what remains of the total is the priority tip the proposer keeps. Both figures are USDC amounts on this chain.

Block hash

The thirty-two-byte digest of a block’s header, and the block’s stable identity — it commits to the parent hash, the state and receipt roots, the timestamp and the rest of the header. Arc uses ordinary Ethereum block headers, so a hash looks and behaves the way it does elsewhere. Because /v1/chain reports finality as instant on both chains, a height here does not in practice acquire a second competing hash the way it can on a chain with probabilistic finality.

Block height

A block’s position in the chain, counted from the first block as zero. Arc produces blocks roughly twice a second — /v1/chain reports a block time of 506 ms on mainnet and 536 ms on testnet — so heights climb by millions per month. Height is not the same thing as coverage: Arcscan’s testnet index begins at block 53,500,000, and a testnet height below that exists on the chain but is not held here.

C – F#

Contiguous range

A run of consecutive heights with nothing missing inside it. Arcscan describes each of its index streams as a set of ranges plus a last_contiguous_block, which is how it can tell you that it is complete up to one height and has holes above it. A stream reported as one range with contiguous_from_genesis true has no holes at all above its starting block. The point of publishing ranges is that an empty answer can be labelled: it is either “nothing happened” or “not indexed”, and those are different.

Difficulty

A header field inherited from Ethereum’s proof-of-work era. On Arc it is 0x0 — read directly from mainnet headers at heights 1, 100,000, 10,000,000 and the chain head — so it says nothing about how a block was produced and Arcscan does not present it as a statistic. Nothing on Arc is mined, and there is no hashrate to report.

ERC-20 native USDC

Arc exposes its native USDC through a contract at 0x3600000000000000000000000000000000000000, so ordinary ERC-20 tooling can move the gas asset. The two forms have different decimals: the native balance has 18 and this ERC-20 interface has 6, both per /v1/chain, which means the same amount of money has two spellings and Arcscan always labels which one it is showing. It has no holder list of its own — asking for one returns a refusal saying that its balances are account balances and indexing them again would double-count every account.

Finality

The point at which a block stops being provisional and cannot be replaced. /v1/chain reports instant for both Arc chains, so a transaction Arcscan shows inside a block is settled: there is no confirmation count to wait out, no safe versus finalized distinction to display, and no reorg risk for the reader to price in.

G – I#

Gas

The unit of execution work a transaction consumes, and the thing a fee is calculated from: gas used multiplied by the effective gas price. On Arc that fee is denominated in USDC, so there is no ETH anywhere in it. Each header also carries a gas limit for the whole block — 30,000,000 on every mainnet header sampled for this page — alongside the gas actually used.

Holder

An address with a non-zero balance of a given token. Arcscan maintains a holder index on both chains (holder_index: true) and reports each holder’s share of supply alongside the balance and the block it was current at. Balances in a holder list are marked as derived from transfer history rather than read from state, and the native USDC interface is excluded — see ERC-20 native USDC.

Index stream

Arcscan does not index “the chain” as one thing. It runs separate streams and publishes each one’s coverage independently: chain (blocks and transactions), balances, and traces. They sit at different heights, and one of them being empty does not make the others incomplete — which is why a page can be authoritative about a block and still say “not indexed” about its internal transfers.

Internal transaction

A value transfer or call made by a contract during a transaction, rather than by an externally-owned account signing one. Internal transactions are not recorded on-chain as separate entries; they only exist as part of a trace. Arcscan can trace a single transaction on demand and show them, but a chain-wide or per-address list needs the stored traces stream, and on mainnet that stream currently holds no blocks — so those questions are answered with “not indexed” rather than with an empty list that would read as “there were none”.

N – P#

Native currency

The asset gas is paid in. On both Arc chains it is USDC with 18 decimals, per /v1/chain — not ETH, and not a separate gas token that has to be acquired first. Every fee and every native balance Arcscan prints is a USDC amount, and this is the single most common wrong assumption a reader brings to Arc from another chain.

Nonce

For an account, the count of transactions it has already sent: it fixes the order of a sender’s transactions and a value cannot be used twice. The nonce in a block header is an unrelated proof-of-work leftover and is all zeroes on Arc at every height sampled for this page, so it is not a statistic about anything.

Proposer

The address credited with producing a block. Arcscan’s own API calls it proposer while the JSON-RPC header field it comes from is still called miner. Arc blocks are proposed rather than mined, so this is the validator a block is attributed to, not the winner of a computation; Arcscan shows the address and any label it holds for it.

Pruning

Arc’s nodes discard block bodies and receipts behind the head while keeping the headers. A pruned block therefore has a complete, verifiable header — proposer, gas used, roots, size — and no retrievable transaction list or fee total, and Arcscan prints unknown for those rather than zero. The two clocks differ: receipts expire before bodies do, so a block can have a listable transaction set and still have no retrievable fee total.

R – V#

Reverted transaction

A transaction that was included in a block and then failed during execution, so its state changes were undone. It still consumed gas and still paid a fee — a mainnet example read for this page moved no value and paid 0.000869883 USDC — so a reverted transaction is neither successful nor free. Arcscan’s API reports its status as failed, and no Arcscan surface may render it as a success.

Testnet

Chain 5042002, named Arc Testnet, served separately at testnet.arc-scan.io. It is its own chain with its own history and its own capabilities, and on two counts it is the mirror image of mainnet: it can show verified contract source and it cannot answer historical-state questions. Arcscan’s testnet index also starts at block 53,500,000 rather than at the chain’s first block, so the blocks below that are not held here at all.

Trace

The recorded tree of calls a transaction made, frame by frame, with each frame locating itself in the tree by a trace_address path. A trace is how internal transactions become visible. Arcscan traces an individual mainnet transaction on demand and returns real frames; what it does not have on mainnet is a stored trace index, which is why per-address and chain-wide internal-transfer questions are refused instead of answered thinly.

Transaction hash

The thirty-two-byte digest of a signed transaction, and the identifier you paste into search. It exists the moment the transaction is signed — before any node has included it — so a hash can be perfectly valid and still unknown to Arcscan. With immediate finality that window is short, but it is not zero, and Arcscan says “not found” rather than guessing.

Verified source

A contract whose published Solidity has been shown to compile to the bytecode actually deployed. Arcscan gets this from Sourcify, and the two chains are not symmetric. On Arc mainnet it does not exist — verified_source is false for chain 5042 — and the API says why in its own words:

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.

On testnet Sourcify does list the chain, so source can be shown — but what Arcscan holds is a cache filled the first time somebody asks for a given contract, so the number of contracts Arcscan has source for is far smaller than the number that are verified upstream.

Where the numbers live#

Nothing on this page is a count, on purpose. Which heights Arcscan holds, which streams are behind, and which questions each chain refuses are all published live by the explorer itself and summarised on Data coverage. If a term here still leaves a question, FAQ answers the ones people actually ask, and Blocks and Transactions show these words in place on a real page.