Blocks
Arc commits a block about every half second and each one gets a page — reachable by height or by hash, final the moment it exists.
Two ways to reach a block#
A height and a 32-byte block hash both resolve to the same page, which is what EIP-3091 asks of an explorer. The height is the canonical spelling: it is what every link on Arcscan emits, and a hash URL points its canonical tag back at the height so the two spellings are never treated as two pages.
https://arc-scan.io/en/block/14852000 https://arc-scan.io/en/block/0xb6a8c3b65b23486cb3b99ac35d60b68009f43daa768a43c16b296cf2c7466968
Anything that is neither decimal digits nor 0x plus 64 hex characters is a 404 without a lookup. A well-formed hash that was never committed is also a 404 — but only the chain decides that one, so it costs a request. To pick a block by eye, start from the block listOpens in a new tab.
What a block page shows#
Three groups of labelled rows, then a disclosure holding the compatibility header. The field names below are the ones printed on the page, so you can read the two side by side.
Overview#
| Field | What it means on Arc |
|---|---|
| Block Height | Its position in the chain. Chevrons beside the number step to the previous and next block, and stop at genesis and at the newest block we have seen. |
| Status | Always Finalized. Arc reports "finality": "instant", so there is no confirmation count to wait out and the page never shows one. |
| Timestamp | When the block was committed, to one-second resolution — so two blocks half a second apart often carry the same timestamp. |
| Transactions | How many transactions the block carried, linking to the Transactions tab. A count of internal transactions is added to the same sentence only when it is known. |
| Proposed by | The validator address that proposed the block. It is not a miner and there is no block reward row, so nothing on the page suggests one was paid. |
| Fees Paid | Total transaction fees in the block, in USDC. |
| Size | The serialised size of the block, in bytes. |
| Transaction Actions | One square per transaction, in block order, coloured by what that transaction did. It is derived from our index, so on a deployment that has no index the row is absent rather than empty. |
| Gas Used | Gas consumed by the block's transactions, its share of the limit as a percentage, and a meter. The meter is one colour at every ratio: a nearly-full Arc block is normal, not a fault. |
| Gas Limit | The most gas this block was allowed to consume. |
| Base Fee Per Gas | The price of gas for this block, as a USDC amount with the gwei figure restated beside it. |
| Burnt Fees | The burnt portion of the fees paid — part of the Fees Paid figure above, never larger than it. |
| Extra Data | Not text. On Arc extraData is the eight-byte big-endian base fee, so the raw hex is shown next to the decoded value rather than run through UTF-8, which would produce mojibake. |
The extraData decode is worth seeing once, because it is the field most likely to be misread by tooling built for Ethereum. On the mainnet head block we measured:
extra_data.raw 0x00000004a817c800 0x00000004a817c800 = 20000000000 wei base_fee_gwei 20
More Details#
Behind the More Details toggle are the header fields Arc carries for client compatibility. They are there so a reader can copy a root into a verifier, not because they say anything about Arc.
| Field | Meaning |
|---|---|
| Hash | The hash of this block's header. |
| Parent Hash | The preceding block's hash, linked to that block. |
| StateRoot | Root of the state trie after this block. |
| ReceiptsRoot | Root of the receipts trie for this block. |
| TransactionsRoot | Root of the transactions trie for this block. |
| Nonce | Carried so Ethereum tooling keeps working. It was 0x0000000000000000 on every block we sampled and has no consensus meaning here. |
| Raw header | The rest of the Ethereum-shaped header — difficulty, sha3Uncles, logsBloom, mixHash, withdrawalsRoot, the blob-gas fields. Each value is real and copyable; none of them means anything on Arc. |
One header field is deliberately not shown
parentBeaconBlockRoot is byte-for-byte the parent hash on every Arc block we have sampled. Printing it as its own row would invent a second, differently-named parent pointer that a reader then has to reconcile, so the page drops it and shows the parent hash once.
The three tabs#
Overview is the card above. Transactions lists the block's transactions in position order and carries the count inside its own label — with no count at all when the count is unknown. Participants ranks the addresses that submitted them by the fees they paid.
Half a second, and final on arrival#
Measured from /v1/chain today: 506 ms per block on mainnet and 536 ms on testnet. Both are measurements the API reports rather than protocol constants, so read them there rather than hard-coding either. Finality is instant on both chains: a committed block cannot be reverted, there are no reorgs, and a block page is therefore correct forever once rendered.
An empty block is normal
Arc commits a block on schedule whether or not anyone submitted anything. Heights 1, 14,000,000 and 14,852,000 on mainnet each carried zero transactions with their bodies fully available — that is an idle chain, not a gap in our data, and the page says so plainly instead of looking broken.
Fees and gas are USDC#
Gas on Arc is paid in USDC, so the fee rows on a block page are dollar amounts already — no oracle, no conversion. The native currency carries 18 decimals, while the ERC-20 USDC at 0x3600000000000000000000000000000000000000 carries 6. Both scales appear on the site, so never assume one when reading a raw amount.
block 14,852,345 Fees Paid 0.0009989545 USDC
Burnt Fees 0.00092926 USDC
Base Fee 20 GweiUnknown is not zero#
When the node no longer holds a block's body, its header is still complete — height, timestamp, proposer, gas used, size and every root are real — but the counts that come out of the body are gone. The API says so on the block, and the page prints Not retrievable where the number would be, above a banner titled This block's transactions and fees are unknown, not zero. The Transactions and Participants tabs carry the same banner rather than reporting an empty block.
Why this distinction is a hard rule
The API returns tx_count: 0 for a pruned block because there is no other number to return. Rendering that zero would state, in five languages, that a block carried no transactions when nobody can know what it carried. Testnet block 30,000,000 is the case to look at: gas_used is 1,015,512 — so something certainly happened — while its body is marked pruned.
Arcscan drops the number and the link to the transaction list together: a tab that cannot list them is not somewhere to send a reader. There are regression tests on this behaviour, and it applies everywhere, not only here.
How far back blocks go#
A block page needs the chain for its header and our index for everything derived. The two chains start in different places, and only one of them starts at genesis.
| Chain | Indexed from | What that means |
|---|---|---|
| Arc mainnet (5042) | block 0 | Indexed contiguously from genesis, so every mainnet block has a page. |
| Arc Testnet (5042002) | block 53,500,000 | Nothing below that height is in our index at all. An empty answer down there is our missing history, not the chain's. |
The upper edge moves about twice a second on both chains, so no figure for it is printed here — read it live from /v1/chain or from the explorer. One gap is worth knowing about while reading a block page: the traces index stream currently holds no blocks on either chain, which is why a block's internal-transaction count is usually absent from the Transactions row. Absent, again, not zero.