Transactions

A transaction page answers three questions — did it do anything, what did it move, and what did it cost — and on Arc all three have answers that differ from the chains most explorer readers come from.

What a transaction page holds#

Open a transaction from the transactions list, from a block, or by pasting its hash into search. The overview is one continuous run of labelled rows — Transaction Hash, Status, Block, Timestamp, From and Interacted With (To), then any value and token movement, then Value, Transaction Fee and Gas Price. Everything heavier than that sits on its own tab, so opening a transaction never waits on a tracer.

Status#

Status has three values, not two. It is read from the receipt, and a receipt either says the execution completed, says it reverted, or is no longer available to be read.

When the outcome is unknown#

A transaction's outcome exists only in its receipt. The node prunes receipts on a sliding window while keeping block bodies far longer, so past that frontier the transaction still renders and its outcome cannot be recovered from the node. Arcscan's own index covers most of that gap, so Unknown reaches you only where neither source holds the receipt. It is a real answer, not an error and not a loading state, and the page says so in prose rather than printing a zero fee beside a grey pill. More on where coverage begins and ends in Data coverage.

No pending state, no confirmations#

Arc reports its finality as instant: a block is final the moment it is committed and cannot be reorganised away. So there is no confirmation counter anywhere on a transaction page — nothing is counting up towards safety — and Arcscan shows a settled Finalized state beside the block instead. There is likewise no pending or mempool view to send you to, because there is no pending state to show.

Gas and fees are in USDC#

Arc's native asset — the thing gas is paid in — is USDC, at 18 decimals. That single fact removes the conversion that fees on other chains require: the fee and its dollar value are the same number, so nothing on the page is a figure multiplied by a rate.

Two decimal scales, one dollar#

The same dollar has two on-chain faces, and mixing them up by twelve orders of magnitude is the most common confusion on this chain. Native USDC — value, gas, fees — is 18 decimals. The ERC-20 contract for USDC lives at 0x3600000000000000000000000000000000000000 and is 6 decimals. Amounts are always rendered with the decimals the payload declared for that asset, never with an assumed 18, and the unit converter in the ⋮ menu exists for exactly this. Token movement is covered in Tokens.

Logs#

The Logs tab reads the receipt twice over. First as sentences — which logs moved value, from whom, to whom — because that is the question most readers arrived with. Then as the events themselves: the emitting contract, the decoded event name and signature, indexed topics broken out as named parameters, and the data section as named fields, with the raw topics and words always one button away.

Decoding is best-effort and never a guess. An event whose signature is not known renders as numbered topics and numbered data words rather than as an invented name. Both views come from the one receipt, so they have to agree; where they do not, the page prints a warning instead of showing a short summary above a longer list and letting you assume.

Internal transactions#

Internal transactions are the calls a transaction made from inside itself, and there are two different products here that are easy to conflate. One transaction's call tree is produced on demand by a tracer when you open the tab, and that works on mainnet today. A chain-wide, searchable index of internal transactions is a separate thing, built from a traces stream — and that stream currently holds no blocks on either chain.

Where a call tree cannot be produced, the page says that rather than rendering an empty table — because an empty table would read as “this transaction made no internal calls”, which is a false statement about the chain. The arithmetic makes the distinction sound: every transaction that executed has at least one frame, the top-level call itself, so zero frames can only ever mean the trace was not produced. Only one frame is the genuinely empty case. When the tracer cannot answer, Arcscan falls back to what the receipt still proves: net native movement on Arc is also published as logs, so the value that moved inside the transaction is recoverable even when the frames are not.

Fetching a receipt yourself#

rpc.arc-scan.io ↗Opens in a new tab is a public read-only JSON-RPC endpoint for Arc mainnet, chain 5042 (0x13b2). It sits in front of several independent providers with failover and answers the ordinary read methods, so you can check any figure on a transaction page against the chain directly.

curl -s https://rpc.arc-scan.io \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,
       "method":"eth_getTransactionReceipt",
       "params":["0xYOUR_TX_HASH"]}'

The receipt's status is 0x1 for a transaction that completed and 0x0 for one that reverted — the same fact the Status badge renders. There is no testnet endpoint on that hostname. See Public RPC for the method list and limits, and REST API for the shape Arcscan's own endpoints return. Blocks covers the container a transaction arrives in.