Why Addresses Need Checksums: Copy-Paste Traps and What Actually Protects You
One swapped character can cost millions — or nothing, thanks to built-in checksums. How bech32, Base58Check, and EIP-55 catch typos, why bc1q and bc1p are not interchangeable — and what no checksum in the world protects against.
Crypto addresses are made for retyping like passwords are made for guessing: long strings where capitalization matters, no "did you mean …?". Still, millions move through them daily — with almost no typo losses. The reason is checksums baked into the addresses themselves. And one scam they are powerless against.
To try it: the Address Validator checks Bitcoin and EVM addresses for format and checksum — with reasoning, entirely in your browser.
Three systems, one principle
Every address family solves the same problem differently:
| System | Example | Checksum | Catches |
|---|---|---|---|
| Legacy (Base58Check) | 1A1zP1… |
4-byte double-SHA-256 at the end | Typos with overwhelming probability |
| bech32 / bech32m (BIP173/350) | bc1q… / bc1p… |
BCH code in the suffix | up to 4 errors guaranteed, almost everything beyond |
| EIP-55 (Ethereum) | 0x5aAeb6… |
No extra byte — capitalization is the checksum | Typos with very high probability (~15 checksum bits on average) |
EIP-55 is the most elegant hack: instead of spending space on checksum bytes, the Keccak hash of the lowercase address is mapped bit by bit onto the letters — hash bit 1 means uppercase. The result looks randomly capitalized but is deterministic. A fully lowercase address is therefore formally valid yet carries no checksum: typos go unnoticed. Rule of thumb: lowercase means unprotected.
The bc1q/bc1p trap
The most expensive beginner mistake after "wrong chain": bc1q… addresses (native SegWit, version 0, bech32) and bc1p… addresses (Taproot, version 1, bech32m) look related but are different systems with different checksum constants. Sending manually to the wrong version risks total loss — which is why good wallets refuse such addresses. The Address Validator will tell you why in such a case.
What no checksum protects against
Now the important distinction: a checksum only proves an address is formally correct — not that it belongs to your recipient. Two attacks exploit exactly this gap:
Clipboard hijacking: Malware on your machine swaps the recipient address at paste time for the attacker's. The new address is perfectly valid — every check nods it through. Defense: after pasting, compare first and last characters with the source — and for larger amounts, a test transaction first.
Address poisoning: The attacker sends you dust from addresses deceptively similar to a real one of yours (e.g. an exchange) in prefix and suffix. Later you copy the wrong one from history. Again: formally all valid. Defense: address book instead of history, check the full address rather than just start and end.
Both are variants of mistake #3 from How a Wallet Actually Works — except the "support scam" here is fully automated and without a single typo.
Why this counts double for AI agents
An agent adopting addresses from emails, chats, or web pages is clipboard hijacking in its purest form — except nobody looks anymore who could compare start and end. Anyone equipping agents with wallets (see What Actually Happens When AI Agents Start Paying for Themselves) therefore needs allowlisted addresses and spending caps, not just valid checksums. The check the Address Validator performs is the bottom layer — necessary, but never sufficient.
Try it
Paste an address into the Address Validator — it tells you format, version, and checksum status with reasoning. Sample addresses are provided to play with, including the famous EIP-55 test address 0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed straight from the specification.
Sources:
Specifications
- Bitcoin BIPs: BIP173 — Base32 address format (bech32)
- Bitcoin BIPs: BIP350 — Bech32m format (bech32m for Taproot)
- EIP-55: Mixed-case checksum address encoding
