How Long Does a USDT TRC-20 Transfer Take? Each Stage Measured
A USDT TRC-20 transfer reaches a block in seconds and is final in about a minute. Each stage timed on 340 real transfers, plus what to do if yours is late.
- Category
- Guides
- Published
- Reading time
- 8 min

A USDT TRC-20 transfer normally reaches a block within a few seconds of signing and becomes irreversible about one minute later. In 340 real transfers we read from the chain on Nov 2, 2026, the median time from building the transaction to its block was 4.1 seconds, and the irreversible (solidified) block trailed the newest one by 18 to 19 blocks, roughly 54 to 57 seconds. When the recipient sees the money depends on their own rules.
The whole path at a glance
| Stage | What happens | How long | Measured Nov 2, 2026 |
|---|---|---|---|
| 1. Build and sign | The wallet creates the transaction with a time and an expiry, you confirm | Up to you | Not visible from outside |
| 2. Broadcast, wait for a block | A node checks and relays it; a Super Representative includes it | A block every 3 seconds | Median 4.1 s from build to block, 98% under 60 s |
| 3. Become irreversible | 19 of the 27 producers produce a block at that height or above | About 1 minute (documentation) | 18-19 blocks, 54-57 s |
| 4. Credit by the recipient | The receiving wallet or service applies its own rules | Seconds or longer | Set by each service |
Stages 1 and 2: from pressing send to a block
The wallet builds a transaction with two time fields in raw_data, described in the TRON transaction documentation:
timestamp: the wall-clock time at which the unsigned transaction was built;expiration: the moment after which nodes drop the transaction instead of including it. By default it is the head block’s time plus 60 seconds, and the maximum is 24 hours. java-tron hard-codes both values asTRANSACTION_DEFAULT_EXPIRATION_TIMEandMAXIMUM_TIME_UNTIL_EXPIRATIONin Constant.java.
Once you sign, a node validates the transaction and relays it to the producers. Blocks come in fixed slots: Parameter.java sets BLOCK_PRODUCED_INTERVAL = 3000 milliseconds and MAX_ACTIVE_WITNESS_NUM = 27. In our sample no slot was skipped: blocks 87,640,712 to 87,640,725 took exactly 39 seconds, 13 blocks.
Our measurement: build-to-block time
On Nov 2, 2026, 05:00:27 to 05:01:06 UTC, we pulled four fresh blocks from TronGrid with wallet/getnowblock. They held 340 USDT transfers, all with the result SUCCESS. For the 333 that carried a timestamp, we subtracted it from the block time:
- 105 transfers (32%) were in a block within 3 seconds of being built;
- 196 (59%) within 6 seconds, 229 (69%) within 10 seconds;
- 326 (98%) within 60 seconds; the slowest took 103.4 seconds;
- the median was 4.1 seconds.
The timestamp is set by the sender’s software and not verified by the network, so these are close estimates. They also include signing time, which explains the long tail.
Three of these transfers, checked again afterwards through walletsolidity/gettransactioninfobyid:
| Transfer | Amount | Built (UTC) | In block (UTC) | Gap | Lifetime set |
|---|---|---|---|---|---|
| 9a449e3f… | 507.36 USDT | 05:00:26.5 | 05:00:27 | 0.5 s | 57.5 s |
| dbc0edc7… | 172 USDT | 05:00:13.3 | 05:00:27 | 13.7 s | 58.7 s |
| aa19d540… | 5,000 USDT | 04:58:58.6 | 05:00:42 | 103.4 s | 24 hours |
With the default 60-second lifetime the third transfer would have been dropped; its sender had chosen the 24-hour maximum.
Stage 3: when the transfer becomes irreversible
A block on TRON is final once it is solidified. The rule is explained in our guide to tracking a transaction on TronScan, together with an 18-block reading from Oct 19, 2026. In the code the threshold is SOLIDIFIED_THRESHOLD = 70, that is 70% of the 27 producers.
We repeated the check on Nov 2, 2026 in two ways:
- Two endpoints side by side. Three times between 05:00:37 and 05:01:05 UTC we called
walletsolidity/getnowblock, with awallet/getnowblockcall about 7 seconds before and after each. The solidified block came back as 87,640,695, then 87,640,700, then 87,640,704. Each was 57 to 58 seconds older than the newest block at that moment, about 19 blocks. - One node, one call.
wallet/getnodeinfoat 05:02:53 UTC reported head block 87,640,760 and solidified block 87,640,742; at 05:04:32 UTC, 87,640,793 and 87,640,775. Both times 18 blocks, 54 seconds.
The extra block most likely comes from the method: separate calls can hit different nodes behind one API. Either way, plan on about a minute.
Stage 4: when the recipient sees the money
A personal wallet may show an incoming transfer before the block is final; this depends on the app. Services that credit balances are slower. The consensus documentation tells exchanges, bridges and anyone settling large amounts to read from the solidity endpoint, so a service that follows this advice does not see your deposit until it is irreversible. Each service can also add its own crediting rules on top. So “SUCCESS on TronScan, nothing on my account” for a minute or two is normal.

