Transfer networks and fees

Why one USDT on two networks is two different things

USDT is not one token copied to a few places. Tether says on its own explainer page that issuance happens "on various blockchains with varying capabilities depending on the transport protocol used", and names thirteen of them: Algorand, Avalanche, Celo, Cosmos, Ethereum, EOS, Liquid Network, Near, Polkadot, Solana, Tezos, Ton and Tron. Thirteen separate ledgers, none of which reads any of the others.

A transfer network is simply the ledger your transaction gets written into. When you withdraw from an exchange you are choosing two things and not one: which token, and onto which ledger. A wallet that shows you the word USDT has told you the first and not the second.

The evidence for that sits in our own code. The crypto top-up registry behind the RGB panel knows nine assets and two of them are both called USDT: one on Tron with 6 decimals, one on BNB Smart Chain with 18 decimals. So "one USDT" is a million small units on Tron and a billion billion of them on BNB Smart Chain. One name, one logo, two counting scales. Code that treats the pair as interchangeable reads the amount wrong by a factor of a trillion.

Which network do I pick?

The rule is one sentence and the rest of this lesson explains that sentence: the receiver decides the network and you match it. The destination service names the network on its deposit page. Your job is to find that same string on the withdrawal page and select it, not something that resembles it and not something that is cheaper.

The big temptation is to infer the network from the address itself. Inside the Ethereum family that does not work at all, and our own code shows why: the address validation pattern for Ethereum, for USDT on BNB Smart Chain and for BNB itself is one identical string, 0x followed by forty hexadecimal characters. Our validator cannot tell those three apart because they are not tellable apart; the same twenty bytes are a valid address on all three chains.

The shape of an address narrows the family and never the network. A Tron address starts with T, a TON address with EQ or UQ, a Bitcoin address with bc1 or 1 or 3. Those differences tell you "this is not a Tron address"; they never tell you "this is an Ethereum address rather than a BNB Smart Chain one".

Three habits worth having: read the network name on both screens side by side and confirm they say the same thing; if the deposit page shows an extra field such as an identifier or a memo, that field is not optional; and send a small amount the first time, if the destination has not set a minimum. A small first transfer costs one extra fee and is worth it.

Where the fee comes from, and why no number is printed here

Three networks, three completely different logics. Understand these and any new network falls into place on its own.

The official Bitcoin developer guide says transactions "pay fees based on the total byte size of the signed transaction" and that fees per byte "are calculated based on current demand for space in mined blocks with fees rising as demand increases". Miners then order transactions by fee per byte and take from the top until the space is full. The consequence: sending ten dollars and ten thousand dollars with the same structure costs exactly the same. You are not paying for money moved, you are paying for space occupied.

Ethereum charges for computation rather than bytes. Ethereum's own documentation gives the formula: units of gas used, multiplied by the sum of the base fee and the priority fee. The base fee is set by the protocol and moves "by a maximum of 12.5% per block" up or down depending on whether the previous block was fuller or emptier than the target size, and that base fee is burned when the block is created, removed from circulation. The priority fee is the tip you add to make your transaction attractive to a validator.

Tron has a third model: instead of paying cash you consume resources. The Tron developer documentation says bandwidth covers the byte size of a transaction and energy covers contract execution, that every account receives a free 600 bandwidth daily quota, that energy has no free quota at all and must be obtained by staking TRX or having it delegated, and that when neither is enough the network falls back to "burning TRX from the sender's balance at fixed rates" and the transaction goes through anyway. That is why a transfer on Tron is nearly free for an account with TRX staked and is not free for an empty one.

Now the uncomfortable part. This lesson prints no fee number, deliberately. The fee on all three networks is a live market that moves by the hour; a number written today is wrong tomorrow, and a page carrying a stale number is worse than a page carrying none. What does not go stale is the three shapes above. Read the number where it is somebody's responsibility: the withdrawal page of the service you are sending from shows you that moment's fee before you confirm.

How many confirmations means done?

A transaction written into a block is not yet fully final. Every block built after it adds one confirmation and makes reversing it more expensive. The receiving service decides how many confirmations are enough, and that number is its choice rather than the network's.

Here are ours, read from the live crypto top-up registry behind the RGB panel: Bitcoin 1, Litecoin 2, Dogecoin 4, Ethereum 12, BNB Smart Chain 15, and Tron and TON 1. For Tron and TON the 1 is technical rather than a statement of trust: the services we read return only finalised transactions, so the "seen but not yet confirmed" stage does not exist on those two at all.

Now the part that is usually read backwards. A confirmation count is not comparable between two networks. Ethereum's documentation says the block time is 12 seconds, so 12 confirmations is about two and a half minutes. Bitcoin's documentation defines the difficulty target as 2,016 blocks in 1,209,600 seconds (two weeks), which is one block per 600 seconds on average, so a single confirmation on Bitcoin averages ten minutes. Our 15 on BNB Smart Chain is more cautious than our 1 on Bitcoin and still finishes sooner. Read a confirmation count next to that network's block time or your conclusion comes out inverted.

What actually goes wrong

There are three failure shapes that repeat, and none of them is the one a beginner is afraid of.

One: the exchange deducts the fee from the amount itself. You send 50 USDT and the destination sees 49 and change, and if the destination system is looking for an exact amount the match fails. This is common enough that our own top-up system has a dedicated recovery path for it: the user submits the transaction hash, we verify that hash on the chain, and we credit in proportion to what actually arrived, at the rate locked when the invoice was issued. The amount comparison happens in the network's smallest unit as a string through bcmath and never in floating point, because in money a rounding error is not a glitch, it is a discrepancy.

Two: the wrong network to a service's deposit address. Here everything depends on who holds the private key. If the address is your own wallet and you hold its key, the money on that other chain really is there and is usually reachable by importing that same key into a wallet that supports the network. If the address belongs to an exchange, you do not hold the key and nothing you do at your end changes that; a return, if it happens at all, is that service's favour and not your right.

Three: you have the token and no fuel. You hold USDT on BNB Smart Chain but your BNB balance is zero, so you cannot move it. The token and the fuel that moves it are two separate assets, and this is true on every contract chain. Before sending a token to a wallet, send a little of that network's own coin along with it.

One warning attached to the list above: any "support agent" who arrives in your private messages offering to reverse a wrong transfer is a scammer. The shape of that fraud is unpacked in the lessons of the security track.