How to Send and Receive Crypto Without Losing It

TL;DR

Address, network, and where required, memo: the who, the where and the which-account of a transfer. Each has its own failure mode, and the sender carries all three, because the protocol generally offers no undo for a confirmed transaction.
Because interfaces can make networks look interchangeable, and because the same asset's name hides its many separate versions. You rule it out by reading the network on both ends and refusing to proceed on inference.
Source the address properly, match the network explicitly, attach the memo where required, verify at the paste destination on the best display available, send a small test, confirm receipt out-of-band, then send the remainder over the proven route. Seven steps, one minute, covering the transfer-stage failure modes this cluster documents.
Give the sender the right address for the network they will use, state the network in words, confirm arrivals in your own wallet, and treat unexpected items in your history as warnings. Receiving-side prevention mirrors the sender's drill.

ในบล็อกเดียว

A crypto transfer is a signed instruction that moves an asset on one blockchain; once confirmed, the network generally cannot reverse it. It arrives only when three fields match what the recipient controls: the address identifies the recipient, the network identifies the ledger, and, at custodial destinations that pool customers, a memo or tag identifies the account.

What must be right for a transfer to arrive?

ตอบด่วน

Address, network, and where required, memo: the who, the where and the which-account of a transfer. Each has its own failure mode, and the sender carries all three, because the protocol generally offers no undo for a confirmed transaction.

The address names the recipient on a specific ledger. It must be theirs, current, and for the asset's chain; the address poisoning guide covers the attacks on this field, and the drill below covers the verification. One property of addresses surprises beginners usefully: many formats carry a checksum, so a mangled address usually fails outright rather than paying a stranger. Ethereum's mixed-case checksum (EIP-55) gives a mistyped address roughly a 0.02 percent chance of passing validation, and Bitcoin's bech32 format (BIP-173) is designed to detect any error affecting up to four characters (Ethereum Improvement Proposals, EIP-55, 2016; Bitcoin Improvement Proposals, BIP-173, 2017). Checksums catch typos. They cannot catch a valid address that belongs to the wrong person, which is precisely the case verification exists for.

The network names the ledger the instruction is written to. The guide to how blockchains differ is the background: the same asset name, USDC being a familiar example, exists as separate deployments on separate chains, and many wallets and exchanges support several networks behind one asset label. A withdrawal screen offering a choice of networks is asking which ledger to write to; the destination follows some of them and not others. Sending on a network the destination does not support writes the funds to an address on that chain which the destination may or may not control. Whether they come back depends on four things: whether the destination's keys also work on the chain used (the same address format on two chains does not mean the same key holder operates both); whether the platform supports that token and that network at all; whether the platform runs a recovery process for the case; and what that process costs and takes. Kraken's recovery page, as observed on 24 September 2026 (the page showed "Last updated: September 21, 2026"), lists free re-crediting for uncredited deposits, a network fee for missing-tag cases, a flat fee for unsupported tokens on supported networks, a higher flat fee for assets on unsupported networks, and states that "not all misrouted crypto deposits can be recovered" (Kraken Support, Crypto assets deposit recovery, accessed 24 September 2026; platform statement). Coinbase's help page, as observed on the same date, says "only certain assets and networks are eligible for recovery" and that sending on the wrong network "may affect eligibility", and it sets out a percentage fee on recoveries above a stated threshold plus network fees (Coinbase Help, Recover unsupported crypto, accessed 24 September 2026; platform statement). Both are each platform's own policy on that date and can change without notice, so check the current page before relying on either. The rule is therefore explicit matching: the sender's network choice and the receiver's stated network must be read, out loud if that is what it takes, and they must be the same words.

