Sending USDC or USDT is usually quick, which is exactly why a disciplined pre-transfer routine matters. The network may accept a transaction in seconds, but a wrong network, wrong address, missing memo, or fraudulent destination can be difficult or impossible to correct. Most serious transfer mistakes happen before the user presses confirm: the destination was copied from the wrong place, the network selector was overlooked, or a familiar ticker was mistaken for the intended token contract.
The checklist below is designed for both hosted and self-custody wallets. Use it for a first-time recipient, a new exchange deposit, a business payment, or any transfer large enough that recovery would be painful. For routine small payments, convert the steps into a short written procedure rather than relying on memory.
Step 1: Pause and define the transfer
Write down the asset, amount, network, destination, and purpose. “Send 2,500 USDC on Base to the supplier address shown in the authenticated vendor portal” is specific. “Send stablecoins to Alex” is not. A precise instruction gives you something to compare against every screen that follows.
Confirm that you are not acting under artificial urgency. Scammers frequently claim that an account is compromised, a refund is waiting, or a payment must be completed immediately. Stop if anyone directs you to move funds to a “safe wallet,” install remote-control software, or share a recovery phrase. Independently contact the supposed sender through a known channel.
Step 2: Confirm the exact token
USDC and USDT are distinct tokens, and each can appear on multiple networks. Check the full asset name and, for self-custody or contract interactions, the official contract or asset identifier. Do not trust a logo or ticker alone. Scam tokens can copy both. If a token appeared unexpectedly in your wallet, do not visit a website embedded in its name or description.
When depositing to a service, begin from that service’s deposit screen. Select USDC or USDT there before copying an address. If the service lists only one of the two, do not send the other even if the address format looks compatible. Internal accounting systems may credit only the selected asset.
Step 3: Match the network at both ends
The sending wallet and receiving destination must use the same blockchain network. Ethereum, Base, Arbitrum, Solana, Tron, Polygon, and other networks are separate routes. Some share similar address formats, especially Ethereum-compatible networks, but that does not make deposits interchangeable. A destination may monitor one network and ignore another even when the address characters are identical.
Read the destination’s network label and any warning text. Then select that same network in the sending wallet. Do not choose a cheaper option unless the destination explicitly supports it. If the intended route requires a bridge, treat bridging as a separate transaction with its own risks, fees, and verification steps.
Step 4: Obtain the destination address from a trusted source
Copy the address directly from the authenticated destination account, a verified invoice system, or a previously approved address book. Avoid addresses in email threads, chat messages, screenshots, and transaction-history look-alikes. Business-email compromise often involves changing payment instructions inside a genuine conversation.
After pasting, compare the address on the final signing screen with the source. Check more than the first and last four characters when the interface permits. Clipboard malware can replace an address, and address-poisoning attacks can create look-alike history entries. For business payments, verify new or changed addresses through a second communication channel using a known contact.
Step 5: Check for a memo, tag, or reference
Some destination services use one address for many customers and rely on a memo, destination tag, or reference to identify the account. Omitting or mistyping it may leave the funds at the service without automatic credit. Recovery may require support, identity documents, a transaction hash, and a fee.
Copy the memo exactly and confirm whether it is numeric, text, or optional. If the sending wallet does not provide a field required by the destination, stop. Do not place the memo in an unrelated note field and assume the service will interpret it.
Step 6: Verify the native fee balance and total cost
A self-custody wallet normally needs the network’s native asset to pay transaction fees. An Ethereum-network transfer may require ETH; a Solana transfer may require SOL; other networks have their own fee assets. Having a USDC or USDT balance does not guarantee that the wallet can send it. Obtain only the fee token from a route you understand, and avoid unknown “gas top-up” links.
Review the total fee and any platform charge. Hosted services may deduct a fixed withdrawal fee or reduce the amount received. Make sure the destination minimum is met after fees. For business invoices, state whether the sender or recipient is responsible for fees so the credited amount matches expectations.
Step 7: Send a test transfer
For a new route or meaningful amount, send a small test that is large enough to exceed the destination minimum. Wait until the destination credits it, not merely until a block explorer shows a transaction. A service may require multiple confirmations or manual review. Verify that the credited token and network are correct.
A test transfer does not eliminate every risk. The destination could be compromised between the test and the main payment, and a dishonest counterparty can confirm a test address. Repeat the address and network review before the second transfer. Still, a test is one of the best ways to catch incompatible routing and memo errors.
Step 8: Perform the final signing review
On the final screen, verify the token, network, destination, amount, fee, and memo. If using a hardware signer, compare the details on its trusted display rather than only on the computer. Do not approve a contract interaction you do not understand. A request to grant an unlimited token allowance is not the same as a simple transfer.
Many public blockchains do not provide a central authority that can reverse a confirmed transaction. Ethereum.org’s guidance on transaction finality and wallet control explains that funds sent to a wrong address generally cannot be recovered by the network. That makes the final review a security control, not a formality.
Step 9: Save the transaction record
Record the transaction hash, date and time, network, token, amount, fee, destination, and purpose. Businesses should also record the invoice, counterparty, preparer, and approver. A blockchain explorer link can help, but the hash itself is the durable identifier. Keep records in your accounting or payment system rather than only in chat.
Confirm that the recipient has credited the payment. A successful onchain transfer proves movement to an address, not that a business has matched it to an invoice or that a centralized service has posted it to the correct account. Resolve mismatches promptly while records and staff context are available.
Special cases that require extra care
Exchange deposits
Use the deposit instructions generated inside your logged-in account. Confirm the network is currently enabled and the amount exceeds the minimum. Do not assume an old deposit address remains supported after a platform migration.
Recurring supplier payments
Use an approved address book and require independent verification for any change. Consider a small verification payment after a change even when the supplier’s email appears genuine. Separate payment creation and approval for material amounts.
Wallet-to-wallet transfers you control
Label addresses by network and purpose. Test the recovery of the destination wallet before moving a large balance. Ensure the destination has or can obtain the native fee token needed for a future outgoing transaction.
Cross-chain bridges
Confirm the source asset, destination asset, bridge contract, destination network, expected completion process, and recovery options. Use only a route documented by the issuer or ecosystem you trust. Bridging adds smart-contract and routing risk beyond an ordinary transfer.
The 60-second pre-transfer checklist
- I selected USDC or USDT intentionally.
- The sending and receiving network names match exactly.
- The token contract or asset identifier is verified when relevant.
- The destination address came from a trusted, current source.
- Any memo or tag is present and correct.
- The wallet has the native fee asset.
- The amount after fees meets the destination minimum.
- A test transfer succeeded for a new or high-value route.
- The final signing screen matches my written instruction.
- I saved the transaction hash and payment record.
Make verification the normal workflow
Safe stablecoin transfers are not about memorizing every blockchain detail. They are about using the same sequence every time: define the payment, confirm the asset, match the network, verify the address and memo, fund fees, test the route, review the signature, and save the record. Consistency makes anomalies easier to notice.
Before selecting a route, review stablecoin network fees and native versus bridged assets. Those two concepts explain many of the confusing choices presented by wallet interfaces.
