EVM vs Solana addresses: format, derivation, and lookup

Two address formats, two cryptographic stacks

The two largest smart-contract ecosystems use different address formats because they use different cryptographic primitives and different account models. Knowing which is which helps you spot bad paste, route lookups correctly, and avoid sending funds to the wrong network.

The short version:

• EVM (Ethereum, Base, Arbitrum, Optimism, Polygon, BSC, and dozens more) - 20 bytes derived from a Keccak-256 hash of a secp256k1 public key, displayed in hex with an optional EIP-55 mixed-case checksum.
• Solana - 32 bytes that are the ed25519 public key itself, displayed in base58.

Everything else flows from those choices.

EVM addresses up close

An EVM address is the lower 20 bytes of the Keccak-256 hash of the secp256k1 public key associated with a private key. The derivation pipeline:

private key (256 bits)
  -> secp256k1 public key (64 bytes, uncompressed, minus the 0x04 prefix)
  -> Keccak-256 hash (32 bytes)
  -> take the last 20 bytes
  -> prefix "0x" and hex-encode

The result is a 42-character string: 0x plus 40 hexadecimal characters. EVM addresses are case-insensitive at the protocol level - the chain treats 0xdeadbeef... and 0xDEADBEEF... identically - but EIP-55 defines a mixed-case checksum that wallets and explorers use to catch typos. The checksum lives in the casing of each character: the spec specifies which letters should be uppercase based on the address's own hash. If you paste an address with the wrong casing, EIP-55-aware tools flag it.

A few practical consequences:

• One private key produces the same address on every EVM chain. Your Ethereum address is also your Base address, your Arbitrum address, your Optimism address, your Polygon address - assuming you control the same key.
• Smart contracts are addresses too. A contract address is computed deterministically from the deployer's address and nonce (or CREATE2 salt), and lives in the same 20-byte space as externally-owned accounts.
• The zero address 0x0000000000000000000000000000000000000000 is a real, valid address shape, used as a burn target and routing sanity check.

Solana addresses up close

A Solana address is an ed25519 public key, full stop. There is no separate hash step. The derivation:

private key (32 bytes of secret)
  -> ed25519 public key (32 bytes)
  -> base58 encode

The result is a 32-44 character base58 string, most commonly 43 or 44 characters. Base58 uses the alphabet [1-9A-HJ-NP-Za-km-z] - upper and lower case letters and digits, with the visually ambiguous 0, O, I, l removed. Case is significant: different case means different bytes means a different account.

Some structural differences worth knowing:

• No checksum in the base format. Base58Check, used by Bitcoin, adds a checksum. Solana addresses do not. Wallets and explorers detect typos by trying to decode and validating the curve point.
• One key, one address. Solana has no equivalent of the EVM nonce-based contract derivation. Program-derived addresses (PDAs) exist, but they are computed differently and are explicitly off-curve points.
• Programs are also addresses. On Solana, deployed program IDs share the same 32-byte base58 address space as user wallets.

A real Solana address looks like a random string with mixed case, no 0x prefix, no underscores, no dashes. If you see those, it is not Solana.

Why this matters for lookups

When you paste a value at tx.taxi/{value}, the router has to decide which chain to send you to before it can pick an explorer. The format itself does most of the work:

• A 42-character string starting with 0x followed by 40 hex characters can only be an EVM address. It is not a transaction hash (those are 66 characters), not a block hash, not a Solana account.
• A 43-44 character base58 string with no prefix and no special characters is overwhelmingly likely to be a Solana account.

tx.taxi's classifier uses regex patterns close to these:

EVM address: /^0x[a-fA-F0-9]{40}$/
EVM hash:    /^0x[a-fA-F0-9]{64}$/
Solana:      base58 alphabet, length 32-44

There is still a routing decision to make on the EVM side because the same address works on every EVM chain. tx.taxi defaults to a multichain EVM aggregator that surfaces results from all configured EVM explorers at once - so you do not have to know up front whether the address is active on Base, Arbitrum, or Polygon.

Practical implications

A few patterns that come up often:

Mixing the two

You cannot use an EVM address on Solana and vice versa. The chains run different VMs (EVM bytecode vs Solana's BPF-based runtime), different signature schemes (secp256k1 vs ed25519), and entirely different networks. A wallet that says it supports "Ethereum and Solana" actually manages two separate keypairs under the hood, one for each curve.

Mixed-case warning

If you copy an EVM address from one source and the casing matches what EIP-55 expects, you can paste it anywhere safely. If you lowercase it accidentally - which still works at the chain level - any explorer or wallet will re-derive the checksum casing on display. With Solana, do not change the case. Each character carries information.

What to look up where

EVM addresses go to chain-specific Etherscan-family explorers (Etherscan, BaseScan, Arbiscan, Optimistic Etherscan, PolygonScan, BscScan) or to a multichain aggregator. Solana addresses go to Solscan or another Solana-specific explorer. tx.taxi keeps the mapping current so you do not have to remember it.

Don't confuse address with hash

On EVM, an address is 20 bytes (40 hex chars + 0x) and a hash is 32 bytes (64 hex chars + 0x). On Solana, an address and a transaction signature are both base58 but very different lengths - 43-44 characters for an account vs 87-88 for a signature. See block hash vs transaction hash for more on hash formats.

The difference between EVM and Solana addresses is not cosmetic - it is two different cryptographic decisions producing two different lookup keys. Once you can spot which is which on sight, paste-and-go gets a lot faster.