A wallet address is the string of characters that tells a blockchain where to send coins or tokens, much as an account number tells a bank where to credit a payment. Unlike an account number, it comes with no name, no bank and no way to reverse a mistake. Most addresses are derived from a public key, which is in turn calculated from a private key, so whoever holds that key controls what the address receives. Every network writes addresses its own way, and the format is the first clue to which network an address belongs to. The crypto hub covers how wallets and networks fit together.
How is a wallet address made?
A wallet hashes or encodes a public key, adds a network marker and usually a checksum, and writes the result in a character set chosen to resist misreading.
On Bitcoin, the oldest format takes the RIPEMD-160 hash of the SHA-256 hash of a public key, puts a version byte of zero in front, adds a 4-byte checksum and writes the result in Base58Check; the zero byte is why these addresses begin with 1. Pay-to-script-hash addresses hash a script instead and use version byte 5, which BIP-13 chose so that they always begin with 3. SegWit formats switched to bech32: a human-readable part, bc on mainnet and tb on testnet, the separator 1, then the data and a 6-character checksum. Base58 leaves out four lookalike characters, zero, capital o, capital i and lowercase L, as the XRP Ledger's documentation spells out, while bech32 drops 1, b, i and o from its data characters and uses a single case.
| Network and type | Starts with | Length | Built from | Checksum |
|---|---|---|---|---|
| Bitcoin legacy (P2PKH) | 1 | Usually 34 characters | Hash of one public key | 4 bytes, Base58Check |
| Bitcoin script (P2SH) | 3 | 34 characters | Hash of a script, such as a multisig | 4 bytes, Base58Check |
| Bitcoin native SegWit (P2WPKH, P2WSH) | bc1q | 42 or 62 characters | Hash of a key or of a script | 6 characters, bech32 |
| Bitcoin Taproot (P2TR) | bc1p | 62 characters | A 32-byte key | 6 characters, bech32m |
| Ethereum and other EVM chains | 0x | 42 characters | Last 20 bytes of the Keccak-256 hash of the public key | Optional, in the letters' case (EIP-55) |
| Solana | No fixed prefix | Usually 43 or 44 characters | The 32-byte Ed25519 public key itself, or a program-derived address | None |
| XRP Ledger | r | 25 to 35 characters | Hash of the account's public key | 4 bytes |
| Tron | T | 34 characters | The same 20 bytes as the key's Ethereum address, after a 0x41 prefix byte | 4 bytes, Base58Check |
BIP-350 moved Taproot to bech32m after a weakness came to light in the original checksum: when an address ended in p, extra q characters could be inserted or deleted just before it without breaking the check. The prefix does not always reveal the network. A 0x address looks identical on Ethereum, Base, Arbitrum or BNB Chain, and on Tron the developer documentation notes that the 20 bytes after the prefix match the Ethereum address of the same key.
How do you read an address character by character?
Split it into its parts: a network marker at the front, a body that encodes the key or script, and on most formats a checksum at the end.
Worked example: Reading three addresses piece by piece
Bitcoin, from BIP-173's examples: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4
- bc marks mainnet, 1 is the separator and q is witness version 0, which is why SegWit addresses start bc1q
- The next 32 characters carry the 20-byte hash of a public key at 5 bits per character: 32 × 5 = 160 bits
- The last 6 characters, v8f3t4, are the checksum, for 2 + 1 + 1 + 32 + 6 = 42 characters in all
Ethereum, from EIP-55's test cases: 0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed
- After 0x come 40 hexadecimal characters, 22 digits and 18 letters
- Each letter's case is set by the Keccak-256 hash of the lowercase address, so this address carries 18 check bits; 9 of its letters are capitals
- Written entirely in lowercase, it is the same address with no check at all
Solana's System Program: 11111111111111111111111111111111
- The address is 32 bytes of zeros, and Base58 writes each leading zero byte as 1, so it reads as 32 ones
- An ordinary wallet address is 32 random bytes and comes out at 44 characters about 94% of the time, 43 the rest
- 44 Base58 characters hold about 257.8 bits, barely more than the 256 the key fills, which leaves no room for a checksum
EIP-55 puts the odds of a randomly mistyped address passing its check at 0.0247%, about 1 in 4,000, and BIP-173 guarantees bech32 catches any error affecting up to four characters. XRP Ledger addresses carry a 4-byte checksum, so a random string forms a valid address only about once in 2³² tries. Solana relies on the wallet showing the right string in the first place.
Where do you see wallet addresses?
They appear on a wallet's receive screen, an exchange's deposit and withdrawal pages, block explorers and payment requests, often as a QR code.
- Receive screens. Wallets built on a seed phrase can generate a new address for every payment, which bitcoin.org recommends for privacy, since anyone can see the balance and all transactions of any address. BIP-173 recommends uppercase for bech32 addresses inside QR codes, since the format accepts either case as long as the two are not mixed.
- Exchange deposit pages. The platform shows an address it controls together with the network it expects and, on networks such as the XRP Ledger, a destination tag. How to sell crypto and withdraw covers the outgoing side.
- Solana token transfers. Tokens are sent to the recipient's wallet address but held in a separate token account, whose address the Associated Token Program derives from the wallet address, the token program and the token's mint. If the recipient has never held that token, the sender usually funds a refundable storage balance of 0.00148844 SOL (1,488,440 lamports) to open the account. Solana's documentation notes that closing it later returns the balance to a destination the owner chooses, not automatically to whoever paid; the Solana price page converts the amount into dollars.
- Block explorers. Pasting an address into an explorer shows its full public history, which is also the way to confirm that a payment arrived.
Why do valid addresses still lose money?
Checksums catch typing slips only, so the costly mistakes involve addresses that pass every check: ones on the wrong network, planted by scammers or swapped in by malware.
The wrong network. Because many chains share a format, a wallet can let you send USDC on one network to an address whose owner only watches another. Coins sent to your own key-controlled address on a different EVM chain are usually reachable, but a contract-based wallet exists only where it was deployed, since ethereum.org explains that a contract's address comes from its creator's address and transaction count or from a chosen salt and its code. Sent crypto to the wrong network works through each case, and smart contract explains what lives at a contract address.
Poisoned history. In address poisoning, an attacker generates an address whose opening and closing characters resemble one you pay often, then sends a dust-sized or zero-value transfer from it so it shows up in your history, waiting to be copied. Crypto scams shows how cheaply such lookalikes are made.
Swapped or supplied addresses. Clipboard-hijacking malware replaces a copied address with its own between copy and paste, and fake support agents or websites hand out addresses they control.
Keyless addresses. Some valid addresses belong to no one. The XRP Ledger's documentation lists blackhole addresses such as ACCOUNT_ZERO, the encoding of the number 0, whose XRP is lost forever because no known secret key produces them. Solana's program-derived addresses also have no private key, but a program controls them, so funds there are governed by its code.
How is a wallet address different from similar-looking strings?
An address is where funds go; keys, token contracts, token accounts and transaction IDs either authorize, define or record a payment instead.
| Term | What it is | How it differs from a wallet address |
|---|---|---|
| Public key | The key an address is derived from | On Bitcoin and Ethereum the address is a hash of it; on Solana the public key is the address |
| Exchange deposit address | An address the platform controls, assigned to you or shared with a tag | You can send to it but cannot sign from it; the exchange credits you on its books |
| Token contract address | The contract that defines a token, such as a stablecoin | Identifies the token rather than a holder, and tokens sent to it are usually stuck |
| Solana token account | An account holding one token for one wallet | Derived from the wallet address and mint; senders still enter the wallet address |
| Transaction ID | The hash that identifies one transfer | Records a payment; a Bitcoin TXID is a 64-character hexadecimal hash and cannot receive funds |
What should you check before sending to an address?
Check where the address came from, which network it is for, whether a memo or tag is needed and whether every character matches, then test with a small amount.
- Take the address from the recipient's own receive or deposit screen, or from an address book entry saved after a payment that arrived, never from transaction history, an email or a chat.
- Match the format to the network: 1, 3 or bc1 for bitcoin, T for tokens on Tron, 0x plus the exact chain name on EVM networks, and r plus any required destination tag on the XRP Ledger.
- Paste rather than type, treat a checksum warning as a hard stop, and prefer the mixed-case form of an Ethereum address.
- Compare the whole string in blocks of four or five characters, middle included, and on a hardware wallet read it on the device's own screen.
- For tokens on Solana, enter the recipient's wallet address, not the token's mint, and expect the token-account deposit the first time they hold it.
- Send a small test, confirm on a block explorer that it arrived, then send the rest.