Checking a Deposit Address Before You Send
A crypto transfer is one of the few actions in personal finance with no undo. Most of the mistakes that go wrong go wrong before the transaction is signed: the address is a different network, the checksum was destroyed by a copy-paste, a second identifier was left blank, or the address was never the intended one. This guide covers what each check can and cannot catch.
Cover artwork: CoinSoso · AI-generated, not a photograph of a real venue, product or market capture.
Key takeaways
- Bitcoin's base58 addresses carry a 4-byte checksum, and bech32 addresses use a code that guarantees detecting any error affecting up to four characters.
- An Ethereum-style address has no checksum in the address itself. The only check is EIP-55 mixed capitalisation, and it disappears the moment the address is lowercased.
- EIP-55 catches an average of about 15 check bits per address, and the specification states a mistyped address passes by accident 0.0247% of the time.
- A checksum proves the address is well formed, not that it is the right address. A valid address belonging to someone else passes every test.
- The network and any memo or destination tag are separate fields from the address, and a correct address on the wrong network usually cannot be recovered.
The last step with no undo
Bank transfers can be recalled. Card payments can be disputed. A signed crypto transaction settles on a network where nobody has the authority to reverse it, and the address is the field that decides where it goes. Everything in this guide is about the minute before signing, because after signing there is no procedure left.
The checks available fall into three groups: what the address format can detect by itself, what the network and asset choice must match, and what only you can decide. The first group is the one people over-trust, because a checksum looks like a guarantee and is not one.
What the address format itself can catch
Address formats differ in how much self-checking they do, and the difference is larger than most people assume.
| Format | Where the check lives | What it detects |
|---|---|---|
| Bitcoin base58 (legacy, P2SH) | 4-byte checksum appended, per BIP-13 | Almost any typo, with a small residual probability of a collision |
| Bitcoin bech32 | BCH code embedded in the string | Any error affecting up to four characters; more than that, a failure rate under 1 in 10^9 |
| Ethereum-style (EVM) | Nothing inside the address | Only EIP-55 capitalisation, if it has been preserved |
The first two are structural. BIP-13 specifies base58 addresses as [one-byte version][20-byte hash][4-byte checksum], so a mistyped character changes the checksum and a wallet refuses to use the address. BIP-173 goes further for bech32, describing a code that “guarantees detection of any error affecting at most 4 characters” and has “less than a 1 in 10^9 chance of failing to detect more errors”.
Ethereum-style addresses work differently, and this is the part worth slowing down for. The address is 20 bytes rendered as 40 hexadecimal characters. There is no checksum field. What exists is EIP-55, a convention from 2016 by Vitalik Buterin and Alex Van de Sande: convert the lowercase hex string to a hash, and capitalise each letter whose corresponding hash nibble is high. The capitalisation is the checksum.
The specification is candid about the strength. An address carries “on average 15 check bits”, and “the net probability that a randomly generated address if mistyped will accidentally pass a check is 0.0247%”. That is a good error detector — it catches about 99.975% of random single-character mistakes — and it is not a cryptographic guarantee.
The lowercase trap
Here is the failure mode that the checksum design cannot protect against, because it removes the checksum rather than defeating it.
If you copy an address from a system that displays it in lowercase, paste it into another field, and compare character by character, you can compare successfully and still have lost the check. Lowercase 0x5aaeb6053f3e94c9b9a09f33669435e7ef1beaed and checksummed 0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed are the same twenty bytes. One can be verified against a typo; the other cannot, because the information that encodes the check is gone.
Some wallets and block explorers will re-checksum what you paste and warn if the mixed case you supplied does not match. That check only works if the mixed case survived long enough to be tested. A system that normalises case before it compares has disabled the safety feature silently.
The practical rule: when you have a choice, copy the checksummed form, and compare the capital letters as part of the comparison. When a recipient insists on all-lowercase, treat the address as unverified and do the rest of the checks by hand.
The network is a different question
An address can be perfectly formed and still be the wrong address, and the most common way is the network.
The address format does not identify the chain. The same string can be valid on several networks, and several chains deliberately reuse Ethereum-format addresses. So an address that looks right is evidence about how it is encoded and no evidence at all about where it lives.
The venue’s deposit page is the authority on which networks it accepts and which address it issues for each. Two habits follow:
Take the address from the deposit page every time. Do not reuse one from an old message, a chat thread, or a previous deposit, because the venue may have rotated it or the network may have been suspended.
Check the network selector immediately before copying, and again before sending. The selector is the field most likely to revert or default to the wrong entry, and it is not carried in the address string.
Sending to the wrong network does not usually produce a clean error. The transaction confirms on the chain you chose, and the receiving venue does not credit it because it is not watching that chain for that asset. Whether the funds can be recovered depends on the receiving venue, on whether you can demonstrate control of the sending side, and on their policy; it is not something to plan around.
The second identifier
Some networks require a memo, destination tag or similar second field alongside the address, so the venue can attribute a deposit to your account among customers who share one deposit address.
It is a separate field from the address. It is frequently omitted, because pasting an address feels like completing the form. A deposit that arrives on-chain without the tag can be credited to the wrong account or held pending manual support, and the transaction itself is valid.
The check is simple and mechanical: read the deposit page’s fields, and treat any field it shows as required rather than optional.
Lookalike addresses
There is a class of mistake that no checksum in any format will catch, because the address is genuinely valid: it belongs to someone else.
One pattern is worth knowing about. An attacker watches public transaction history for an address they want you to use, generates an address that matches the first several and last several characters, and sends a tiny transfer from it. That transaction appears in your history. When you next send to “the address you used last time”, selecting it from history rather than from your own record picks the lookalike.
The defence is to stop comparing by prefix and suffix. Compare more of the string than a human normally would — a reasonable habit is the first six and the last six characters, checked against a source you wrote down rather than one the interface offered you — and prefer a saved contact or an address book entry over a selection from recent history.
A second pattern is deliberate: an invoice or a support message that supplies a different address than the official channel. An address supplied inside an unsolicited message is not a payment detail; it is a request from an unknown party.
A check that costs one transfer
The one procedure that tests the whole route is to send a small amount first, confirm it arrives and is credited — including any memo — and then send the rest.
The test is worth doing whenever the destination is new, the network is one you have not used, or the amount is uncomfortable to lose. It is also the only check that exercises the receiving venue’s crediting logic rather than just the address string.
The only way a test transfer misleads you is if it is too small to be credited, or if you skip it because the first amount seemed small enough not to matter. Both turn a zero-cost check into a false reassurance.
What none of this proves
Two things sit outside every check above, and it is worth naming them so the checks are not asked to do more than they can.
A checksum proves form, not ownership. A perfectly valid address controlled by someone else passes every format test. Nothing in the string tells you who holds the key.
A deposit address is not a permanent identity. Venues rotate them, and a valid address from last year may be retired. The deposit page in front of you is the only current source.
Both are reasons to prefer a saved, verified destination over a copied string, and reasons to treat any request to change a destination — in a message, in an email, in a support chat — as a new verification rather than an update.
The privacy side of the same subject is covered in what a wallet address does and does not reveal, and the trade-off between holding funds on an exchange and holding them yourself is set out in custodial versus non-custodial wallets. If a test transfer goes wrong, the recovery question is almost always about who controls the destination, which is the subject of that second guide.
Risk note. The checksum mechanisms described here are taken from ERC-55, BIP-13 and BIP-173 as read on 2026-10-18; the 0.0247% figure and the four-character detection guarantee are quoted from those documents, not estimated here. Network support, memo requirements and address rotation are set by each venue and change over time, so the deposit page is the operative source. No address check can recover funds sent to the wrong destination, and nothing in this article is investment advice.
Sources
How this was researched. Wallet guides describe how key management works in general. Where an article describes a specific product's behaviour, its sources are listed below.
Primary sources for the factual claims on this page. A date appears only where a human has actually read the source; where it is missing, the check is still outstanding.
Frequently asked questions
Why does my Ethereum address have some capital letters?
That mixed capitalisation is the checksum. EIP-55 encodes 15 or so check bits by capitalising certain letters deterministically from a hash of the address. If your wallet shows an address in all lowercase, the check is no longer present and a mistyped character would not be detected. Where possible, copy addresses from a source that displays them checksummed, and compare the case as well as the characters.
Does a valid address guarantee the funds are recoverable?
No. A checksum only establishes that an address is internally consistent. It says nothing about who controls it. A correctly formed address belonging to someone else, or an address on the wrong network, passes every checksum and still sends the funds where you did not intend. Recovery then depends on the receiving party, and often there is none.
What happens if I send to the wrong network?
Usually the asset arrives at an address the receiving venue does not credit, because it does not monitor that chain, and it may or may not be retrievable if you can prove control of the sending side. The venue's deposit page is the authority on which networks it accepts. Do not infer the network from the address's appearance: two chains can use the same address format, and some chains deliberately reuse Ethereum-format addresses.
What is a memo or destination tag?
Some networks attach a second identifier to a deposit so the receiving venue can attribute it to your account among many customers sharing one deposit address. If the venue's deposit page asks for one, leaving it out can produce a deposit that arrives on-chain but is not credited. It is a separate field from the address and it is easy to omit when pasting.
How much should I send as a test?
Enough that the process is real and small enough that losing it does not matter to you. The point of a test transfer is to confirm the route end to end, including any memo and the time the venue takes to credit. A test that is too small to be credited, or too large to lose comfortably, defeats its own purpose.
Where to go next
Independent research. Each card shows the platform’s invite code, and its Create Account button is a referral link that may earn us a commission at no extra cost to you. Whether an account can be opened is decided by the platform at sign-up.
Binance
One of the largest global exchanges by traded volume, with a very broad product range.
20% Trading Fee Rebate
Use invite code con888 when signing up to enjoy trading fee benefits.
Download from the exchange's official download service. Verify the source and follow the on-screen installation instructions.
Do not install an APK from an unknown source, or one that has been modified or cannot be checked.
OKX
A large global exchange offering spot, derivatives and a self-custody wallet.
20% Trading Fee Rebate
Enter invite code con888 when signing up to check available trading fee benefits.
Download from the exchange's official download service. Verify the source and follow the on-screen installation instructions.
Do not install an APK from an unknown source, or one that has been modified or cannot be checked.