Arbitrum One vs Base block explorers

TLDR

Arbitrum One and Base are both Ethereum L2 rollups using the EVM. They share Ethereum's address format and the same wallet UX, but they run on different rollup tech stacks and are separate chains with independent state. tx.taxi routes Arbitrum One lookups to Arbiscan and Base lookups to BaseScan.

Address & transaction format

Both chains use the EVM, so their address format is identical to Ethereum's: 20 raw bytes shown as 0x followed by 40 hex characters. EIP-55 mixed-case checksums display the same way on both. The same private key derives the same address on both chains, because address derivation is chain-agnostic.

Transaction hashes are Keccak-256 of the signed transaction, 32 bytes shown as a 66-character 0x-prefixed hex string. Block hashes follow the same format. Block numbers are plain integers, but the two chains maintain independent block counters: Arbitrum block 100,000,000 and Base block 100,000,000 are unrelated.

Each chain has a distinct chain ID. Arbitrum One is chain ID 42161 and Base is chain ID 8453. The chain ID is part of the signed transaction under EIP-155, so a transaction signed for Arbitrum cannot be replayed on Base. If you only have a bare hex address or a 66-character tx hash, the shape alone does not tell you which chain it belongs to; you need additional context.

Block explorers tx.taxi uses

For Arbitrum One, tx.taxi's primary configured explorer is Arbiscan. Arbiscan is built on a widely-used explorer family and provides the standard EVM views (address activity, transactions, contracts, tokens) along with rollup-specific data like L1 batch references.

For Base, tx.taxi's primary configured explorer is BaseScan. BaseScan is built on the same explorer family and offers an equivalent feature set scoped to Base, including L1 batch metadata where relevant.

Because both explorers share UI conventions, switching between Arbiscan and BaseScan feels familiar. The differences you will notice are chain-specific: gas costs, fee components, batch posting cadence, and any chain-native contracts.

When to use which

If your value came from an Arbitrum-deployed app or appears in an Arbitrum-aware wallet view, use the Arbitrum One chain page to route to Arbiscan. If it came from a Base-deployed app or a Base wallet view, use the Base chain page to route to BaseScan.

For an ambiguous bare hex address, tx.taxi routes to a multichain EVM aggregator that shows activity across many chains at once. From there you can drill into whichever chain has the data you want. For tx hashes, you typically know the chain from the source of the hash (your wallet, a swap UI, a bridge UI).

See EVM vs Solana addresses for the broader address-format primer and what is a block explorer for explorer fundamentals.

Common confusions

The first confusion is that same address means same wallet but different chain means different state. Users routinely assume their L2 balances are unified because the address is identical. They are not. Your ETH on Arbitrum and your ETH on Base are separate balances on separate chains. Bridging between them either goes via L1 or via an L2-native bridge, and either way it is a real transaction.

The second confusion is rollup type. Arbitrum One is an optimistic rollup using fraud proofs; Base is built on the OP Stack, also optimistic-rollup-based. They are similar in trust model but the implementations differ. From the explorer perspective, both look like EVM chains with periodic batch posting back to Ethereum. The differences become visible only when you inspect the rollup-specific metadata (batch numbers, withdrawal proofs, sequencer state) which each explorer surfaces in its own way.

The third confusion is block timing and finality. Both chains produce blocks far more frequently than Ethereum L1 (Arbitrum and Base both target sub-block-time confirmations under normal load), but their soft confirmations are not the same as L1-anchored finality. If you are reconciling cross-domain activity, you need to compare against L1 batch posting times, not L2 block times. Both Arbiscan and BaseScan expose this; tx.taxi just makes sure you land on the right one.

A fourth, subtler confusion is contract addresses for the same protocol. A protocol deployed on both Arbitrum and Base usually has different contract addresses on each chain, because each deployment is its own CREATE2 (or CREATE) transaction on a different chain. So even when you are looking at "the same" application, the contract address on Arbiscan will not match the contract address on BaseScan. Pasting the wrong one into the wrong explorer returns an empty address page rather than an error, which can be misleading. The fix is to confirm chain context before pasting. For raw lookups, paste a value at tx.taxi/{value} from the relevant chain page and you will be on the native explorer in one redirect.