A blockchain address is a public-facing identifier on a chain that receives transfers, derived from a public key by hashing and encoding it into a short readable string. It is not your wallet, it is not your private key, and it is not a username. Get the distinction right and almost every common send mistake suddenly has a cause you can see.
What is a blockchain address actually?
A blockchain address is a unique string of letters and numbers that identifies a destination on a specific chain. When someone sends you crypto, they paste your address into their wallet, sign a transaction, and the network records the transfer to that address. Other people can look up the address on a public block explorer and see every transaction that ever moved through it.
The "send-to identifier" framing is correct, but it is also incomplete. What the blockchain actually records when you have an address is a list of transactions tied to that string. There is no separate "account" file with your name on it. The address is the account, in the same way an email address is your inbox, except that everyone in the world can read every email that arrived. The contents are public by default; only the ability to send future transactions from that address is protected, and that protection lives in the private key your wallet stores.
This is the moment to clear up the most common confusion in beginner crypto. Your wallet is the software (or hardware device) that holds your private keys and signs transactions on your behalf. Your address is the public identifier that wallet generates from those keys. One wallet can manage hundreds of addresses across multiple chains. One seed phrase backs up the keys for all of them. The address is what you share publicly. The wallet is what stays private. For the broader picture of what a wallet does, see Blofin's overview of what a crypto wallet is.
A useful way to picture it: when you write down an address and hand it to someone, you are giving them a receipt slot. Anyone can put crypto into that slot. Only you, with the private key, can take crypto out. The slot itself is just a label on a public ledger that thousands of nodes around the world maintain.
How is a blockchain address generated from a key?
Every blockchain address starts as a public key, gets run through a hash function, and gets encoded into a shorter human-readable string. The wallet does this automatically the moment a new key pair is created. The exact functions used are different on each chain, which is why Bitcoin addresses look nothing like Ethereum addresses, which look nothing like Solana addresses.
Walk through the conceptual pipeline using a Bitcoin "Legacy" address as the example. Your wallet starts with a public key, which is a 33-byte (compressed) number derived from your private key. The wallet runs that public key through SHA-256, then runs the result through RIPEMD-160. That gives you a 20-byte hash. The wallet adds a version byte at the front (to mark it as a Bitcoin mainnet address) and a 4-byte checksum at the end (to detect typos), then encodes the whole thing in Base58 (source: Bitcoin Developer Guide). The result is a string starting with 1 that looks like 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa.
Ethereum does it differently. The wallet takes the 64-byte uncompressed public key, runs it through Keccak-256, takes the last 20 bytes of the result, and prepends 0x to mark it as hex. That gives you a 42-character address like 0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb1 (source: Ethereum Developer Docs). Some Ethereum addresses use mixed-case characters that aren't random; that is a checksum encoded in the capitalization itself, defined by EIP-55, designed to detect single-character typos (source: EIP-55).
Solana takes yet another path. Solana addresses are simply the 32-byte Ed25519 public key encoded directly in Base58, with no separate hashing step. The address you see is, mathematically, the public key itself (source: Solana Docs — Accounts).
The reason this pipeline exists in every chain is consistent across the board. Public keys are too long and too random for humans to verify visually, so every protocol designer found some combination of hashing (to shorten and randomize), encoding (to make characters readable), and checksums (to catch typos). The cryptographic property that matters is one-way: anyone with your public key can verify a signature, but nobody can reverse the hash to recover useful information about the private key (source: Cloudflare Learning Center). For the underlying key-pair mechanics, see Blofin's explainer on public keys vs private keys.
Why do blockchain addresses look so different across chains?
Because each chain made different design choices about which hash function to use, how much to truncate, and which encoding to apply. The differences are visual but the underlying idea is the same: take a public key, transform it into a fingerprint, and make that fingerprint short enough to share. Once you know the design choices, the formats stop looking arbitrary.
Here is a side-by-side that captures the major chains beginners actually deal with:
Chain | Address example | Encoding | Length | Distinctive marker |
|---|---|---|---|---|
Bitcoin Legacy (P2PKH) | 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa | Base58Check | 26-35 chars | Starts with 1 |
Bitcoin SegWit (P2SH) | 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy | Base58Check | 34 chars | Starts with 3 |
Bitcoin SegWit native (Bech32) | bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq | Bech32 | 42 chars | Starts with bc1q |
Bitcoin Taproot (Bech32m) | bc1pmzfrwwndsqmk5yh69yjr5lfgfg4ev8c0tsc06e | Bech32m | 62 chars | Starts with bc1p |
Ethereum (and EVM chains) | 0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb1 | Hex with EIP-55 checksum | 42 chars | Starts with 0x |
Solana | 7EqQdEULxWcraVx3mXKFjc84LhCkMGZCkRuDpvcMwJeK | Base58 | 32-44 chars | No prefix; pure Base58 |
Bitcoin alone has four format families. Each came with a network upgrade. Legacy P2PKH was the original. P2SH arrived with multisig support. Bech32 arrived with SegWit (cheaper transactions). Bech32m arrived with Taproot (better privacy and signature aggregation). The character set and checksum mechanism are different for each (source: BIP-173 defines Bech32; BIP-341 defines Taproot). For a deeper dive on the Bitcoin format families and when to use which, see Blofin's article on Legacy vs SegWit vs Taproot.
EVM-compatible chains (Ethereum, Polygon, BSC, Arbitrum, Optimism, Base, and many others) all share the same address format. This is intentional. They all run the Ethereum Virtual Machine, so they use the same 0x... 42-character format and the same EIP-55 checksum. The shared format makes wallet code portable across these chains. It also creates a trap we will revisit in a few sections, because the same address you see on Ethereum is a valid address on Polygon and BSC too, even though those are different chains with different balances.
Is your address tied to your wallet or your keys?
Your address is tied to your keys, not your wallet app. The wallet is just the interface that uses the keys. If your wallet app vanishes tomorrow and you install a different wallet on a new device, the same seed phrase will derive the exact same private keys, which produce the exact same public keys, which produce the exact same addresses. The address is a function of the key, all the way down.
This is how one seed phrase can back up access to thousands of addresses across multiple chains. Modern wallets use a hierarchical deterministic structure: the seed generates a master key, the master key derives chain-specific keys (one for Bitcoin, one for Ethereum, one for Solana), and each chain key derives a sequence of addresses on demand. When you "create a new receiving address" in your wallet UI, you are not generating new randomness. You are walking one step further down the derivation tree, producing the next address in a sequence that is fully determined by your seed phrase. For more on how the seed phrase encodes this whole tree, see the Bitcoin pillar's article on what a seed phrase is.
Smart contract addresses break this pattern, because they are not derived from a key at all. When a developer deploys a smart contract on Ethereum (or any EVM chain), the network computes the contract's address from the deployer's address, a nonce, and the contract bytecode. That address has no private key behind it. Nobody can sign a transaction from a contract address; the contract itself executes its code in response to transactions sent to it. This is why your wallet UI sometimes flags an address as a "contract" instead of a regular account. The visual format is identical, but the behavior is not (source: Ethereum Developer Docs — Accounts).
The takeaway for security: protect the keys, not the address. Sharing your address publicly is the entire point of having one. Sharing the private key, or the seed phrase that generates it, is what costs you everything. For how the keys themselves are structured and how the wallet uses them to sign, see Blofin's coverage of how crypto wallets work.
What happens when you send to the wrong address or wrong network?
Three different things, depending on which kind of mistake you made. A typo on a valid address means the funds went to a real address that nobody controls; the loss is permanent. A correct address sent on the wrong EVM chain means the funds are sitting on a different chain than you expected, and they are usually recoverable. A correct address sent across incompatible chain families (Bitcoin to Ethereum, Solana to Bitcoin) usually fails outright because the formats do not match, but a few non-obvious cross-format collisions are unrecoverable.
The first case is the most common and the most painful. If you change one character in a 42-character Ethereum address and that new address happens to be valid (which it almost always is, because the address space is enormous and most strings of 40 hex characters pass a basic length check), the transaction signs cleanly, broadcasts, and confirms. The funds are now at the typo'd address. The blockchain has no concept of "intent." It only sees a valid signature for a valid transaction, so it executes. Recovery requires the impossible: the private key for an address that nobody created. The mixed-case checksum in EIP-55 catches some single-character typos at the wallet UI level, but not all of them, and not every wallet enforces the checksum. For a deeper look at what to do after a wrong-address send and what (rarely) recoverable cases exist, see Blofin's guide on sending Bitcoin to the wrong address.
The second case is the one that most often surprises people. Imagine you want to send 100 USDC from MetaMask to a friend's Ethereum address. You select MetaMask's network dropdown, which happens to be on Polygon at the moment, type in your friend's 0x... address, hit send, sign the transaction. Polygon happily processes it because the address shape is valid Polygon. Your USDC is now in your friend's address, but on Polygon, not Ethereum. If your friend's wallet supports Polygon, they can switch networks and they will see the funds appear. If not, they need to add Polygon as a network in their wallet first. The funds are not lost. They are on the wrong chain for the wallet's current configuration. This is the same recovery pattern that applies to Ethereum/BSC, Ethereum/Arbitrum, and any other pair of EVM-compatible chains.
The third case usually fails at the wallet stage. If you try to paste a Bitcoin address into a Solana send dialog, the Solana wallet rejects the address because it does not match Solana's format. Same thing if you paste a Solana address into a Bitcoin wallet. The only painful exception is when an address happens to be coincidentally valid on a chain you did not intend; this is rare for non-EVM cross-sends but does happen in edge cases involving wrapped tokens and bridge routing.
From Blofin's operational perspective, a wrong-network deposit is one of the most common recoveries we see. A user sends from MetaMask on Ethereum to a Blofin BSC deposit address that looks identical because both chains share the EVM address namespace. The funds are not lost on the chain they actually landed on; they are just on the wrong chain for the destination wallet's configuration, and recovering them takes a manual cross-chain operation that is only possible when both chains are EVM-compatible and the destination has the matching key. For the Bitcoin transaction context that frames the same flow on a non-EVM chain, see Blofin's deep dive on how a Bitcoin transaction works.
Should you reuse the same address or use new ones each time?
Use a new address for every receive when you can, but understand the chain-specific tradeoff. On Bitcoin, address reuse links your transaction history publicly and removes the privacy benefit of using fresh addresses, which is why most modern Bitcoin wallets generate a new receive address each time by default. On Ethereum and other account-model chains, reusing the same address is the default behavior because the chain tracks balance per address rather than per individual UTXO, and switching addresses adds nuisance without strong privacy gains.
Bitcoin's UTXO model rewards fresh addresses because anyone can tie multiple receives at the same address to a single owner, and from there to a real-world identity if any of those receives originated from a KYC'd source. A wallet that automatically advances to the next address on every receive makes this kind of analysis harder. The downside is administrative: you and the people sending to you both need to keep track of which address is current, which is why exchange deposit pages tell you to "always check the latest address" before each new deposit.
Ethereum's account model takes a different stance. The address is also your account; reuse is automatic and the chain explicitly tracks the running balance per address. Generating a new Ethereum address every receive is technically possible but rarely useful, because the funds end up scattered across multiple addresses that you then have to consolidate (paying gas each time). Most Ethereum users settle on one or two addresses for receiving and live with the privacy cost. For higher-stakes receives where privacy matters, mixing services or stealth-address protocols exist but sit outside this article's scope.
Practical rule of thumb that holds across most chains: if your wallet automatically generates a fresh receive address every time you click "Receive", let it. If it does not, do not lose sleep. The bigger threats to your funds are typos and wrong-network sends, not address-history correlation. Privacy improvements are nice; not losing money to a malformed transfer is essential.
How do attackers use address tricks against you?
Two specific attacks exploit the fact that humans visually compare addresses by checking the first and last few characters, not the middle. Address poisoning plants a look-alike address into your transaction history, hoping you copy-paste from history rather than from your address book the next time. Clipboard hijacker malware silently swaps the address in your system clipboard, so what you paste is not what you copied. Both attacks rely on the same shortcut: not visually verifying the full address before signing.
Address poisoning works like this. An attacker generates a vanity address that matches the first four characters and last four characters of an address you regularly receive from. They send a tiny amount (often zero-value or dust) from that vanity address into your wallet. From your wallet's perspective, you now have a transaction in your history involving an address that looks almost identical to one you trust. The next time you go to send funds to that trusted address and you copy from your transaction history, you may grab the attacker's address by mistake. You sign, broadcast, and the funds land in the attacker's wallet. Modern wallets have started flagging suspicious dust transactions and warning before sending to addresses with extremely short interaction histories, but the verification habit on your end is what closes the gap.
Clipboard hijacker malware is older and targets the operating system rather than the wallet. The malware monitors the system clipboard for strings that look like crypto addresses (0x..., bc1..., Solana Base58 patterns), and silently replaces them with the attacker's address. You copy the correct address. By the time you paste, the clipboard contains a different one. Hardware wallets defend against this because they show the resolved transaction details on a separate screen that the malware cannot reach, so you see the actual destination address before approving. Without a hardware wallet, the only defense is verifying every character of the pasted address against the source.
The verification habits that catch both attacks are simple but require discipline:
Compare the full address character-by-character, not just the first and last few characters
For new addresses, send a small test transaction first and confirm receipt before sending the real amount
For repeat addresses, use your wallet's address book feature so you do not have to copy-paste every time
For high-value sends, verify the address on a hardware wallet's screen before signing
On Blofin's platform, every withdrawal address goes through a checksum verification step before the cold-storage policy signs. A single character flipped in a 42-character Ethereum address creates a different valid-looking address that nobody controls, and once a transaction is signed and broadcast, that mistake cannot be reversed. The verification step is not optional, even for repeat addresses, because clipboard hijackers and address-poisoning attacks are designed to exploit muscle memory.
Frequently asked questions
Is a wallet address the same as a public key?
Not exactly, though they are closely related. The wallet address is derived from the public key by hashing and encoding it into a shorter, human-readable form. On most chains, you cannot reverse-engineer the public key from just the address. Solana is an exception, where the address is the public key encoded in Base58 directly. For practical purposes, both are public information meant to be shared.
Can two people have the same blockchain address?
The probability is so small that it is treated as impossible. The address space on Bitcoin or Ethereum has roughly 2^160 possible values, which is far more addresses than there are atoms in a large mountain. Two different key pairs producing the same address (called a "collision") would break the underlying hash function's security guarantees. No real collision has ever been observed.
Does an address expire or get reused over time?
Addresses do not expire on the blockchain. An address you used five years ago is still valid today, and someone could send funds to it tomorrow. The blockchain itself has no concept of "active" or "deprecated" addresses. Your wallet may stop displaying old addresses for usability reasons, but the underlying address still works as long as your wallet has the matching key.
Why is my Ethereum address mixed-case?
The mixed-case formatting is a checksum. EIP-55 specifies that certain letters in the address should be uppercase based on a hash of the address. If you mistype a single character, the checksum validation fails and the wallet warns you. All-lowercase Ethereum addresses are still technically valid, but the checksum is bypassed.
Can I send Bitcoin to an Ethereum address?
You cannot from any standard wallet. Bitcoin and Ethereum use different address formats, different cryptography, and different transaction types. Wallet software validates the address format before it builds a transaction, so a paste of an Ethereum address into a Bitcoin wallet gets rejected at the input field. The two ecosystems do not share an address namespace.
How do I know if an address is valid before sending?
Modern wallets validate addresses automatically by checking the format and any embedded checksum. If the wallet's send dialog accepts your input without an error, the address is structurally valid. Structural validity does not mean the address belongs to the person you think it belongs to, though, which is why visual verification and small test transactions matter for any new send.
Are smart contract addresses different from regular addresses?
In format, no. They look identical to regular Ethereum-style addresses. In behavior, yes. Smart contract addresses do not have a private key. They cannot sign transactions. They execute code when transactions are sent to them. Most wallet UIs flag a contract address with a label or icon so you do not accidentally treat it like a personal address.
Researched and written by the Blofin Academy editorial team with AI-assisted drafting. Primary sources include the Bitcoin Developer Guide, BIP-173 and BIP-341, the Ethereum Developer Docs, EIP-55, the Solana developer documentation, and Cloudflare Learning Center. All facts independently verified against cited documentation current as of May 2026.
This article is for informational purposes only and does not constitute financial advice, investment guidance, or a recommendation to buy, sell, or hold any digital asset. Cryptocurrency markets involve significant risk and you should conduct your own research and consult qualified professionals before making investment decisions. Blofin Academy content reflects the state of public information at time of publication; protocol parameters, fees, and ecosystem data change frequently.