Ethereum vs Solana block explorers

TLDR

Ethereum and Solana sit on opposite sides of the smart-contract design space. Ethereum uses Keccak-256 hex addresses and the EVM account model; Solana uses Ed25519 base58 addresses and a parallel-runtime model. tx.taxi routes Ethereum lookups to Etherscan and Solana lookups to Solscan based on the format of the value you paste.

Address & transaction format

Ethereum addresses are 20 raw bytes presented as a 40-character hex string with a 0x prefix, so 42 characters total. They are case-insensitive in raw form, but most tools display them with EIP-55 mixed-case checksums to catch typos. An Ethereum transaction hash is the Keccak-256 of the signed transaction, 32 bytes shown as a 66-character 0x-prefixed hex string. Block numbers are plain integers, and block hashes use the same 66-character hex format as tx hashes.

Solana addresses are 32-byte Ed25519 public keys encoded in base58. They are typically 32 to 44 characters long, contain no 0x prefix, and use a restricted alphabet that omits 0, O, I, and l to reduce visual ambiguity. Solana transactions are identified by their signature, also base58-encoded, usually 87 or 88 characters. Slot numbers (Solana's analogue to block numbers) are integers, and block hashes are base58 strings.

The encoding choice is not cosmetic. Solana programs derive program-derived addresses (PDAs) by hashing seeds with a program ID, producing valid 32-byte points that map cleanly to base58. Ethereum addresses derive from the low 20 bytes of the Keccak-256 hash of a public key (or from CREATE/CREATE2 factory rules for contracts), which is why hex is the natural representation. Trying to interpret one chain's identifier on the other's explorer will simply fail to parse.

Block explorers tx.taxi uses

For Ethereum, tx.taxi's primary configured explorer is Etherscan. Etherscan is a long-running, widely-used Ethereum explorer covering address activity, transaction receipts, token transfers, contract source verification, and event logs.

For Solana, tx.taxi's primary configured explorer is Solscan. Solscan is a well-known Solana explorer that displays account state, SPL token holdings, transaction instructions across multiple programs, and validator data.

Both explorers cover the same conceptual objects (addresses, transactions, blocks), but they present them in chain-native terms. Etherscan shows gas used, calldata, and ERC-20/721 transfers; Solscan shows compute units, instruction logs, and SPL token transfers.

When to use which

If the value you have starts with 0x and is 42 or 66 characters, it is Ethereum-shaped and the Ethereum chain page on tx.taxi will route you to Etherscan. If it is a base58 string with no 0x prefix, it is Solana-shaped and the Solana chain page on tx.taxi will route you to Solscan.

In practice you do not need to make that decision yourself. Paste the value at tx.taxi/{value} and the detector handles routing. The tradeoff worth understanding is that the same 40-hex-character body can belong to multiple EVM chains (Ethereum, Base, Arbitrum, Polygon), so a bare hex address is ambiguous across EVM networks. A base58 Solana signature is far less likely to collide with anything else, because the format itself is chain-specific.

See EVM vs Solana addresses for a deeper breakdown of the encoding differences, and what is a block explorer for a primer on what these tools actually show.

Common confusions

The first thing users mix up is the account model. Ethereum has explicit accounts: every address has a balance, nonce, and (for contracts) code and storage. Solana has accounts too, but they are typed differently: any account can hold data owned by a program, and programs themselves are accounts marked executable. So "address" means slightly different things on each chain, even though both explorers display a similar landing page when you paste one in.

The second confusion is transaction identifiers. Ethereum's tx hash is content-addressed: hash the signed transaction and you get the ID. Solana's signature is literally one of the transaction signatures, which is why a single Solana transaction can technically be referenced by any of its multiple signatures. Solscan handles this transparently, but if you compute a hash from a Solana transaction body you will not get a valid lookup key.

The third confusion is that Ethereum has one canonical chain identifier per network (chain ID 1 for mainnet, 8453 for Base, and so on), but explorers like Etherscan are network-specific. Solana has separate clusters (mainnet-beta, testnet, devnet) and Solscan shows mainnet by default with a cluster switcher. If a Solana value does not resolve, double-check you are on the right cluster.

For most lookups, that detail is invisible. Paste, get redirected, read the data on the native explorer. tx.taxi exists to skip the chain-picker step entirely.