The memo, also called a tag or reference (both terms appear in the crypto glossary), is the field beginners meet at exchanges and custodial services, and it is destination specific: which chains use one, what it is called, and whether it is required all depend on the ledger and the platform. On the XRP Ledger the field is the destination tag, which "indicate[s] the beneficiary or destination for a payment"; hosted accounts such as exchanges typically assign one per customer, and a receiving account can set a RequireDest flag so that the ledger rejects payments that omit it instead of accepting funds it cannot attribute (XRP Ledger documentation, Source and destination tags, accessed 23 September 2026). On Stellar the field is the memo, an optional field in the transaction that custodians historically used to distinguish customers sharing one address (Stellar developer documentation, Memos, accessed 23 September 2026). Cosmos SDK chains carry a memo string in the transaction body, and exchanges that pool customers behind one ATOM address make it mandatory: Gemini's help page states that the address and memo are both required "to identify the proper individual account as Gemini uses a shared address" and that "failure to do so may result in loss of funds" (Gemini Support, How do I transfer ATOM via the Cosmos Network, accessed 24 September 2026; platform statement). On chains where accounts are cheap to create, such as Bitcoin and Ethereum, exchanges typically issue each customer a separate deposit address and ask for no memo. Where a deposit page shows a memo, it is part of the address for practical purposes: funds sent without it arrive at the platform and sit unattributed until a support process reattaches them, and Kraken's XRP page, as observed on 24 September 2026, warns that the omission "might even make the deposit irretrievable in certain cases" (Kraken Support, Destination Tag for XRP deposits, accessed 24 September 2026; platform statement). The receiving side of the drill: when a deposit page shows both an address and a memo, both travel together, always.

Diagram of the transfer triplet showing the address as the recipient on a specific ledger with checksums catching mangled strings and valid-but-wrong addresses as the danger, the network as the choice of ledger where the same asset exists as separate versions per chain and mismatched networks strand funds unless the platform runs a recovery process, and the memo as the account router at pooled custodial destinations such as XRP destination tags and Stellar or Cosmos memos where omission parks funds with the platform instead of the customer — Figure 1. The three fields that must match what the recipient controls: the address on the right chain, the network both ends agree on, and the memo where the destination pools accounts (XRP destination tags, Stellar and Cosmos memos).

Why is the wrong network an easy mistake, and how do you rule it out?

ตอบด่วน

Because interfaces can make networks look interchangeable, and because the same asset's name hides its many separate versions. You rule it out by reading the network on both ends and refusing to proceed on inference.

The mistake's anatomy is worth one honest paragraph, because it does not require carelessness. A user withdraws USDC from an exchange to a wallet; the exchange's screen offers half a dozen networks with the cheap ones preselected or prominent; the wallet, meanwhile, was set up for one chain, and its address format may look identical across several. Each individual screen made sense; the mismatch lived between them. Some wallets and exchanges run address-format checks that catch some cross-chain sends, and some block choices their side knows to be wrong. Checks of that kind cannot catch everything, because format compatibility across chains means some wrong choices validate. An Ethereum-format address is also a valid address on other EVM-compatible chains that use the same format, so a transfer on the wrong one of those chains confirms without complaint.

That same compatibility gives wrong-network sends between EVM chains the clearest recovery path when you hold the key: if the destination is a self-custody wallet whose key you hold, the funds sit at your own address on the other chain and can be moved once the wallet is pointed at that network. If the destination is an exchange deposit address, the exchange holds the key and recovery depends on its policy, fees and support for that chain. If the chains use different key schemes or the destination is a contract that exists only on one chain, there may be nobody who can sign on the other side. The guide to how blockchains differ covers the chain families; the point for this guide is that "sent on the wrong network" is a category with several outcomes, and the outcome is settled by who controls the key on the chain actually used.

Ruling it out is procedural. On the receiving end, establish the network explicitly: the wallet's receive screen names the chain per asset, and a deposit page states which networks it accepts. On the sending end, select that network by name, never by fee or by default. When the two ends' words match, proceed; when they do not, or when either end is ambiguous, stop and resolve, since ambiguity is the mistake's habitat. And when the destination is new, or the amount would hurt, the test transaction below makes the question empirical for that route at that moment.

What is the complete drill for a transfer that matters?

ตอบด่วน

Source the address properly, match the network explicitly, attach the memo where required, verify at the paste destination on the best display available, send a small test, confirm receipt out-of-band, then send the remainder over the proven route. Seven steps, one minute, covering the transfer-stage failure modes this cluster documents.

