USDT on Tron: querying the largest stablecoin rail

1. The largest USDT rail

Tether publishes the breakdown of USDT in circulation by network, and Tron carries more of it than any other chain, ahead of Ethereum (the live figures are on Tether's transparency page). For payments and remittance flows in particular, Tron is the default USDT rail, on low fees and 3-second blocks. That makes its transfer stream a primary dataset for anyone doing stablecoin analytics, payments reconciliation, or compliance monitoring.

One boundary up front, because it shapes everything below. This data is about transfers: which address sent USDT to which, and how much, per transaction. It is not an address balance. A balance is the running sum of every transfer in and out of an address across all history, a reconstruction you build on top of the transfer stream, not a value you read from one call. What follows traces movement, which is what most stablecoin monitoring actually needs. The cross-chain version of this is in stablecoin data.

2. TRC-20 USDT in one declarative query

Because USDT is a TRC-20 token and the TVM is EVM-compatible, a USDT transfer is an event log with the standard Transfer(address,address,uint256) signature. The request filters by two things: the USDT contract address (as 20-byte hex, no 0x prefix) and the Transfer topic0. This is the actual request, as a runnable curl:

The contract a614f8…ded13c is USDT (TR7N…Lj6t in base58). Across these two blocks the stream returns 102 transfer logs. The response is newline-delimited JSON, one block per line, with the matching logs attached; the Portal serves it keyless over HTTP, so the same curl runs from a terminal, a serverless function, or an agent tool call.

3. Reading a real transfer

The first log returned, verbatim from the stream:

Three topics and a data blob decode into a complete transfer. topics[0] is the Transfer signature. topics[1] and topics[2] are the indexed sender and recipient, each a 20-byte address left-padded to 32 bytes (take the last 40 hex characters). data is the amount as a uint256, and USDT uses 6 decimals, so 0x1312d000 = 320,000,000 = 320 USDT:

4. One contract, most of the block

USDT's share of Tron activity is easy to see if you drop the address filter and pull every event log in the block. In block 84,000,000, 65 of the 69 TVM logs came from the USDT contract alone:

That concentration is why a USDT-filtered query is so cheap to run and so useful: one contract accounts for the overwhelming majority of the chain's event traffic, and the Portal lets you address it by contract and topic without scanning everything else. Pin a wider window and the same shape gives you the full firehose, ordered, decodable, and ready to stream into a database with the Pipes SDK.

5. Why the transfer burned no TRX

The transfer above is more interesting one level down, on its transaction. Tron meters execution in two resources rather than gas: bandwidth (transaction size) and energy (contract execution), both obtained by staking TRX and both delegatable between accounts. Joining the parent transaction returns its resource usage:

The transfer consumed 64,285 energy and 345 bandwidth, yet every fee field is null. The resources were covered by the account's staked and delegated balance, so no TRX was burned. This is not an edge case: in the same block, 114 transactions were accounts delegating and reclaiming resources to keep exactly this working. It is the mechanism behind the everyday observation that USDT transfers on Tron are effectively free, and it is visible in the data on every transaction, not inferred. An indexer modeled only on gas has no column for any of it; energy and bandwidth are Tron-native fields.

6. Joining the log to its transaction

One Tron-specific detail makes that join necessary rather than optional: a Tron log has no transactionHash field. The valid log fields are transactionIndex, logIndex, address, data, and topics, and nothing else. To attach a transfer to its transaction hash and its resource usage, you ask the Portal to join the parent transaction:

Setting "transaction": true on the log filter pulls in the parent transaction; the fields.transaction selection then chooses what comes back with it. This is the same join pattern EVM traces use to recover their transaction hash, and it is the one piece of Tron plumbing that does not look like Ethereum.

7. Why this is harder elsewhere

For the protocol detail behind the transfer, see what is a Tron indexer and TRC-20 vs ERC-20. For cross-chain stablecoin flows and peg health, stablecoin data.