Arbitrum One vs Ethereum block explorers

TLDR

Arbitrum One is an optimistic rollup that scales Ethereum. It uses the EVM, the same address format, and the same wallet flows, but it is a separate chain with its own state and its own block explorer. tx.taxi routes Ethereum lookups to Etherscan and Arbitrum One lookups to Arbiscan.

Address & transaction format

Ethereum and Arbitrum One share the EVM address format. An address is 20 raw bytes shown as 0x followed by 40 hex characters, 42 characters in total. EIP-55 mixed-case checksums display identically. The same private key controls the same address on both chains because key-to-address derivation does not depend on the chain.

Transaction hashes are the Keccak-256 of the signed transaction, 32 bytes shown as a 66-character 0x-prefixed hex string. This is true on both chains. Block hashes share the format. Block numbers are integers, but importantly, the block numbers are not synchronized: Arbitrum One block height and Ethereum block height are independent counters.

Where the chains diverge is the chain ID. Ethereum mainnet is chain ID 1; Arbitrum One is chain ID 42161. Chain ID is part of the signed transaction under EIP-155, which prevents cross-chain replay. So although a key produces the same address on both chains, a transaction signed for Ethereum mainnet cannot be relayed to Arbitrum One.

Arbitrum has historically exposed two kinds of transaction identifiers in its receipts: the standard EVM-style hash, and in some contexts an L1-correlated identifier for messages that cross domains. For day-to-day lookups, the standard 66-character 0x hash is the right one to paste into Arbiscan.

Block explorers tx.taxi uses

For Ethereum, tx.taxi's primary configured explorer is Etherscan. Etherscan is a long-running, widely-used Ethereum explorer with deep coverage of contract verification, internal calls, token transfers, and event logs.

For Arbitrum One, tx.taxi's primary configured explorer is Arbiscan. Arbiscan is built on the same explorer family and provides the equivalent feature set scoped to Arbitrum One. Because the UI conventions match, anyone familiar with Etherscan will recognize the layout immediately.

Both explorers cover the same conceptual objects (addresses, transactions, blocks, contracts). Arbiscan additionally surfaces rollup-specific data such as L1 batch references where relevant.

When to use which

If the value came from an Arbitrum One action (a swap on an Arbitrum-deployed AMM, a bridge claim on Arbitrum, a contract call to an Arbitrum-only address), use the Arbitrum One chain page which routes to Arbiscan. If it came from Ethereum mainnet, use the Ethereum chain page which routes to Etherscan.

For a bare 0x address with no chain context, tx.taxi routes to a multichain EVM address aggregator so you can see where the address has activity, then drill into the chain-specific explorer. The detector cannot infer chain from address shape alone because the shape is identical across EVM chains.

See how to read a transaction hash and the what is a block explorer guide for more context.

Common confusions

The first confusion is shared address, independent balances. Your address on Ethereum and on Arbitrum One are the same string, but the chains track separate balances. Bridging ETH from L1 to Arbitrum is a real transaction that moves value across a domain boundary; it is not a UI toggle. Arbiscan will not show your Ethereum mainnet history, and Etherscan will not show your Arbitrum activity. To audit a user's full position, you need to query each chain's explorer separately.

The second confusion is gas accounting. Arbitrum charges in ETH like Ethereum, but the fee structure includes an L2 execution component and an L1 calldata component because the rollup must post data back to Ethereum. Arbiscan exposes both components on transaction pages. The transaction "value" still represents ETH transferred, but the fee semantics differ from a pure L1 transaction.

The third confusion is block timestamps versus L1 timestamps. Arbitrum One produces blocks far more frequently than Ethereum, but each L2 block also references an L1 block. When timestamps appear out of order between explorers, it is usually because you are comparing L2 block time on Arbiscan to L1 inclusion time on Etherscan. Both are correct; they just refer to different events. tx.taxi does not try to harmonize this; it just gets you to the right explorer for each chain.