Open tronscan.org and paste the transaction hash (TxID) into the search box — a string of 64 characters with no “0x” at the start, which your wallet or the sending service will show you. On the transfer page, read two fields separately: Result — whether the transfer was carried out, and Status — whether the block is locked in for good. Do not confuse them: they do not match.
Result: Successful means the money has gone, even if Status is still UNCONFIRMED: the block will be locked in within about a minute — by the measurement of 19.09.2026 the lag was 57 seconds. A Result that starts with Failed means the transfer did not happen, even if Status already reads CONFIRMED: that status confirms not the transfer but the fact of the failure itself. The most reliable sign of a failure is that the page has no Token Transfers block at all.
If it says Result: Successful, there is nothing to worry about: for an everyday transfer that is already enough. Status: CONFIRMED is what people wait for when they are receiving a large sum. And if the hash is not there at all, there are six possible reasons, three of them common: they are searching for the wrong string, the transaction expired, or the wallet never broadcast it. All of them are broken down below.
Result and Status: two different fields on one card
These fields answer different questions. Result — whether the transfer was carried out, whether the money went or not. Status — whether the block is locked in irreversibly, whether the transfer can already be treated as final. They change independently of each other, which is why someone looking at the wrong field draws exactly the opposite conclusion.
A successful transfer of 500 USDT, captured from tronscan.org on 19.09.2026, hash d0f09014…57af4. The card shows Result: Successful and at the same time Status: UNCONFIRMED Confirmed by 16 blocks, and a line below Confirmed SRs: 16: the transfer has already gone through, but the block is not locked in yet — the 19 Super Representatives required have not come together. Nothing has to be done; Status will change by itself within a minute.
A failed attempt to transfer 10,000 USDT, the same day, hash 0ae7fce9…4a8d. Here it is the other way round: Result: Failed - Out of Energy, and next to it Status: CONFIRMED Confirmed by 37 blocks and Confirmed SRs: 19 — the same 19 out of 27. The word “confirmed” means the network has locked in the failure for good, not that the money arrived.
A failure can be told by three signs, in order of reliability:
- there is no
Token Transfersblock on the page at all. A token is either transferred or it is not, there is no state in between; at the bottom Tronscan addsNo new txn found by sender; - the reason is stated right in the
Resultfield — in the example above that isFailed - Out of Energy; - the note
(Failed)in the header, right after the amount and the recipient's address.
A trap of its own is the line Amount: 0 TRX on the card of a successful transfer. The zero is there because transferring a TRC20 token is a contract call, not a movement of the network's own coin. The token amount is shown higher up, in the Token Transfers block, and the Method Calling field reads transfer(address _to, uint256 _value).
How likely a failure is in the first place. On 19.09.2026 we scanned 30 consecutive blocks — 13,805 transactions, about 90 seconds of network time. The breakdown by the node field that Tronscan takes the Result label from:
value in the network | label on the page | share, measurement of 19.09.2026 |
|---|---|---|
|
| 99.71% |
|
| 0.28% |
| we have no live capture of a card with this exact label | 0.01% |
Three cases in a thousand is the share of failures among all the transactions in that slice, not the probability for one particular “stuck” transfer: the second of those we did not measure, and one cannot stand in for the other. A failure on TRON is rare, but “rarely” does not mean “never”, so the Result field is one you always look at.
These are three values actually encountered in the measurement of 19.09.2026, not a full list of the possible ones: we found no consolidated list in the TRON documentation.
OUT_OF_ENERGY means the sender had neither staked energy nor TRX to pay for it. REVERT means the contract itself refused to carry the transfer out: for USDT that usually means a balance smaller than the amount being sent, or an address on the issuer's blacklist.
The main thing for anyone who sees Failed - Out of Energy on the screen: the money has stayed with you. The receipt for that attempt on 19.09.2026 shows only 345 Bandwidth spent and no TRX burned — there was no energy on the account, so there was nothing to burn either. The USDT is where it was, and the transfer can be repeated once you top up with TRX.
This is where TRON differs from Ethereum, where a failed transfer debits a fee for the work done all the same. But the rule is not a general one: with REVERT the contract does get to run before it refuses, and that transaction burned 8,624 energy.
How long to wait, and why confirmations here are not blocks
The line Confirmed SRs on the card is not a block counter, and that is the first thing that throws people. On TRON, blocks are produced in turn by 27 Super Representatives, and a block becomes irreversible once at least 19 different active Super Representatives have worked at its height or above. That is how the TRON developer documentation describes it.
The measurement of 19.09.2026 shows what that is in real life: the locked-in block was exactly 19 blocks behind the current one, that is 57 seconds, and the average block length over 1,000 consecutive blocks came out at 3.006 seconds. Hence the whole picture of the timing: Result appears in the very first block, within three seconds, while Status turns CONFIRMED about a minute later.
Not everyone has to wait out that minute. It is waited out by people receiving a large sum who want irreversibility; for an everyday transfer Result: Successful is enough — the money has already gone.
If more than five minutes have passed and Status is still UNCONFIRMED, the speed of the network is no longer the issue — see the next section. How the counting of confirmations on a blockchain is arranged in general, and why it differs from network to network, is covered separately: transaction confirmations on the blockchain.
Why the transfer is not in Tronscan at all
An empty page for a hash is not the explorer breaking down, and not “it is lagging behind”. Tronscan shows a block within seconds of its release: if the transfer is not there after a minute, it is not in the network either. The reasons, from the most common to the rarest:
- They are searching for the wrong hash. The hash of a transfer and the “order number” in a wallet or a service are different strings. A hash on TRON is exactly 64 hexadecimal characters with no
0xat the start. A string that is shorter, longer, or has letters beyond f is not it. One that begins with0xis an Ethereum or BNB Chain hash, and it is read by different rules: how to read a transaction page on Etherscan. - The transaction expired. According to the TRON documentation, a transaction has a hard lifetime, 60 seconds by default from the time of the latest block; if it does not make it into a block, the nodes throw it out. The hash exists, but there is no transaction behind it.
- The transaction was never broadcast. The wallet signed it locally but did not send it to the network: no connection, or the node refused. The sign is that the hash is in the wallet's history while the explorer is empty.
- The recipient's address has not been activated. The TRON documentation says it outright: until it is activated, an address cannot be found either through the API or through an explorer. A person opens their new address, sees emptiness and decides the address does not exist.
- The transfer went to a different network. An address of the form
T…is almost impossible to mistake for another network's, but if the transfer really was going to Ethereum or BNB Chain, it is not in Tronscan by definition: those networks have their own explorers — Etherscan and BscScan — and the hash has to be looked up there. - A test network is open. Tronscan has a
Switch network (current: Mainnet)switch and separate addresses for the test networks. A transfer from the main network is not visible on a test one.
The difference from Ethereum is fundamental here: there an unexecuted transfer hangs in the queue for hours and days, while on TRON, within a minute, the transaction is either in a block or thrown out. What to do if the money went to the wrong network is covered separately — sent crypto to the wrong network.
Wallet address or USDT contract address — how not to mix them up
By sight they cannot be told apart: the TRON documentation says outright that the addresses of contracts and of ordinary accounts are written the same way — 34 characters, both starting with T. There is no marking in the string itself, and that is exactly why both of the mistakes below happen regularly.
The USDT contract address on the TRON network is the same one for everybody: TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t. A direct call to the contract on 19.09.2026 showed an issue of 94,258,350,557 USDT, and on a transfer card Tronscan labels this address as USDT Token. On any USDT TRC20 transfer the Contract Address field will be exactly this.
Hence the rule for reading the card: Owner Address is the sender's wallet, Contract Address is the USDT contract itself, the same for everyone. The page address in the browser helps too: a wallet opens as /address/…/transactions, a token as /token20/…/transfers, a program as /contract/…/code.
The first mistake costs money: sending USDT to the address of the contract itself. The network will carry such a transfer out; formally the address is correct. The coins cannot be brought back — the contract has no owner who could get them out of there.
The second mistake costs nerves: looking for your own transfer by the contract address. A person copies the “token contract” string out of their wallet instead of their own address, lands on the token page with millions of other people's transfers, and decides the explorer is showing someone else's money.
Who makes Tronscan and what to expect from it
Tronscan is the first and main explorer of the TRON network, built into its infrastructure: the TRON developer documentation calls it the basic on-chain data infrastructure of the network and the most used explorer on TRON.
What you cannot do, though, is call it the official explorer of the TRON foundation. We looked on 19.09.2026 and found no statement of legal ownership either on tronscan.org or in the TRON documentation. The word “official” does not occur on the site itself at all — what does occur is “first” and “best”.
There is one practical conclusion: the explorer decides nothing. It reads the blockchain and shows what it has read. It will not speed a transfer up, will not cancel it and will not give the money back. Writing to the explorer's support to have “the USDT returned” is pointless: it has neither access to other people's wallets nor a cancel button.
Searching by hash and by address works without signing in. The Connect Wallet button is there for private notes and labels; to look at your own transfer there is no need to connect a wallet.
A danger particular to this topic is look-alike domains. A check of the search results for the word “tronscan” on 19.09.2026: alongside the real address sit sites that put the word Official in the page title. We did not record any theft from those sites as such, but the mechanism is dangerous in itself — tomorrow that same address could be holding a form for entering a private key.
The rule is simple: type the explorer's address by hand or keep it in your bookmarks, rather than following the first link out of a search. An explorer never needs a private key or a recovery phrase — it only reads public data.
Once the transfer has been checked and Result: Successful is in place, everything further depends on what you do with the USDT. If the next step is an exchange, we have a separate direction for USDT on the TRON network: the address for the transfer is issued with the network stated explicitly, and you check the hash the very same way.
Short answers
How long does a transfer on TRON take to confirm?
About a minute. Measurement of 19.09.2026: the locked-in block was 19 blocks behind the current one, which is 57 seconds. But Result: Successful appears straight away, in that same block, and for an everyday transfer that is enough. Waiting for Status: CONFIRMED makes sense when a large sum is being received.
The page says CONFIRMED but the money has not arrived — why?
Because Status is about the block, not about the transfer. Look at the Result field: Failed - Out of Energy together with CONFIRMED means the network has locked the failure in for good. The money, meanwhile, stayed with the sender — in the measurement of 19.09.2026 an attempt like that spent only 345 Bandwidth. Check the Token Transfers block as well: a failure does not have one.
Why is the Amount field zero when I sent USDT?
That is exactly how it should be. USDT on TRON is an entry inside a contract, not a coin of the network itself, which is why the coin amount field shows Amount: 0 TRX. The token transfer is accounted for separately, in the Token Transfers block: in the capture of 19.09.2026 it stood there as the counter Token Transfers: 1. If that block is not there at all, the token did not go.
Tronscan cannot find my hash — has the money vanished?
Most likely not. Most often people are searching for the wrong string: a hash on TRON is 64 hexadecimal characters with no 0x, not a service's order number. The second most common case is a transaction that expired and was thrown out by the nodes — according to the TRON documentation that happens after 60 seconds by default.
If the transaction expired or was never broadcast, it did not make it into any block and the money has stayed with the sender. And if the wrong string is being searched for, the transfer may well have gone through: take the TxID field out of your wallet and check that one.
