Tron AML: adding TRC-20 transaction monitoring and wallet screening

Tron settles a large share of the stablecoin volume that never touches an EVM chain. Ignoring it left a hole in every score we produced.

Why Tron AML coverage mattered

Our coverage started with EVM chains because they share an execution model: one ingestion path, one log format, one way to trace a token transfer. Solana broke that assumption and taught us to separate ingestion from scoring. Tron was the second test of that separation, and the first where the volume argument was overwhelming — a counterparty that looks clean on Ethereum can be funded entirely through TRC-20 flows we could not see.

The blind spot is worse than it first appears, because it is not random. Flows choose Tron for a reason: low fees and fast finality make it the default rail for high-frequency, lower-value stablecoin movement, particularly in corridors where the alternative is correspondent banking. That is a legitimate use case at enormous scale, and it is also exactly the profile that suits structuring. A monitoring stack blind to Tron is not missing a slice of volume at random; it is missing a slice weighted toward the behaviour it exists to detect.

What changed in TRC-20 ingestion

TRC-20 transfers are events on a contract, much like ERC-20, but the account model, the fee mechanics and the block cadence differ enough that the tracing logic could not be reused unchanged. Three things needed new code:

• resolving transfers through the energy and bandwidth model, so fee-payer relationships are not mistaken for ownership;
• normalising Tron addresses into the internal identifier space without colliding with EVM addresses;
• handling the faster block time in the graph builder, which previously assumed a slower, coarser clock.

The fee-payer trap

The first of those deserves elaboration, because it is the most common way Tron analytics goes quietly wrong. On Tron, resource costs can be delegated: one account can stake to cover another account's energy. A tracer that treats "paid the costs for this transfer" as evidence of common control will merge a service and all of its users into a single cluster. The result is not a small error — it is a cluster containing thousands of unrelated parties, and every risk signal computed over it is meaningless.

We treat delegation as its own edge type, weighted separately from value flow, and require independent corroboration before common control is inferred.

Address normalisation

Tron uses base58check addresses with a distinct prefix, and internally each also has a 21-byte hex form whose tail is indistinguishable from an EVM address. Normalising naively produces collisions where an Ethereum address and a Tron address occupy the same key — and then an Ethereum verdict gets served for a Tron transfer. Every identifier in our graph is namespaced by chain, which is also why any integrator caching our responses must key on (chain, address), never on the address alone.

What it means for a score

Two things improve. Cross-chain proximity is now measured across Tron as well, so an address funded from a flagged TRC-20 cluster carries that signal. And confidence rises for addresses that were previously thin on EVM history but active on Tron — the same address, more evidence, a narrower band.

The scoring model itself did not change. Only the graph it reads from got wider.

That is the payoff of separating ingestion from scoring. Adding a chain is a data-engineering exercise, not a model rewrite, and the meaning of a score stays stable across coverage expansions — which matters if you have thresholds tuned against it. The full picture of what the score represents is in what a wallet risk score measures.

Coverage is not parity

Some heuristics tuned on years of EVM history are younger on Tron, and the confidence band reflects that honestly rather than hiding it. We would rather return a wider band on a Tron-heavy address than imply a precision we have not earned.

This is the question worth putting to any analytics vendor, us included: not "do you cover chain X" but "what is your confidence distribution on chain X compared to Ethereum, and how long has it been in production". Claimed coverage is cheap. Ask to watch a live cross-chain trace resolve, as we argue in building a screening stack that holds.