The drill in order. First, source: the address comes from the recipient's verified channel or your own address book, never from transaction history (the rule set out in the address poisoning guide) and never retyped by hand. Second, network: read it on both ends, match the words. Third, memo: if the destination shows one, it travels with the address. Fourth, verify: at the paste destination, compare a meaningful span of the address, ends and middle, against the source, and on hardware, read the device's display, which a compromised computer cannot redraw, as the blind signing guide explains. Fifth, test: for any amount that would hurt, send a small amount first over the exact route, same address, same network, same memo. Sixth, confirm out-of-band: the recipient, or your own destination wallet, shows the test arrived and is spendable; a screenshot from a counterparty is a claim, and your own wallet's view is the fact. Seventh, send the remainder over the now-proven route, unchanged in every field.

What the test proves, and what it cannot

A test transaction proves that a particular address, network and memo, as entered at that moment, delivered funds the recipient could see. That is a great deal, and it is less than a guarantee for the remainder. The remainder is a new transaction, and the route can change between the two: clipboard malware can swap the address on the second paste while leaving the first alone; a counterparty's deposit address or memo can be rotated by the platform between the test and the main send; a typo can enter the second entry that was absent from the first; and an attacker who has been watching a compromised device can wait for the larger amount. The test also says nothing about whether the recipient is who you believe they are. So the seventh step's "unchanged in every field" is a literal instruction: re-verify the pasted address against the source before the main send, and where possible send the remainder from the same saved address-book entry the test used rather than pasting again. The test reduces route risk substantially. Verification at each signing is what keeps it reduced.

Two notes complete the sender's side. Fees do their own job here: the guide to gas and network fees explains rates and timing, and this guide adds only the refusal it repeats deliberately: on transfers that matter, timely and predictable inclusion is worth more than the saving, and the test transaction's cost is small next to the amount it helps protect. And once a route is proven, save it: the address book entry, network noted, is what makes the next transfer to that counterparty a one-check operation instead of a seven-step one.

Checklist diagram of the transfer drill in seven steps: source the address from a verified channel or address book and never from history, match the network by name on both ends, attach the required memo, verify a meaningful span of the address at the paste destination on the best available display, send a test amount over the exact route, confirm the test arrived spendable in the destination wallet rather than by screenshot, then re-verify and send the remainder over the proven route unchanged — Figure 2. The seven-step drill for transfers that matter. One minute of procedure covers the transfer-stage failure modes described in this guide; the test lowers route risk and the re-verification before the remainder keeps it low.

What does careful receiving look like?

ตอบด่วน

Give the sender the right address for the network they will use, state the network in words, confirm arrivals in your own wallet, and treat unexpected items in your history as warnings. Receiving-side prevention mirrors the sender's drill.

Generating the address is the wallet's job; communicating it is yours, and the failure modes live in the communication. State the asset and the network alongside the address, so the sender's screen and yours agree on the ledger; for pooled destinations, pass the memo with the address every time. Send the address through a channel the counterparty can trust, and remember the blind spot both ends share: an address pasted into a chat can be swapped by malware on either machine, which is why meaningful arrangements deserve confirmation of the address across a second channel, the same out-of-band principle the drill uses for receipts.

Confirmation is your own wallet's view: the funds visible and spendable at your address, at the depth of confirmation the amount deserves; the guide to how crypto transactions get confirmed covers finality per chain. What arrives without explanation gets the poisoning guide's treatment: unknown dust and unfamiliar tokens are left alone and read as a signal that your address sits in someone's campaign dataset, sharpening the next transfer's care rather than softening it.

Frequently asked questions

I sent funds on the wrong network. Are they gone?

Sometimes, and the answer depends on who controls the receiving address on the chain you actually used. If you sent to your own self-custody wallet on a chain that shares the address format and key scheme (EVM-compatible chains are the usual example), the funds are at your address on that other chain and you can move them once your wallet is set to that network. If you sent to an exchange, the exchange holds the key on that chain and recovery follows its policy. As observed on 24 September 2026, Kraken's published schedule ranged from free to a flat fee depending on whether the token and network are supported, and Coinbase said eligibility is limited to certain assets and networks, may be affected by the wrong-network choice, and carries a percentage fee above a threshold (Kraken Support, Crypto assets deposit recovery; Coinbase Help, Recover unsupported crypto; both accessed 24 September 2026; platform statements). These policies can change, so read the platform's current page before opening a case. If the chains use different key schemes, or the destination exists only as a contract on one chain, there may be nobody who can sign on the chain you used. Contact the destination's support through its official channel with the transaction hash, the network used and the address. No outcome is guaranteed. Unsolicited offers from third parties to retrieve lost crypto for an upfront fee fit the pattern the FBI describes as recovery fraud, and the FBI's guidance is: "Do not pay for services that claim to be able to recover lost funds" (FBI, Cryptocurrency Investment Fraud, accessed 24 September 2026).