Why a transfer hangs or never arrives
It never left the wallet
If a node rejected it at broadcast, TronScan finds nothing by the hash and the USDT never left your address.
It expired before reaching a block
A transaction that misses its expiration is dropped for good. Here is how long senders let their transfers live in our Nov 2 sample (expiration minus timestamp, 333 transfers):
| Lifetime set by the sender | Transfers | Share |
|---|---|---|
| About 1 minute, the default | 133 | 40% |
| 1 to 3 minutes, mostly 2 | 52 | 16% |
| Exactly 5 minutes | 47 | 14% |
| 5 to 60 minutes | 22 | 7% |
| Over 1 hour, up to the 24-hour cap | 79 | 24% |
Shares are rounded. So if your wallet uses the default lifetime, nothing on chain a minute after sending means the transaction is not coming and the USDT is still yours. With a longer lifetime it can still land, but never after its expiration.
It failed
A FAILED transaction is in a block and costs TRX but moves no USDT. The usual cause is missing energy or TRX, see the OUT OF ENERGY error guide and how much TRX you need to send USDT. As of Nov 2, 2026 a standard transfer without energy burns about 6.43 TRX for energy and 0.345 TRX for bandwidth once the free daily allowance is spent. Renting 65,000 energy at the current rate on Nov 12, 2026 costs 1.69 TRX; the exact price is shown in the app before you pay, and reference prices are on the pricing page.
It went over another network
If the sender picked Ethereum or BNB Smart Chain, the transfer is there and will never reach your TRON address. Look the hash up on etherscan.io or bscscan.com.

What to do if the transfer is late
- Get the hash from your wallet. No hash, or an error at the moment of sending, means the transaction did not go out.
- Search it on tronscan.org. Nothing there after a minute means it has not reached a block: it was dropped or, with a long lifetime, is still waiting. Check that your USDT balance has not changed.
- Before resending, make sure the first copy cannot land. If your wallet still shows the transfer as pending, wait until that status changes. A copy with a long lifetime, like the 24-hour one above, can still arrive, and you would pay twice.
- FAILED: the USDT stayed with you. Add energy or TRX, then send again.
- SUCCESS, block not yet confirmed: wait about a minute.
- SUCCESS and confirmed, still no credit: check the recipient address, the token contract
TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6tand the network, then send the hash to the recipient’s support.
How to put energy on your address before the next transfer is shown in the guides.
FAQ
How long does a USDT TRC-20 transfer take? Seconds to reach a block and about a minute to become irreversible. We measured a 4.1-second median and an 18-19 block gap on Nov 2, 2026.
Does the amount affect the speed? No. The time depends on when the transaction is signed and broadcast, not on the sum.
Why does my wallet show the transfer while the service I paid does not? Services usually credit only after the block is solidified, about a minute later, and some wait longer under their own rules.
Can a transfer be stuck for hours and then arrive? Only if the sender set a long lifetime, and never past 24 hours. With the usual one-minute default, a transfer either lands in a block quickly or is dropped.