How to Verify a TRC-20 Transfer on TRON: A Step-by-Step Guide

A green tick in your wallet does not mean the money arrived. On TRON it means one thing only: the network accepted and broadcast your signed transfer. Whether that transfer reached the right address is a separate question, answered in a separate place.

So this guide runs the whole check in order. First, what you check before you send. Then what the wallet's confirmation screen shows you. Then what the TRONSCAN receipt proves after the fact, and which field settles each part of the question.

Five steps, and nothing here needs a developer background. The only tool is the block explorer TRONSCAN, and you reach it by typing tronscan.org into the address bar. Bookmark it rather than searching for it, because look-alike sites use similar names and show false data.

1. What 'the transfer worked' actually means

Three different things get called success on TRON, and they happen in order. Knowing which one you are checking is most of the work, because each is confirmed somewhere else.

Most people stop at the first question, because the wallet gives them a green tick and they move on. That is exactly how a mistyped address can look like a completed payment for days.

One more outcome needs naming before we start. It looks like a fifth status, but it is not one: the TxID returns nothing at all.

TRONSCAN has no record of it. That happens when the transfer was never broadcast, when the hash was copied wrong, or when the transfer went out on a different chain entirely. 'Not found' is not a failure state. It is an absence of evidence. It is also the one result you should never accept as proof of payment.

2. Step 1 — Verify the recipient address before you send

This is the only check in the whole guide that can prevent a loss rather than detect one. Do it slowly, once per payee, and then save the result.

1. 1Read the full recipient address, character by character, against a second channel: the counterparty's own message, an invoice, or a signed confirmation. A TRON address is 34 characters and starts with T. The short form your wallet shows (first four and last four) is not enough, because matching those eight characters is cheap to generate.
2. 2Confirm the full string through that second channel, not by re-reading the address you already pasted. Re-reading your own paste only proves you can copy.
3. 3Send a small test transfer first, to the exact address you will use for the real payment, and wait for the recipient to confirm it landed. A test bounds a mistake to a few dollars instead of the balance.
4. 4Save the verified address in your wallet's address book, then send the real payment by selecting that entry rather than pasting anything.

3. Step 2 — Verify you have enough energy and bandwidth

Before you send, check two resources. They do not cover each other. A large energy balance will not cover a bandwidth shortage, and the free bandwidth allowance cannot pay for contract execution at all.

The number that matters for energy is EnergyLimit minus EnergyUsed, not the limit on its own. Both the wallet's resource panel and TRONSCAN's account page split the figure into used and limit, so read the remaining value.

TRONSCAN's account page needs no wallet connection and no signature. Paste the address into the search bar. Then open the Resources section. The Tokens section on the same page is useful later in this guide.

Now the sizing. A TRC-20 USDT transfer consumes roughly one of two amounts.

The rule behind the two figures is the token contract's own storage cost, not anything about the account's age. USDT keeps every holder's balance in a slot inside the contract. Creating a brand-new slot costs the TRON Virtual Machine 20,000 energy. Overwriting a slot that already holds a number costs 5,000.

So a transfer to an address whose USDT balance is zero writes a new slot. One to an address that already holds USDT does not. The gap between the two practical figures is wider than the 15,000 difference in those two slot prices. The contract applies its own energy multiplier to the whole call.

Treat both numbers as planning figures rather than constants. The contract's cost model is recalculated on a fixed cycle, so re-read the amount close to the moment you send. One consequence catches people out every week: the tier follows the recipient's USDT balance right now. An address that has been active for years but sits at zero today is priced exactly like one the chain has never seen.

If your remaining energy is short, the network does not stop you. It burns TRX from your balance to cover the shortfall, priced at 100 sun per energy unit. One TRX is 1,000,000 sun, so 65,000 units comes to 6,500,000 sun, which is 6.5 TRX. That is about $2.2 at a TRX price near $0.34, and a first-time recipient at 130,000 units costs 13.0 TRX, roughly $4.4.

The better route is to hold the energy before you send. Energy you hold covers the fee and nothing is burned. Energy can be staked or rented onto the address you send from. Either way it has to sit on that address, not on the app you use.

Bandwidth is the smaller line, but it can still stop a send. A TRC-20 transfer is about 350 bytes. Every activated account gets 600 free bandwidth points per day. The allowance refills across a rolling 24-hour window at roughly 25 points an hour, rather than resetting at midnight.

Anything beyond the free allowance burns TRX at 1,000 sun per byte, which is 0.001 TRX. On a normal day with an active account, the free allowance covers a transfer and nothing is charged for bandwidth at all.

4. Step 3 — Read the confirmation screen before you sign

Your wallet simulates the call in the background and shows you what it will cost before anything is submitted. This is your free measurement. Backing out at this point sends nothing and costs nothing.

Check four things on that screen.

• The recipient string, expanded to the full 34 characters, not the truncated display.
• The amount, including the decimals. USDT on TRON has 6 decimals, so 100 USDT is written 100.000000, and a careless extra digit is a real risk.
• The asset. Confirm it is USDT and not TRX and not another token with a similar name.
• The fee lines. A wallet typically shows bandwidth, energy and the total fee. If it shows a large TRX fee rather than energy consumption, your energy is short, and section 3 explains why.

If a line on that screen does not make sense to you, that is a reason to stop rather than to proceed. The signature is the last moment at which a mistake is still free to fix.

