From public key to address: formats across networks

An address is a protocol representation, not a universal identifier

A blockchain address is a network-specific way to refer to an account, a destination, or a set of spending conditions. Many addresses ultimately relate to public-key cryptography, but the path from a public key to a displayed address is not universal. Some networks hash a public key, others encode the public key directly, and still others allow destinations derived from program logic or multiple conditions. Consequently, the statement “an address is just a public key” is too broad. Likewise, addresses do not contain a verified personal name, and the same-looking address text can have different meaning on different networks.

An encoding defines how bytes become readable characters. Base58 uses an alphabet selected to avoid certain visually confusing characters. Hexadecimal uses base 16 with digits 0 through 9 and letters a through f. Bech32 uses a different alphabet and includes a checksum mechanism to detect many transcription errors. A prefix can help indicate a network or address family, but a prefix is not an independent check of ownership. Readers should recognize formats while leaving definitive validation to software that understands the particular network and its rules.

Bitcoin: different ways to describe spending conditions

Bitcoin addresses generally represent output destinations: the conditions under which coins placed in a particular output may later be spent. In an older pay-to-public-key-hash (P2PKH) pattern, the destination encodes a hash associated with a public key and is commonly displayed using Base58Check, often beginning with “1” on Bitcoin mainnet. Pay-to-script-hash (P2SH) addresses commonly begin with “3” on mainnet and represent a hash of a redeem script rather than simply a person's public key. A P2SH script may contain conditions that are not visible from the address alone.

Native Segregated Witness (SegWit) version 0 outputs use Bech32 address encoding under Bitcoin Improvement Proposal (BIP) 173 and often begin with “bc1q” on mainnet. Native witness version 1 and later outputs use Bech32m under BIP 350; Taproot addresses commonly begin with “bc1p”. The exact spending rules depend on the witness program and script type. These strings are examples of address families, not exhaustive validation rules. A human should not infer that any arbitrary string beginning “bc1p” is therefore valid. Software must check length, alphabet, checksum, witness version, and other constraints described by the applicable specification.

Why older and newer formats coexist

An address format is part of a protocol and application ecosystem. New encoding techniques can improve error detection or support new spending types while earlier destination types remain present in the historical record and often remain usable. This coexistence does not imply that one displayed format represents a different asset. Nor does it mean a user can safely rewrite a destination into another format by changing its prefix. Conversion is not a text-editing operation; the underlying spending conditions and protocol rules must be preserved. An analyst who sees multiple formats should first determine whether they belong to the same network and what information each conveys.

Ethereum: 20-byte account addresses

Ethereum externally owned account addresses are conventionally formed from the final 20 bytes of a Keccak-256 hash of an appropriately represented public key. They are commonly shown as the “0x” prefix followed by 40 hexadecimal characters. Ethereum also has contract accounts whose addresses identify deployed code and are not derived from a conventional corresponding private key in the same way. Ethereum Improvement Proposal 55 (EIP-55), Mixed-case checksum address encoding, uses letter capitalization in the hexadecimal string as an optional typo-detection mechanism. All-lowercase representations can still be used; mixed-case checksum validation helps catch some errors but cannot establish a recipient's identity.

Numerous networks compatible with the Ethereum Virtual Machine use an address syntax that also begins with “0x”. A matching sequence of 20 bytes across two networks does not mean the two networks share balances or transaction histories. A token on such a network may itself be associated with a smart-contract address, while a user's balance is recorded by contract state. The contract address, the user's account address, a transaction identifier, and an asset's human-readable symbol refer to different things. Confusing them can lead to erroneous reporting even when every copied character is correct.

Solana: addresses based on 32-byte values

A Solana account address is a 32-byte value displayed in Base58. One kind of address is a public key associated with an Ed25519 keypair; another is a program-derived address (PDA), computed from a program identifier and seeds under Solana's address rules. A PDA has no corresponding private key capable of signing in the ordinary way. Instead, an authorized program can act for that address through defined execution rules. This example illustrates why every address cannot be described as a shortened public-key hash. In Solana's account model, the account address identifies state, while the account owner field determines the program allowed to modify that data under network rules.

Recognizing, validating, and attributing

An address can look plausible while belonging to the wrong network. A checksum can detect many accidental typos, but a properly formed address can still identify an unintended recipient or a program with unexpected behavior. Screenshots that hide the middle characters may also conceal substitutions. Before interpreting a payment record, distinguish syntactic validity from network compatibility, and both from human ownership. An explorer label such as “service wallet” is a claim provided by an operator or data source, not something mathematically embedded in most address strings.

1. Identify the exact network and, where relevant, the network environment, such as mainnet or a test network.
2. Determine whether the string is an account address, contract address, output destination, transaction identifier, or another object.
3. Validate the entire value with a network-appropriate parser rather than its prefix alone.
4. For attribution, collect independent evidence; do not equate a checksum match with a verified person or institution.

Address formats are intentionally optimized for machines to interpret exactly, not for people to memorize. For a public-sector report, a sound formulation is “this transaction references destination X on network Y,” not “person Z received the funds” unless other evidence justifies that attribution. The next lesson shows how these address and identifier distinctions appear in the records exposed by block explorers. The following course module will cover practical management of keys, seed phrases, and custody relationships.

Exam focus: Compare Bitcoin Base58Check, Bech32, and Bech32m address families; Ethereum hexadecimal addresses and EIP-55; and Solana Base58 accounts, including program-derived addresses. Explain why an address is not universally a public key or a verified identity, and why identical text across networks does not imply identical state.