One name, several assets
On an exchange, “USDT” is one line in a list. On the blockchains, it is at least half a dozen different things. There is a USDT contract on Ethereum, another on TRON, another on Polygon, and so on. They are pegged to the same dollar and issued by the same company, but a unit of one is not a unit of another, any more than a dollar in one bank’s ledger is a dollar in a different bank’s ledger. Moving between them is a conversion, not a transfer.
This is why an exchange withdrawal form asks a question that feels redundant — *which network?* — and why the answer matters more than the amount. The address you paste is only meaningful on the chain it was generated for.
That ordering is the whole safeguard. An address issued for TRON is being watched on TRON. A deposit that arrives for that same string of characters on some other chain is not seen, because nothing is looking there.
The mistakes that refuse themselves
Most chains have their own address format, and that is more protection than it sounds. A wallet validates the address before it signs anything, so sending across formats usually fails before it starts.
| NETWORK | ADDRESS BEGINS WITH | EXAMPLE SHAPE |
|---|---|---|
| Bitcoin | 1, 3, or bc1 | bc1q… (about 42 characters) |
| Litecoin | L, M, or ltc1 | ltc1q… |
| TRON (TRC20) | T | T… (34 characters) |
| Ripple (XRP) | r | r… — plus a numeric destination tag |
| Ethereum (ERC20) | 0x | 0x… (42 characters) |
| Polygon | 0x | 0x… — identical to Ethereum |
Five distinct formats, and one collision. The last two rows are the problem.
Paste a TRON address into an Ethereum send and the wallet will say the address is invalid; paste a Bitcoin address into a TRON send and the same. Those errors are not failures. They are the format doing its job — the mistake is caught at the sender, before any coins move, at no cost.
The one that does not
Ethereum, Polygon, BNB Chain, Arbitrum and every other EVM-compatible network share the same address format. The same private key controls the same 0x address on all of them. That is a convenience for developers and a trap for everyone else, because it means a transfer to the wrong EVM chain is valid. The wallet sees a well-formed address and signs. The chain accepts it. The coins land — on a network where the deposit address was never registered.
Concretely: an address issued here for Ethereum, sent to from an exchange with Polygon selected, receives Polygon tokens at an Ethereum address. Nothing rejected it. Nothing will credit it either, because the deposit system is watching Ethereum for that address and Polygon is a different ledger.
Whether coins in that position can be recovered depends on something the sender cannot see: whether the operator holds the key to that address on the chain the coins landed on, and whether it has a process for sweeping them. Sometimes it does. It is never automatic, it is never fast, and it is never something to count on. The honest framing is that a wrong-network EVM transfer is a recovery request, not a deposit.
The coin that needs a second number
XRP adds a different failure. A custodian typically holds all customer XRP in a small number of addresses and tells them apart by a destination tag — a number attached to the transaction that says whose deposit this is. The address routes the coins to the custodian; the tag routes them to you.
Send XRP to the right address with no tag and it arrives at the custodian correctly and unattributed — the ledger delivered it, and nobody knows it is yours. That is usually recoverable with the transaction hash and some patience, because the coins are at least on the right chain in the right place. But it is a manual match, and the deposit does not credit until someone makes it.
Before you press send
- Choose the network on the deposit screen first, then copy the address. The address is generated for that network; an address copied before choosing is an address for a guess.
- Match the network at the sending side to the one on the deposit screen, by name — TRC20 to Tron (TRC20), ERC20 to Ethereum (ERC20). If the sender offers a network the deposit screen does not list, it is not a supported rail; do not send on it.
- Look at the first characters of the address against the table above. If they do not fit the network you chose, stop. If they fit but the network is EVM, that check has told you nothing — go back to step two.
- For XRP, copy the tag as well as the address, and confirm the sending form has a field for it. A form with nowhere to put the tag is a form that will lose it.
- Send a small amount first on any network you have not used before. The cost of a test transfer is the network fee; the cost of skipping it is the whole deposit.
None of this is the house being difficult. It is the house being unable to see chains it is not watching — which is also, from the other direction, the reason a deposit waits for confirmations once it does arrive on the right one.
Once it lands, one roll checks everythingDice: the quickest verifiable round to run after a first deposit clearsDice →
What happens if I send crypto on the wrong network?
If the address format does not match the chain, the sending wallet usually refuses and nothing moves. If it does match — as it does across Ethereum, Polygon and other EVM chains, which share the 0x format — the transfer succeeds on a chain the deposit system is not watching, and it is not credited. Recovery is a manual request and is not guaranteed.
Is USDT on TRON the same as USDT on Ethereum?
No. They are separate assets on separate ledgers, pegged to the same dollar. A deposit address is valid on one chain only; the version of USDT you send must be the one that chain carries.
Why does the deposit screen ask for a network before showing an address?
Because the address only exists for a specific chain. The wallet asks the server which networks a coin is available on, and issues an address for the one you choose — so that the chain being watched and the chain you send on are the same by construction.
What is an XRP destination tag?
A number attached to an XRP transaction that tells a custodian which customer a deposit belongs to. The address routes coins to the custodian; the tag routes them to you. XRP sent without it arrives unattributed and must be matched by hand.
How can I tell which network an address is for?
Often from its first characters — T for TRON, r for XRP, 1/3/bc1 for Bitcoin, L/M/ltc1 for Litecoin. The exception is 0x, which Ethereum, Polygon and every other EVM chain share; for those, only the network selector tells you.
- Betkyo client source: networkDefinition.ts (the supported rails), ECoinType NETWORK and TAG with their source annotations in CoinStore.ts, the network-first address flow in deposit.tsx and useCoinNetworks.ts
- Address formats are public protocol conventions — Bitcoin BIP-173 (bech32), TRON base58 with the T prefix, the XRP Ledger destination tag, and EVM 0x addresses shared across Ethereum-compatible chains
