Sending USDT on the right network, and why mistakes are hard to undo

Tether issues USDT on a long list of blockchains, including Ethereum, Tron, Solana, TON and Avalanche, and says a token on one of them should be treated as equal to, and interchangeable with, a token on any other. That is a statement about what the tokens are, not about where they are. Each version is a separate token on its own chain, identified there by its own contract or asset address, and a transfer is recorded only on the network it was sent on.

This is why Tether asks the platforms that integrate its tokens to make explicitly clear which networks they support, and why its advice to anyone sending is so direct: send USDT only to addresses that explicitly state they support it, because a transfer to any other destination could result in a total loss of funds. The simplest way to send USDT on the right network is to treat the network as part of the destination rather than a setting beside it. The address says who is being paid; the network says where.

Network labels on a sending screen can be less specific than they look. Tether's list describes USDT on Tron as a TRC20 token, but it lists the ERC20 form on Ethereum, Avalanche, Celo, Kaia and Cosmos (via Kava), so a label that names only the token standard does not tell you which chain the payment will use. Compare the full network name in your wallet with the network shown at checkout, and if the two do not plainly match, stop before sending rather than after.

The amount deserves the same care. Send the figure the payment request shows, and check what will arrive rather than only what you typed. From your own wallet on Ethereum, the fee is paid in ETH, separately from the USDT being sent: ethereum.org's worked example of a transfer credits the recipient with the full amount and deducts the fee from the sender on top. From an exchange account, look for the amount the recipient will receive on the final confirmation screen, and correct it before confirming if it falls short.

Every Ethereum transaction pays a network fee, known as a gas fee, and ethereum.org is unambiguous that gas fees have to be paid in ether (ETH). The USDT being sent cannot pay for its own transfer, so an ordinary wallet holding USDT on Ethereum but no ETH has nothing to pay the fee with, and cannot send the payment until it does.

The fee also moves with demand. The protocol sets a base fee, the sender adds a priority fee as a tip, and when the network is busy the tip needed for prompt inclusion rises; a transaction that offers too little may be included late or not at all. Most wallets fill in a recommended fee automatically, and that is usually the one to accept when a payment is waiting. One detail is easy to miss: the fee is paid whether the transaction succeeds or fails. Whichever network checkout names, look at the fee your wallet quotes on that network, and at the currency it will be charged in, before you commit.

Pressing send starts a payment rather than finishing it. The transfer is given a transaction hash, also called a transaction ID, and broadcast into a pool of pending transactions until it is included in a block. For Ethereum, Etherscan's documentation explains that the wait depends on how busy the network is and on the fee attached, and that when traffic is heavy, transactions offering lower fees can be left pending while higher-fee ones go first.

Once included, the transfer starts collecting confirmations: the number of blocks added to the chain since the block that holds it. Different platforms require different minimum numbers before they treat an incoming payment as received, so a wallet that shows success and a recipient that still shows waiting are not contradicting each other. Let the confirmations arrive rather than sending the payment a second time, and keep the transaction hash until the order is complete: pasted into a block explorer for the network you used, it shows the transfer's status and details.

There is no reverse button for a transfer that went somewhere unexpected. Tether's first advice for tokens sent to an unsupported destination is to contact the receiving party immediately and ask for help returning them, which it describes as occasionally a far more expedient route than approaching Tether. During a purchase, that means contacting the merchant's support with the transaction hash, the network used, the amount and the destination address, supplied as text rather than only as screenshots.

Tether does run its own recovery process, and its published terms show why it is a last resort. Requests are accepted only for amounts above $1,000, and only from users who complete Tether's verification. Whether a recovery is feasible is assessed at Tether's sole discretion, depends on the blockchain involved, and is final; success is not guaranteed; a fee of up to 10% of the amount or $1,000, whichever is greater, is deducted from anything recovered; and the process can take several months. For smaller payments the route does not exist at all, which makes the checks before sending the protection that counts.