Crypto Swap Checklist: Verify the Address, Network and Memo

Before you press send

By Marcus Richardson — Founder & Privacy Research Lead · Published September 19, 2026

An address can be valid and still be the wrong destination for your swap. A token can have the right ticker and still be on the wrong network. A transfer can reach an exchange’s wallet and still fail to credit your account because a required memo was missing.

Those mistakes often happen at the handoff between two screens: the receiving wallet supplies deposit instructions, while the swap form asks you to choose an asset and network. This guide gives you a way to reconcile those instructions before any funds move. It is meant to be used with the actual deposit screen open, not remembered as a list of address prefixes.

Start at the receiving end. If you are withdrawing to a self-custody wallet, open its receive screen for the intended account and network. If you are depositing into an exchange, open that exchange’s authenticated deposit page. Work backwards from those instructions to the swap’s receive selection and then to the payment you will send.

Write a destination card before opening the quote

A short note can prevent a surprising amount of confusion. Copy the values from the destination’s current instructions and label them in plain language. Do not copy an old transfer from your transaction history and assume it remains the correct route. For a custodial destination, the account’s deposit screen is the source to check each time.

This is a working note, not something to post in a public group. An address is not a spending secret, but attaching it to your identity can expose transaction history on public networks. Keep the card private, and never add seed phrases, private keys, backup files, or authentication codes to it.

Check the asset and network as one pair

Do not stop at “both screens say USDT” or “both screens say USDC.” The receiving service must accept the exact asset on the network selected for the payout. A network choice is part of the transfer instruction, not a cosmetic fee setting. The cheapest option in a dropdown is irrelevant if the destination cannot credit it.

For USDT, use Tether’s supported-protocol information when you need to verify issuer details. For USDC, Circle publishes official contract addresses by network. Those references help identify assets, but they do not prove that your particular exchange account accepts every issuer-supported network. You still need the recipient’s own deposit instructions.

A practical example: your destination displays USDT on Ethereum, while a swap quote offers USDT on TRON. Those are different delivery routes. Choosing the TRON option because its fee looks lower does not satisfy the Ethereum deposit instruction. Select a supported matching route, or stop and ask the destination service to clarify what it accepts.

Identical-looking addresses do not establish compatibility

Many EVM-compatible networks can use the same account-address format, and a wallet may show the same address on more than one network. The MetaMask guide to EVM networks explains that assets and transactions remain network-specific. An address beginning with 0x therefore does not tell you, by itself, which network a receiving service supports.

Imagine a deposit page displays a 0x address for a selected network. You paste it into a swap form, which accepts its format. That acceptance can establish that the text looks syntactically valid for the form; it cannot prove that the receiving company will credit a payout on every compatible network. Compare the network labels explicitly instead of treating successful form validation as a deposit guarantee.

The token contract identifies the token; it is not your receiving address

A token’s contract address and your wallet’s receiving address serve different purposes. When you verify a token using an issuer’s documentation, you are checking which asset a wallet or explorer is showing. You are not being instructed to send your swap payout to that token contract. The destination address should come from your own wallet’s receive screen or the receiving service’s deposit instructions.

Bridged, wrapped, and issuer-native versions can also need different treatment. If the destination specifies a particular version, match it exactly. Avoid inferring compatibility from a familiar logo. When the two services describe the token differently, ask whether their specific asset-and-network selections are compatible before creating an order.

Verify the source of the address, then the full address

Open the receiving service yourself through a saved official bookmark or its known application. Select the correct account and asset. Generate or display the current receiving instructions, then copy the address from that screen. If someone supplied a destination in a message, verify it through an independent trusted channel before treating it as authoritative.

After pasting, compare the full address with the source. Checking only a few characters at the beginning and end is weaker than verifying the entire value. Address-poisoning attacks exploit familiarity with lookalike addresses in transaction history; MetaMask’s explanation of address poisoning describes that threat. Do not use an unsolicited transfer as your address book.

For a hardware wallet, follow its official receive-address verification process and compare the address shown on the device where supported. Ledger’s hardware-wallet security guidance recommends verifying addresses on the device screen. The photograph above illustrates the type of device; it is not a screenshot of the address you should use.

A QR code reduces manual typing but does not eliminate verification. After scanning, inspect the decoded destination and the network selected by the sending application. If the QR includes other payment information, compare the amount and any supported identifier with the intended instructions. Stop if the scan opens an unexpected website or asks you to reveal wallet recovery information.

Do not fix a mismatch by trial and error

If the address changes after pasting, the form rejects it, or the displayed network differs from the one you selected, pause. Revisit the original receiving instructions and the sending application’s documentation. Do not delete characters, invent a prefix, or remove a required tag simply to make a form accept the entry.

A rejection can be a useful warning that the route is wrong. If the route is supposed to be supported, send a clear description to official support without sharing secrets. Describe the asset, network, address format, and error message. You can redact the address in a general question and provide the complete value privately only when needed for the investigation.

Resolve the memo or destination tag before moving on

Some receiving services use a shared blockchain address and an additional identifier to decide which customer account to credit. The identifier may be called a memo, destination tag, or another network-specific name. The requirement comes from the actual destination instructions; it is not safe to assume every address for a particular coin needs the same treatment.

On XRP Ledger, destination tags can identify the intended beneficiary within a recipient’s systems, as described in the official XRP Ledger documentation. Stellar likewise documents how exchanges can use memos to distinguish deposits to a shared account in its explanation of memo-less payments. These are reasons to inspect the receiving instructions carefully, not to invent a memo when none was provided.

