What we learned detecting USDT payments on TRON (and the outage that left our scanner 5 days behind)

Symond — Sun, 15 Nov 2026 12:27:24 +0000

We run Disburz, a small service in India that lets people sell USDT and receive rupees in their bank account. The crypto side is simple on paper: a customer sends USDT on TRON (TRC20) to an address we give them, we see the transfer, and our payout partner sends INR by IMPS.

"We see the transfer" turned out to be the part worth writing about. Here's how our payment scanner works, the numbers that matter on TRON, and what broke when our database went away for five days.

The setup in one paragraph

Each order gets a deposit address from a pool. A scanner walks TRON blocks in order, picks out TRC20 Transfer events for the USDT contract, and matches the to address and amount against open orders. When a match is final, the order is marked paid, the funds are swept to a main wallet, and the payout is triggered. The scanner keeps a single cursor in the database: the last block it fully processed.

Numbers that matter on TRON

Block time is about 3 seconds. A scanner that falls behind by a day has roughly 28,800 blocks to catch up on.
Finality is about 19 blocks. TRON has 27 super representatives, and a block is treated as solidified once more than two thirds of them have built on top of it. In practice that's about 19 confirmations, or a little under a minute.
USDT transfers are just contract events. You're not watching native TRX transfers; you're decoding Transfer(from, to, value) logs from the USDT TRC20 contract, with 6 decimals.

We show customers a live "payment detected · x/19 confirmations" counter on the payment page. It's display only, but it removed a whole class of "did you get my money?" support tickets, because people can watch it count up.

Lesson 1: The cursor is the product

Everything hangs off one number: the last processed block. Two rules we'd give anyone building this:

Only advance the cursor after the block's effects are committed. Matching, marking orders paid and moving the cursor belong in one transaction. If the process dies halfway, you re-scan the block instead of skipping it.
Make re-scanning idempotent. Key each detected transfer by transaction hash plus log index. Seeing the same transfer twice must be a no-op, not a double payout.

Get those two right and most crashes become boring: restart, re-scan a few blocks, carry on.

Lesson 2: Orders should not expire while you're blind

Our orders have a payment window. Early on, a scanner that fell behind could have let a paid order expire simply because we hadn't looked at the block yet. The fix: expiry checks compare against the scanner's position, not the wall clock. If the scanner hasn't reached the block range covering the order's window, the order stays open.

This mattered a lot during the outage below. Customers who paid during it saw their order sit unpaid, but none of them were expired and asked to pay again.

Lesson 3: Rate limits bite hardest when you're already behind

We read blocks through a hosted TRON API with a per-key rate limit. During normal operation the scanner sits near the chain head, handles a block every few seconds, and never gets near the limit.

Then our database became unreachable for about five days. The scanner couldn't commit anything, so its cursor stopped. When the database came back, it was roughly 143,000 blocks behind, and it tried to catch up by fetching several blocks in parallel.

That's exactly when the provider's limit kicked in: too many requests per second, the key gets suspended for a short window, every call returns HTTP 429, retries pile on, and effective throughput collapses. We measured about 0.6 blocks per second while catching up. The chain itself adds a block every 3 seconds (0.33/s), so we were gaining only about 0.27 blocks per second: closing a 143,000-block gap would have taken around six days.

What we're changing, and what we'd recommend to anyone:

Parallelism should be a knob, and catch-up should use less of it, not more. A burst that trips the limiter is slower than a steady stream under it.
Respect the suspension window. When you get the "suspended for N seconds" response, sleep for N seconds instead of retrying immediately.
Have a second RPC endpoint for catch-up, so one key's limit isn't your ceiling.

Lesson 4: Sometimes you jump the cursor, but you verify the gap

Catching up 143k blocks at that speed would have taken days, and meanwhile real customers who had just paid were waiting. So we did something that sounds scary: we moved the cursor forward to near the chain head, then separately verified the skipped range.

For the verification we didn't replay blocks. We queried the transfer history of every address that could have received a payment (all pool addresses and the main wallet) for the skipped time window, using the API's account-transactions endpoint. That's a few hundred calls instead of 143,000 block fetches. The window came back with zero relevant transfers, so nothing was missed, and the one order that had been paid after the outage was picked up within minutes of the jump.

The rule we follow now: a cursor jump is only allowed together with an account-level check of the skipped window, written down in the incident log.

Lesson 5: Watch the scanner, not just the API

Our health checks were green during the outage in the sense that the web app was up. What we actually needed was an alert on scanner lag: chain head minus cursor. If that number grows for more than a few minutes, something is wrong, whether it's the database, the RPC provider or the scanner process itself. That alert is what we're adding, and in the meantime an order that's paid on chain but still shows unpaid is checked against the scanner position first.

What this means for people sending USDT

A few things we tell customers, which fall straight out of the above:

Network matters. A TRC20 address starts with T. USDT sent on another network to that address isn't something the scanner will ever see.
About a minute after you send, the transfer is final on TRON. If your wallet shows it confirmed and the service doesn't, ask them to check their scanner, not to "resend".
Keep the transaction hash. It's the one reference both sides can look up.

If you're building on TRON and want to compare notes on scanners, sweeping or rate limits, I'm happy to talk in the comments. And if you're in India and want to see the flow from the user's side, the live quote is on disburz.money.

DEV Community: Symond