What is a Tron indexer?

1. What is a Tron indexer?

A Tron indexer reads onchain data from the Tron network, blocks, transactions, and TVM event logs, and writes it into tables you can query with SQL, GraphQL, or REST. The job is the same as any blockchain indexer: turn an append-only log of blocks into something you can ask questions of, like "every USDT transfer to this address" or "throughput by contract type".

What makes Tron worth a dedicated page is that it sits between two worlds. At the contract level it is EVM-compatible, so most of an EVM indexer carries straight over. At the transaction and account level it is its own protocol, with typed transactions, a base58 address format, and a resource model that has no gas in it. A Tron indexer is the part that bridges those two: EVM-shaped decoding on top of a Tron-shaped envelope.

2. The Tron data model: typed transactions and TVM logs

Tron produces a block every 3 seconds, and the blocks are dense. Block 84,000,000 alone holds 455 transactions. The first thing that separates Tron from an EVM chain is that those transactions are typed. An Ethereum transaction is a generic envelope of value plus calldata; a Tron transaction declares what kind of operation it is. Here is the actual breakdown of that one block:

Two things stand out. First, a TRC-20 token transfer is not its own transaction type: it is a TriggerSmartContract call, the same way any contract interaction is, and the transfer itself surfaces as an event log inside it. Second, a large share of the block, 114 of 455 transactions here, is DelegateResourceContract and UnDelegateResourceContract: accounts lending and reclaiming staked energy and bandwidth. That resource traffic is a first-class part of Tron activity, and it has no equivalent on an EVM chain.

The event logs, by contrast, look exactly like Ethereum's. In that same block, 65 of the 69 TVM logs came from a single contract: USDT. Logs are where almost all application data lives, and they are the part that ports directly from EVM indexing.

3. TVM is EVM-compatible: the same event topics

On an EVM chain, a decoder identifies an event by its topic0, the keccak-256 hash of the event's canonical signature. Because the TVM runs the same bytecode and the same hashing, a TRC-20 Transfer produces the identical topic0 to an ERC-20 Transfer. Side by side, a real USDT transfer log from each chain:

The full hash is ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef on both. This is the single biggest thing that carries over: any ABI, any decoder, any "filter by topic0" logic you already have for ERC-20 reads TRC-20 unchanged. The dedicated comparison, TRC-20 vs ERC-20, walks the byte-level detail. For why one decoder spans many chains, see one query shape, every VM.

4. Where Tron diverges: the request type picks the schema

The logs are EVM-shaped, but the transaction is not, and the Portal makes that boundary explicit through the request type. A Tron query sends "type": "tron", which selects the Tron schema: typed transactions with type, feeLimit, energyUsageTotal, and netUsage fields. Ask for an EVM-only field and the request is rejected outright:

The reverse holds too: send "type": "evm" and request energyUsageTotal and you get the same rejection, because the EVM schema only knows gas, gasPrice, and friends. One more Tron-specific quirk catches people: a Tron log has no transactionHash field. The valid log fields are transactionIndex, logIndex, address, data, and topics. To attach a transfer to its transaction hash, you join the parent transaction by setting "transaction": true on the log filter and requesting fields.transaction.hash, the same join pattern EVM traces use.

5. A real query: TRC-20 USDT transfers

Putting it together: the USDT contract address goes in as 20-byte hex with no 0x prefix, the topic0 is the shared Transfer hash, and the response is newline-delimited JSON. This is the actual request, as a curl you can paste:

The first log that comes back, verbatim:

The data field decodes as a uint256, and USDT on Tron has 6 decimals, so 0x1312d000 is 320,000,000, a transfer of exactly 320 USDT. The two indexed topics are the sender and recipient: the 20-byte hex base58-encodes (with the 0x41 prefix) to TVnH…5EFY and TJLu…Pmyf, the T... addresses you would see on Tronscan. The contract address resolves the same way, to TR7N…Lj6t, the canonical USDT-TRON contract. Reading TRC-20 USDT end to end, including the resource model behind that transfer, is the subject of USDT on Tron.

6. Energy and bandwidth, not gas

Tron does not have gas. Execution is metered in two resources: bandwidth, consumed by transaction size and basic transfers, and energy, consumed by smart-contract execution. Accounts get them by staking TRX, and resources can be delegated, which is what those 114 delegate and undelegate transactions in the block were doing. In the data this shows up directly on the transaction. The parent transaction of the 320 USDT transfer above, 32675254…a750b6, comes back as:

The call burned 64,285 energy and 345 bandwidth, but every fee field is null: the resources were covered by the account's staked and delegated balance rather than paid in TRX. That is the mechanism behind the common observation that USDT transfers on Tron feel free. An indexer that only modeled gas would have nowhere to put any of this; the energy and bandwidth columns are Tron-native, and reading them is just another field selection in the same query.

7. Tron indexing tools in 2026

If you author your own indexer, the Squid SDK has a @subsquid/tron-processor package and the Pipes SDK has a Tron source, both TypeScript, both streaming Tron data into a database you control. TronGrid is the official node gateway for raw JSON-RPC and HTTP access if you want to run the fetching yourself.

The queries on this page used a fourth option: the SQD Portal, which serves the Tron dataset (tron-mainnet, real-time from genesis) as a keyless HTTP stream, no node and no indexer to run. The same request shape covers every other chain, which is the point of the next section.

8. Why this is harder elsewhere

Next: read a TRC-20 transfer end to end in USDT on Tron, compare the standards byte for byte in TRC-20 vs ERC-20, or see how many chains land together in multi-chain indexing.