Copy the exact required value into the corresponding field and preserve the expected type. A numeric identifier and a text memo should not be treated as interchangeable. If the recipient gives you an integrated address format that incorporates an identifier, follow the sender’s and recipient’s documented support for that format; do not split or transform it based on guesswork.

If your swap form has no way to supply an identifier that the destination explicitly requires, stop and contact support. Do not put the memo into an unrelated field such as an email address, refund note, or customer comment and assume the blockchain payout will include it. Ask whether the particular receive asset and route support the required identifier.

If you have already sent without a required memo, preserve the transaction hash and contact the receiving service. A successful on-chain transfer and a credited customer account are separate facts. Recovery may require manual work and is not guaranteed. Sending another payment with the memo does not automatically assign the first payment to your account.

Check the amount that will arrive and what you can do with it

A destination may set a minimum creditable deposit. Compare that minimum with the swap’s expected net payout, after any included charges, rather than the starting amount you plan to send. The two numbers may be denominated in different assets. Read the destination’s current policy instead of borrowing a minimum from another exchange or another network.

For example, a receiving service might require at least 20 units of a particular token on its selected network. A quote displaying 19.8 units would not meet that condition in this hypothetical case. A floating quote only slightly above 20 also deserves attention because the final output can change. Resolve that uncertainty before funding the swap, especially when the destination says smaller deposits will not be credited.

Check the sending side as well. If a withdrawal platform subtracts a fee from the amount you enter, the swap deposit can arrive short of its requirement. Use the withdrawal preview’s recipient amount to confirm that the order will receive what it requests. This is a different minimum and a different handoff from the payout arriving at your final destination. For worked examples, see how to compare the full cost of a swap.

Receiving a token and spending it later are different tasks

A self-custody wallet may display a received token even when it lacks the native asset normally required to send a later transaction. Before choosing a destination network, understand how your wallet pays transaction fees there. On Ethereum, the official gas documentation explains the ETH fee mechanism. Other networks and sponsored-fee arrangements have their own rules.

Write down your intended next action. Are you holding the token, paying someone, depositing into an application, or transferring it again? That next action may introduce a fee, approval, or additional compatibility requirement. Checking it now can prevent the awkward result of receiving the correct asset on a network you cannot conveniently use.

Do not confuse a wallet’s displayed fiat value with spendability. A large token balance does not necessarily provide the native asset needed for fees. Equally, a small native balance on one network does not automatically pay for a transaction on another. Use the wallet’s preview for the specific network and action you intend to perform.

If you run a test, make it a valid transaction

A small test can help verify a new route, but “small” still has to meet every applicable minimum. If the swap and the receiving service each impose limits, a test below either one may produce an unhelpful result. Plan a separate valid test order rather than sending a fraction of the payment requested by a larger order.

Before the test, define what success means. It should include a successful payout on the intended network and, for a custodial destination, an actual credit to the intended customer account. Seeing a hash alone does not test the entire route. If your next step requires spending the received token, decide whether you also need to verify that capability.

Keep the test’s order ID and transaction hashes so that its result is unambiguous. Then obtain fresh instructions and a fresh quote for any later order. A successful test does not make old deposit addresses, previous rates, or changed network conditions permanent. Recheck the details that can change rather than assuming the first transaction validates every future one.

Three situations worth rehearsing

You want to receive USDT at another exchange

Open that exchange’s USDT deposit screen and select the network you intend to use. Copy its current address and any extra instructions. Check whether deposits are enabled and whether the expected payout exceeds its minimum. In the swap form, choose the same receiving asset and network. Only then compare fees among compatible offers. If the exchange supports several networks, you can compare those routes separately, but each quote must remain paired with the correct deposit instructions.

You want to receive XRP at a hosted account

The receiving platform displays an address and a destination tag. Treat them as a pair. Copy the address from the deposit screen, copy the tag into the tag field, and verify both in the final review. If the sending route cannot include the required tag, do not proceed merely because it accepts the address. Ask about a supported route. The fact that the blockchain can deliver to an address does not mean the platform can automatically identify your account without the required information.

You want to receive a token in your own wallet

Choose the intended account and network in the wallet. Verify the receive address using the wallet’s documented process and, where applicable, the hardware device screen. Confirm the exact token version and how it will appear in the wallet. Check the fee asset needed for a later transfer. After the swap, inspect the outgoing transaction on the receiving network before treating a missing display balance as a failed payout. The swap troubleshooting guide explains how to separate those situations.

Your final sign-off checklist

Read these statements against the actual screens, not from memory. If you cannot honestly check one, resolve it before sending.

• The receiving asset and token version match the destination’s instructions.
• The receiving network matches on both the swap and deposit screens.
• The full destination address matches the trusted source after pasting.
• Every required memo or tag is present in the correct field.
• The expected net payout meets the receiving service’s current minimum.
• The sending preview delivers the exact deposit amount the order requires.
• The funding route can satisfy the quote’s payment conditions.
• I have saved the order ID privately and know where to track it.

When using AceChange, open the swap form only after the destination is ready. If any asset, network, or memo requirement is unclear, use the official contact page to ask before sending. For a broader explanation of token networks, see the existing ERC-20, TRC-20 and BEP-20 guide.

The purpose of this inspection is simple: make each handoff explicit. You should be able to explain what leaves your sending wallet, what the swap expects to receive, and what the final destination is prepared to credit. When those three descriptions agree, you have removed several avoidable sources of error without relying on a guess about an address or a logo.