5. Step 4 — Read the receipt on TRONSCAN after you send

Once the transfer is signed, take the TxID from your wallet's history. It is a 64-character hash. Copy it, do not retype it, and do not accept a screenshot in its place. Paste it into TRONSCAN's search bar.

You will land on the transaction detail page. Read it in this order.

1. 1Status. It reads SUCCESS, FAILED or PENDING. Section 7 explains what each one means and what to do about it.
2. 2Block and timestamp. A real transfer sits inside a block. The timestamp is the chain's record of when it happened, which matters in a dispute.
3. 3Ignore the header To field for now. For a USDT transfer that field usually shows the USDT contract address, not your recipient. It is the single most misread field on the page.
4. 4Open the Token Transfer tab, or the event logs. This is where the real recipient lives: From, To, Amount, Token and Contract. The To here is the address that received your USDT.
5. 5Match the Contract against the real USDT contract on TRON: TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t. A token that wears the USDT name but carries a different contract is not USDT.
6. 6Read the amount here rather than from the raw event log. The log stores the amount as an integer in base units, so 100 USDT appears as 100000000. The Token Transfer tab shows the figure you recognise.
7. 7Read the fee section: Energy Usage, Energy Fee, Bandwidth and the total Fee. This is where you learn whether your own energy paid for the transfer, or whether TRX was burned.

One last thing about timing. TRON produces a block every 3 seconds. A block becomes solidified once 19 of the 27 active Super Representatives have built on top of it, which takes about 19 blocks, so roughly 57 seconds.

Until a transfer is inside a solidified block it can, in theory, be rolled back. Treat one minute as the point at which the record is final, and treat the moment before that as likely but not settled.

6. Step 5 — Confirm the recipient's balance changed

The receipt proves the transfer executed. The recipient's balance proves the money is with them. Paste the recipient's address into TRONSCAN's search bar and open the Tokens section. The USDT row shows the current balance, read from the chain.

This step settles arguments that a screenshot cannot. A balance figure on the account page is what the network says, not what an app says. If the recipient's wallet shows nothing while TRONSCAN shows the balance, the problem is the app. They need to refresh, or add the token contract to their wallet.

One distinction is worth keeping clear when the recipient is an exchange rather than a person. The chain record and their credited balance are two different things. TRON settles in about a minute, but an exchange decides for itself how many confirmations to wait for before it credits a deposit. A successful transfer that has not been credited is usually a policy wait, not a network problem. The TxID is the evidence their support team needs.

• TxID copied in full from the wallet, not retyped from a screenshot.
• Status reads SUCCESS.
• The Token Transfer record names the recipient you intended, character by character.
• The contract in that record is TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t.
• The amount matches the invoice, including decimals.
• The recipient's USDT balance on TRONSCAN reflects the change.
• The TxID is filed alongside the invoice or order, so the payment can be proved later without hunting for it.

7. What each TRONSCAN status means

Four results cover almost everything you will see, and the correct response differs for each.

A pending transfer has a deadline. A transaction expires 60 seconds after it is built. The clock starts from the latest block's timestamp, not your device's clock, and the node simply drops it after that.

The protocol allows that window to be configured up to 24 hours. The default most wallets and API nodes run with is 60 seconds. So a transfer still pending after a minute will not land. Because it was never included in a block, nothing was charged. Rebuild the transfer from scratch rather than re-broadcasting the old one. If you signed it long before broadcasting it, that delay is the likely cause.

A failed transfer is where the money quietly goes. TRON does not refuse the transaction at the door. It starts executing, runs until the work fails, then reverts. The energy consumed up to that point is charged, and the TRX is not refunded.

For a transfer that runs out of energy, that means the whole allocation: 65,000 units, which is 6.5 TRX at the 100-sun burn price. You pay, and nothing moves.

Two failure reasons cover most cases. OUT_OF_ENERGY means the call needed more energy and TRX than were available to it. REVERT means the contract's own check failed during execution, which for a transfer usually means the sender's token balance was not enough. Either way the fix is the same: correct the cause before resending, because a second identical attempt fails identically and charges you again.

8. When the status says SUCCESS and the money still went wrong

SUCCESS is the status people trust, and it is the one that hides the two worst outcomes.

The first is a valid transaction to the wrong address. A single wrong character still produces a perfectly well-formed transfer, and the network has no way to know it was a typo. It executes, it confirms, and it is permanent. Nothing on the page contradicts you.

The only defence is the check in step 1. The only way to catch it afterwards is to read the To field in the token transfer record. Compare that against what you meant to send, character by character. This is why the recipient check happens before signing and not after.

The second is the wrong token. Plenty of contracts copy the USDT name and symbol, and a wallet will display them the same way. The name proves nothing. Only the contract address settles it, and the one that matters is TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t. If the transfer record shows a different contract, you did not send USDT, and the recipient's USDT balance will not have changed.

The third case is a chain mismatch rather than a mistake on your side. USDT exists on many networks, and an ERC-20 transfer will never appear when you search its hash on a TRON explorer. If a counterparty insists they sent USDT and the TxID returns nothing at all, ask which network before assuming the hash is wrong. It is the one situation where 'not found' is the correct answer to a real event, just not a real event on this chain.

9. Print-and-use verification checklist

Disclaimer: This content is for informational purposes only and does not constitute financial, legal or security advice. No checklist or tool eliminates risk entirely; self-custody means you are responsible for your own keys.