Crypto Addresses: Formats, Chains and Why One Is Not Another

A crypto address format is a promise about which ledger the string belongs to, and the promise is invisible when you look at it. Two addresses can look equally plausible and belong to networks that cannot talk to each other at all.

Learning to read a crypto address format is mostly learning what it cannot tell you. The characters encode an alphabet, a length and often a checksum; they do not encode a guarantee that the destination chain is the one you selected, and they never encode the memo that some chains require before an exchange will credit you.

• Format narrows the possibilities; it does not identify the chain. A valid-looking address can still be for the wrong network.
• An address is chain-specific even when the shape is generic, because the same 40 hex characters exist on many chains at once.
• Checksums catch typos, not intent. A checksummed address for the wrong chain is still the wrong chain.
• A test transfer is the cheapest control in self-custody: small cost, immediate and unambiguous answer.

The three crypto address format families you will meet

Almost every address you handle belongs to one of three encoding families. Recognising the family tells you what kind of chain you are dealing with, and roughly which mistakes are possible.

Base58: compact, mixed case, no lookalikes

Base58 is a decimal-and-alphabet encoding that deliberately omits the characters most easily confused when read aloud or copied by hand: zero, capital O, capital I and lowercase l. The result is a short string of mixed-case letters and digits with no obvious structure.

Solana uses a base58 public key, typically in the 32 to 44 character range. Bitcoin’s older address types use base58check, which adds a version prefix and a checksum, so they usually begin with a 1 or a 3. Tron uses base58check as well, which is why Tron addresses start with a T. The shared alphabet is exactly why shape alone settles nothing.

0x hex: the EVM convention

Smart-contract chains in the Ethereum lineage use a 0x prefix followed by 40 hexadecimal characters, encoding a 20-byte account. The convention spread with the tooling: the same shape appears across many compatible networks, and also on some chains that merely borrowed the format.

Because it is borrowed so widely, 0x is the most dangerous prefix to trust. It says “this is a 20-byte account somewhere”, not “this is the chain you have selected”. A 0x address that is correct on one network is a valid, spendable address on another, possibly one where nobody holds the key.

Bech32: readable prefixes and a separator

Bech32 addresses are lowercase and start with a human-readable prefix, then a separator, then data. Bitcoin segwit addresses begin with bc1; Cosmos-family chains use their own prefix, such as cosmos1 or a project-specific variant. The prefix is the chain’s declaration of identity, which is a genuine improvement over a bare hex string.

Bech32 also encodes a checksum designed to catch transcription errors, and the encoding forbids mixed case entirely. An address that mixes upper and lower case in a bech32 string is invalid rather than merely unusual.

An address tells you how it is written. It does not tell you where it lives, and the second question is the one that decides whether the funds arrive.

Why one crypto address format does not mean one chain

Because a format is a convention, not a registry. Anyone can build a chain that uses 0x hex or base58, and several have, often deliberately, to reuse existing wallets and tooling. The consequence is that format narrows the field to a family and never to a single network.

Two failure patterns follow, and they are worth separating. The first is a genuinely incompatible pair: a base58 Solana address entered where a 0x address is expected, which most interfaces will reject on length or character set. The second is the quiet one: a valid 0x address sent on the wrong EVM network, which passes every check and lands somewhere the recipient cannot use.

The second pattern is more common and more expensive precisely because nothing complains. The address is valid, the transaction confirms, and the funds sit on a chain the recipient never mentioned. Nothing about the string was wrong; the routing was.

Checksums and capitalisation: the errors that get caught

A checksum is extra information embedded in the string that lets software detect a corrupted or mistyped address before anything is sent. It catches transpositions and single-character errors, which are the majority of hand-copy mistakes.

Mixed case as a checksum

Ethereum-style addresses use capitalisation as the checksum: the same 40 hex characters, with upper and lower case chosen according to a hash of the address itself. Two versions of the same address differing only in case are not the same address, and a wallet that rejects one is doing its job.

This has a practical consequence. Lowercasing an address to make it “cleaner”, or pasting one that a chat app has auto-capitalised, can turn a valid checksum into an invalid string. If a venue rejects an address that looks correct, check the case before checking your sanity.

Bech32 is lowercase by design

Bech32 does not use case as a checksum, and it does not permit mixed case at all. All-uppercase is defined for some uses, typically QR codes, and all-lowercase is the normal written form. Anything in between is a decoding error.

How to test an address before a large transfer

Send a small amount first, on the exact route you intend to use, and wait for it to be credited before sending the rest. The point is not superstition; it is that every step of the route gets exercised while the amount at risk is trivial.

1. Confirm the chain name on the sending side matches the chain name printed on the receiving side, character for character.
2. Copy the address from the receiving interface in the same session as the send, not from a saved note.
3. Compare the first four and last four characters of what you copied against what is displayed.
4. Send a test amount — enough to be visible, small enough to lose without consequence.
5. Wait for the destination to show the credit, not just for the explorer to show a confirmation.
6. Only then send the balance, and keep the transaction hash of both transfers.

The arithmetic is one-sided. If a test transfer costs a small network fee and protects a 2,000 USD transfer, the premium is a rounding error on the position: even a one-dollar fee on a 2,000 USD move is 0.05% of the amount protected. The alternative, a misplaced deposit, typically costs the whole transfer.