I forgot the memo or destination tag on an exchange deposit. What now?

The funds sit with the platform unattached to your account. Whether and how they are reattached is the platform's call. As observed on 24 September 2026, Kraken listed a missing or incorrect tag as a recoverable case for a network fee, while its XRP page warned of significant delays and that some such deposits can be irretrievable; Gemini's Cosmos page said omission "may result in loss of funds" (Kraken Support, Crypto assets deposit recovery and Destination Tag for XRP deposits; Gemini Support, ATOM via the Cosmos Network; all accessed 24 September 2026; platform statements). Check the current page, since these policies can change. Expect a support ticket, proof of the sending address and patience. The drill exists because those outcomes are set by the platform, and the sender has no say once the transaction confirms.

How big should a test transaction be?

Small enough that losing it would be a lesson you can afford, large enough to clear any minimum the destination imposes. Its size is not the point; the route's end-to-end proof is. A test proves the route as entered at that moment, so the remainder must travel the identical route, re-verified at the paste, rather than a freshly typed or freshly pasted one.

Do I need a new address every time I receive?

Wallets for some chains rotate receiving addresses by default, which helps with the concerns covered in the guide to on-chain privacy; old addresses generally remain valid. For routine counterparty payments, address stability is a convenience; for privacy, rotation is a tool. Both are receiving-side choices, and neither affects the sender's drill.

Can I cancel a transaction after sending?

Before confirmation, occasionally: on Bitcoin, a transaction that signalled replaceability can be replaced by a higher-fee version under the opt-in replace-by-fee rules (Bitcoin Improvement Proposals, BIP-125, 2015), and some Ethereum wallets let you replace a pending transaction with one using the same nonce; the fees guide covers the mechanics. After confirmation, the sender cannot cancel it, and protocol-level reversal is generally unavailable. A few interventions outside the protocol can exist in specific cases, and none is something a sender can count on. Where the receiving address belongs to an exchange or other custodian, that platform may be able to return or re-credit funds under its own policy; the Kraken and Coinbase recovery pages cited above are provider-specific examples of such policies, not general rules. Some tokens' contracts give their issuer powers to freeze or block addresses, as the smart contract guide explains; such a freeze can stop funds moving onward, and any return of them depends on the issuer's own terms. Chain-level interventions, such as Ethereum's 2016 hard fork after The DAO exploit, have been rare one-off events. The design assumption to carry: the moment of signing is the last decision point the sender fully controls, and everything in this guide happens before it.

Key takeaways

Three fields decide whether a transfer arrives: address, network and memo, and the sender's verification before signing is the safeguard that acts before the fact. The wrong-network mistake persists because one asset name hides many separate ledger versions; the cure is matching the network by name on both ends and refusing to proceed on inference. Protocol-level reversal of a confirmed transfer is generally unavailable, so recoveries that do happen come from outside the protocol, most often a platform's own process. A wrong-network send can be recovered only if someone controls the key on the chain actually used and, at a platform, only if the platform supports the case, at a fee and on terms that can change. Memos are destination specific: XRP uses destination tags, Stellar and Cosmos chains use memos, and where a deposit page shows one it travels with the address every time. The full drill for transfers that matter: verified source, explicit network, attached memo, paste-side verification on the best display, a test amount over the exact route, out-of-band confirmation, then the remainder re-verified and unchanged. A test reduces route risk, and re-verification at each signing keeps it reduced. Receiving mirrors the drill: state asset and network with every address, pass memos always, confirm in your own wallet, and read unexpected deposits as warnings.

Sources and further reading

Primary sources and platform statements for this guide. Exchange help-centre pages describe each platform's own policy as observed on 24 September 2026 and can change without notice; they are cited as platform statements, not as independent verification.