TRC20, ERC20, BEP20: choosing a network
Three token standards on three blockchains, with withdrawal costs that differ by an order of magnitude and compatibility rules that quietly overrule the cost question. This piece sets out what each one is, what each typically costs, and why the receiving side gets a vote before you do.
The three, at a glance
- Tron (TRC20)
- Around 1 USDT · blocks about every 3 seconds
- Ethereum (ERC20)
- Several times the Tron figure · slots about 12 seconds
- BNB Smart Chain (BEP20)
- Typically below the Tron figure · quick, like Tron
The withdrawal screen asks you to pick a network before it will let you paste an address, and the selector opens on whatever you chose last time. Most people take the cheapest option or the familiar one, and most of the time that works. The times it does not are expensive, slow to fix, and occasionally permanent. The decision has two parts, and the cheap part is the second one.
What are TRC20, ERC20 and BEP20?
They are token standards: TRC20 is the fungible token standard on the Tron blockchain, ERC20 is the equivalent on Ethereum, and BEP20 is the equivalent on BNB Smart Chain.
A token standard is an agreed set of functions a smart contract must expose so that wallets, exchanges and other contracts can handle any token the same way. Balance lookups, transfers, spending approvals. The ERC20 specification on ethereum.org is the original and the other two are close relatives of it. That family resemblance is convenient for developers and confusing for everyone else, because it makes three different things look like variations on one thing.
They are not variations. Each standard exists on exactly one blockchain, and blockchains do not read each other.
The same ticker on two networks is not the same asset for transfer purposes.
USDT is the case that catches people. There is a USDT contract on Tron and a USDT contract on Ethereum, both issued by the same issuer, both redeemable against the same reserves, both worth the same on any exchange. They are still two separate objects. A Tron validator has never heard of your Ethereum balance and has no mechanism to move it. When you swap between them on an exchange, nothing crosses a chain: the exchange debits its Tron holdings and credits its Ethereum holdings, or the reverse, using inventory it already had on both sides.
Tron, Ethereum and BNB Smart Chain are three independent ledgers. The word "USDT" appearing on all three is a naming convention, not a bridge.
Naming makes this harder than it should be. The same network turns up in dropdowns as "TRC20", "Tron (TRC20)" or just "Tron"; BNB Smart Chain appears as "BEP20", "BSC" or "BNB Smart Chain (BEP20)". Those are labels for the same thing. What is not the same thing is BEP2, the older standard on BNB Beacon Chain, whose addresses begin bnb1 and which required a memo on every deposit.
Treat BEP2 as history rather than a network you choose. BNB Beacon Chain was shut down through the BNB Chain Fusion programme, with validators stopping at the end of 2024, and the official token recovery path has since been wound down in turn. In 2026 an ordinary withdrawal screen should not be offering it. If you still see a bnb1 address, a BEP2 option or an old memo instruction somewhere, that is a stale interface, an unmigrated legacy balance, or a scam page — not a cheap alternative to BEP20. Do not send to it. Assets stranded on Beacon Chain are a recovery problem to raise with the platform holding them, and BNB Chain’s own recovery tool sunset notice is the document that describes what is still possible and until when.
The live BNB network for tokens is BNB Smart Chain, and its addresses are ordinary 0x EVM strings with no memo. The practical consequence for a 2026 transfer is short: if a dropdown shows BEP20 or BSC, that is the BNB option; anything labelled BEP2 or Beacon Chain is not an alternative to it.
Which network is cheapest to withdraw on?
As of 2026-08, USDT withdrawals on BNB Smart Chain typically cost the least, Tron sat around 1 USDT, and Ethereum ran several times higher and moved with gas prices.
The important framing first: the number you pay is set by the exchange, not by the network. An exchange pays the network fee itself and charges you a flat figure in the token, adjusted periodically to cover its costs with a margin. That is why two exchanges quote different withdrawal fees for the same asset on the same chain on the same day. The live figure appears on the withdrawal screen before you confirm, and that figure is the only one that is authoritative.
| Network | Standard | Typical USDT withdrawal fee band | Settlement feel | Where it is accepted |
|---|---|---|---|---|
| Tron | TRC20 | Around 1 USDT, stable month to month | Quick. Blocks arrive about every 3 seconds | Very widely, on exchanges, payment desks and most wallets |
| Ethereum | ERC20 | Several times the Tron figure, and it moves with gas | Slower. Slots are about 12 seconds and exchanges wait longer | Universally, and required for anything on Ethereum itself |
| BNB Smart Chain | BEP20 | Typically below the Tron figure | Quick, in the same order as Tron | Most centralised exchanges; patchier outside crypto-native services |
Two mechanical details that the table cannot show. The fee is denominated in the asset you are sending, so it comes out of the amount rather than being billed separately, and the amount that lands is your figure minus the fee. Each network also carries its own minimum withdrawal, usually set a little above the fee, which is why a network can be technically available and practically unusable for a small amount.
Bands checked 2026-08. Treat them as the shape of the thing rather than as quotes. Ethereum in particular is a moving target, because the exchange has to cover gas that varies with demand for block space, and it re-prices when the average moves enough to matter.
Put the numbers against a transfer and the ordering stops mattering as much as people think. On a 5,000 USDT transfer, a 1 USDT fee is 0.02%. Even a fee ten times larger is 0.2%, which is real but not decisive. On a 40 USDT transfer, a 1 USDT fee is 2.5% and the Ethereum equivalent could take a quarter of the amount. The fee only matters relative to the size of what you are moving, which is the argument made at more length in the piece on what moving USDT actually costs.
A cheap network is worth nothing if the destination cannot credit it. Every recovery request described in the piece on deposits that did not arrive started with someone optimising the fee before confirming the destination. Order of operations is the whole discipline here.
Block time is not the wait you feel
Tron produces a block about every 3 seconds and Ethereum a slot about every 12 seconds, but what you actually wait for is the exchange's confirmation requirement, which is longer than either.
Block time is the protocol's heartbeat. It tells you how often new transactions can be included, and it is a fixed property of the chain. Tron's roughly 3-second cadence and Ethereum's roughly 12-second slot are the two numbers worth remembering.
Neither is what you experience. A receiving exchange will not credit a deposit on the first block that contains it. It waits for a number of subsequent confirmations, because a very recent block can still be reorganised away. That number is set per asset and per network by the exchange itself, and it is not a protocol constant. Different exchanges pick different values for the same asset, and an exchange can change its own requirement without announcing it.
Ethereum adds a second layer to this. Slots are grouped into epochs of 32, and a block is only finalised after a further couple of epochs, which is why a cautious Ethereum deposit policy can feel slow even though the chain is producing blocks steadily. Tron's higher block rate means the same number of confirmations elapses faster in wall-clock terms.
The practical version: on Tron and BNB Smart Chain a deposit usually appears within a couple of minutes. On Ethereum it is longer, and how much longer depends on the exchange's policy rather than on anything you can influence by paying more.
Ask the receiving side first, compare fees second
Ask the receiving side which networks it supports for that specific asset, get the deposit address from it for that specific network, and only then compare cost among the options that remain.
This ordering is not a stylistic preference. It is the difference between a routine transfer and a support ticket. The cheapest network is useless if the destination does not credit it, and there is no partial credit for having chosen well on price.
- Open the receiving side first. A wallet, another exchange, a merchant, a person. Find the deposit page for the exact asset you are sending.
- Read which networks it lists for that asset. This varies by asset even within one destination: a service might accept USDT on three networks and some other token on only one.
- Generate or request the deposit address on the network you intend to use. Addresses are network-specific in practice even when they are not in format, and taking the address from the correct network's page is how you avoid the whole class of problem.
- Now go to the sending side, select the same network, and paste that address.
- Compare fees only among networks that survived steps two and three. If only one survived, there is nothing to compare and you are done.
A destination that says only "USDT" with no network named is not giving you enough information. Ask. If it is a person or a small merchant, ask in writing, and ask them to send the address and the network in the same message so there is no ambiguity about which address belongs to which chain.
The step people skip is the third one. They already have an address saved from a previous transfer, they assume it works for any network, and the format check passes. It is a completely reasonable assumption and it is wrong.
There is a second compatibility question that only bites when the destination is a self-custodied wallet rather than an exchange. Every chain charges its own gas in its own native coin. To move a TRC20 token onward from your own wallet you need some TRX in that wallet; to move a BEP20 token you need BNB; to move an ERC20 token you need ETH. Arriving with a balance of tokens and zero native coin leaves you holding something you can see and cannot send. Exchange deposits do not have this problem, because the exchange funds its own gas. Personal wallets do, and it surprises people the first time.
So the fuller version of the rule is: ask the receiver which networks it credits, then ask yourself what you intend to do with the funds once they land, and only then look at the fee column.
When is ERC20 worth paying for?
When the funds need to interact with something deployed on Ethereum itself, when the counterparty supports nothing else, or when the amount is large enough that the fee difference is a rounding error.
The cheapest option is not automatically the correct option, and treating Ethereum as an obsolete expensive choice leads people into worse outcomes than the fee they avoided.
You are going to use an Ethereum application. Lending markets, decentralised exchanges, staking contracts and marketplaces deployed on Ethereum need the asset on Ethereum. Withdrawing to Tron to save a few units and then bridging across afterwards means paying a bridge fee, paying gas on arrival anyway, and taking on the risk of a bridge in exchange for a saving that was smaller than any of those costs.
The counterparty only takes ERC20. Institutional custodians, older integrations and some payment processors support Ethereum and nothing else. Their constraint is your constraint. There is no negotiating with a deposit page.
The amount is large. Fee as a percentage is what matters. On a six-figure transfer, the gap between a 1 USDT fee and a much larger one is a fraction of a basis point, and it should not outweigh a preference for the chain with the deepest tooling and the longest operational history.
The token only exists there. Many tokens have never been deployed anywhere but Ethereum. If yours is one of them, the network selector will show one option and the question is settled.
Two chains, one identical address format
Ethereum and BNB Smart Chain use an identical address format, so an address valid on one is syntactically valid on the other, and no validation step anywhere can tell you which chain it was meant for.
Both are EVM chains. Both use a 20-byte account address written as 0x followed by 40 hexadecimal characters. The same private key produces the same address on both. That was a deliberate design decision, and for self-custodied wallets it is genuinely helpful, because one address works everywhere in that family.
For exchange deposits it is a trap. The exchange's address for your BNB Smart Chain deposits may be watched only on that chain. Send ERC20 tokens to it and the transaction confirms perfectly well on Ethereum, the tokens sit at an address the exchange controls, and nothing credits your account because no process is looking there.
Tron addresses look different. They are base58-encoded, start with T, and run 34 characters, so a Tron address pasted into an EVM field will be rejected outright. That visual distinctness is protective, and it is why Tron-to-EVM confusion is much rarer than the EVM-to-EVM kind.
A green tick beside the address field means the characters are well-formed and the checksum passes.
It does not mean the address exists on the network you selected, that anyone is watching it, or that the destination will credit what arrives. The network dropdown is the field that decides where the money goes, and nothing validates your choice there.
One more wrinkle. Because Tron and Ethereum addresses can be derived from the same underlying key material and differ only in encoding, some tools will happily convert between the two representations. That does not make the accounts interchangeable across chains. A converted address is a different chain's account, not a route between chains.
The other version of this mistake involves the native coin rather than a token. Sending BNB itself to an EVM address is a transfer of the chain's own currency, not of a BEP20 contract balance, and some destinations credit tokens on a chain while not crediting the chain's native coin to the same address. The deposit page tells you which assets that address is for. Read the asset name as carefully as you read the network name.
Should I send a test transfer first?
Yes, whenever the address or the network is new to you, and the cost of doing so is one extra flat withdrawal fee.
The procedure is short. Send the smallest amount the destination will accept. Wait until it is actually credited and visible in the destination's balance, not merely confirmed on chain. Then send the rest to the same address on the same network.
The arithmetic is easy to argue with yourself about and easy to settle. On Tron at around 1 USDT a withdrawal, testing a large transfer costs about 1 USDT. Against a four-figure amount that is a fraction of a percent for confirmation that the whole path works. On Ethereum the same insurance costs more, and there is a size below which paying two Ethereum withdrawal fees is not sensible.
Worth testing: any new address, any network you have not used with that destination before, any address you retrieved from a saved note rather than freshly from the destination's deposit page, and any amount you would be genuinely upset to lose. Not worth testing: repeat transfers to an address you have used successfully within the last little while, using the same network, where nothing about the destination has changed.
Two limits on what a test proves. It confirms that the address and network combination works, and it does not confirm anything about a memo or destination tag, which is a separate failure mode covered in the piece on deposits that did not arrive. It also does not protect you against the destination changing its address afterwards, which is why fresh addresses beat saved ones.
I default to testing when anything at all is new, including a network I have used before with a destination I have used before. The habit costs about a unit of currency and it converts a category of irreversible mistake into a category of mildly annoying one. That trade has been worth taking every single time.
Is USDT on Tron the same as USDT on Ethereum?
Not for transfer purposes. They are two separate contracts on two separate blockchains, each issued by Tether and each redeemable against the same reserves, but a Tron node has no knowledge of an Ethereum balance and cannot move one. Economically they trade at the same value. Mechanically they are different objects, and sending one to an address that only handles the other is one of the most common causes of a stuck deposit.
Is BEP20 always cheaper than TRC20?
Usually, but not by an amount that should decide anything on its own. As of 2026-08, exchange withdrawal fees for USDT on BNB Smart Chain typically sat below the Tron figure, which itself sat around 1 USDT. Both are small enough that the difference is a rounding error on any transfer worth making. The fee shown on the withdrawal screen at the moment you confirm is the only figure that is actually true.
Why does my wallet accept an address for the wrong network?
Because the address is correctly formatted, and format is all the interface can check. Ethereum and BNB Smart Chain use identical address formats, so a validator has no way to tell which chain an address was intended for. It sees forty valid hexadecimal characters and a valid checksum and accepts them. The network selector, not the address field, is what determines where the funds go.
Do I have to use ERC20 if I want to use DeFi later?
Only if the application you want to use is deployed on Ethereum itself. Plenty of lending markets, exchanges and yield products run on other chains and want the token in that chain's native standard. Decide which application you are heading for, find out which chain it lives on, and withdraw directly to that chain. Withdrawing to the cheapest network and bridging afterwards usually costs more than sending to the right one in the first place.