Fixture data
Public demo · the reference case
A recorded snapshot of a real TRON USDT theft. We kept it as our reference case precisely because its conclusion is negative: the on-chain evidence did not support the accusation.
Case parameters
- Case id
- ELAB-GINO-TRON-20260720
- Chain
- TRON · USDT
- Amount stolen
- 45,473USDT (raw integer
45473000000) - Incident
- 2026-07-20T11:40:06Z
- Snapshot as_of
- 2026-07-21T05:10:00Z
- Victim address
- TYJftR…qSKkSeed address
- Thief wallet
- TUX5GD…HYn5Seed address
- Accused suspect addresses
- 7 addresses
- Incident transaction
- 94abac9c76fc462862f2bbc25b1de824df23ad48c2c9ea324f91f79f4e021a93
- Traversal limits
- max_depth 30 · max_nodes 5000 (theft) / 1000 (others) · hub threshold 250 · min expand value 1.0
The anchor is validated first
Before any analysis runs, the incident transaction itself is verified: txid, sender, recipient, asset, amount, and a receipt status of SUCCESS. If it does not verify, the case fails and no analysis is produced at all.
The false-positive funnel
This single table is the entire justification for our two-graph doctrine. On the left is what a naive implementation reports. On the right is what each stage removed.
Raw reachability overlap248
What was applied: Naive: «addresses reachable from both the thief and the suspect network»
This is the «we found 248 links» number. It is not wrong; it simply does not answer a question. Reachable is not flow, and flow is not the same person.
After FP1 victim-bridge suppression6
What was applied: Add the victim and the thief to blocked: reachable, but never expanded through
The suspects had funded the victim before the theft. So on the reachability graph the entire thief downstream hangs underneath the suspect downstream — purely because the victim address itself acts as a bridge. Remove that bridge and 248 becomes 6.
After the FP3 value-assets-only closure1
What was applied: Recompute the closure over USDT edges only, excluding TRX and gas
Three of the remaining 6 were connected exclusively by TRX gas edges. Their usdt_out is zero, meaning no value ever moved through them at all. Those three addresses are the most important lesson in this case; they are listed separately below.
Non-hub survivors0
What was applied: The single survivor is a high-degree shared service
The last remaining link is the deposit address of an automated swap service with roughly 27.46 million lifetime transactions. Both sides touching it means as much as two people having used the same convenience store. Flagged shared_service, downgraded to weak. Not a link.
The three addresses FP3 caught
Read the high_degree column. These three do not look like exchanges or shared services — they look like ordinary private wallets connecting the thief to the suspect network at depth 2 to 3. That is the single most incriminating shape an analyst can see.
| Address | Thief depth | Suspect depth | High degree | USDT out |
|---|---|---|---|---|
| TVdSuB…eWad | 3 | 2 | no | 0USDT |
| TMXZAy…jjTc | 3 | 2 | no | 0USDT |
| TTn5QH…qrZX | 4 | 3 | no | 0USDT |
And every one of them is an artifact of following gas top-ups from a shared energy-rental service as if they were value flow. usdt_out = 0 is the tell: no value ever flowed through them at all.
Without FP3, this product accuses three innocent wallets.
The single survivor
Depth 1 from both sides. It looks exactly like a pivotal node. It is the deposit address of an automated USDT→TRX swap service.
TDii6vao7xyWg2rKPbCPWVRpSmne8xcqYxHub / service address
False-positive checks1 flagged
These flags mean a finding has a known, ordinary alternative explanation. A flag never hides the finding — it downgrades it and says why.
Shared service
Both sides simply used the same exchange or gas service.
This intersection address has a very high counterparty count or public transaction total: it is shared infrastructure — an exchange hot wallet, a deposit address, an energy-rental service. Two unrelated people using the same exchange is ordinary life, not a relationship.
The finding has already been downgraded to weak. To go further you need something sharper: whether it is a deposit address assigned to one specific customer, whether there is a fixed-amount operational fingerprint, and how large the service's public transaction count is — the larger it is, the less the coincidence is worth.
The correct handling: flag shared_service, downgrade to weak, put it in the report and explain it — neither hidden, nor presented as a link.
Taint trace
Starting from the thief wallet, propagating downstream only along USDT edges that are causally possible in time.
Within this snapshot the stolen funds never reached an exchange, and never flowed back to the victim or into the suspect network.
Gas-funder analysis
Who paid the thief's transaction fees? This is usually the shortest path to a human being.
It is the payout leg of that same automated swap service, with roughly 9.65 million transactions, and it is not in the suspect network. The correct behaviour is to surface it as the highest-value off-chain lead — subpoena the service operator — while flagging it shared_service so it is never presented as attribution.
Money conservation
Computed entirely on integers. This section doubles as our public demonstration of the no-floats rule.
- Victim balance (before → after)
- 45,473.11USDT → 0.11USDT
- Amount stolen
- 45,473USDT
- Thief first-hop outflow
- 45,472.77099USDT
- Residual left at the thief
- 0.22901USDT
- Conservation
- 99.999496 %
- Parked, not cashed out
- ≈ 45,454USDT across 3 wallets (recorded as an approximate figure in the source artifact)
- Last inbound to drained
- 1 h 15 m 21 s Consistent with somebody watching the balance.
Why we do not use floating point
In the same reference material, one address carries a usdt_out value of 2.315841784746324e+71. That is not a possible USDT amount. It is a uint256-scale raw value that was summed as a Python float and leaked into a delivered forensic artifact.
TZ5VUw…k7Kw usdt_out = 2.315841784746324e+71
This is why amounts are integers end to end, strings in JSON, and converted only at the display edge. The failure is not hypothetical; we caught it in our own source material.
False-positive detectors triggered by this case
Each of the five detectors corresponds to a real bug that produced a real false accusation before it was caught. They are shown, downgraded and explained — never hidden.
False-positive checks3 flagged
These flags mean a finding has a known, ordinary alternative explanation. A flag never hides the finding — it downgrades it and says why.
Victim bridge
This link only exists because the path runs through the victim.
The suspect once sent funds to the victim, and the victim was later robbed. That makes the thief's entire downstream hang underneath the suspect's downstream automatically. But the thing joining the two sides is the stolen wallet itself, not the suspect — this link is arithmetically guaranteed and means nothing.
Re-run with the victim and thief marked reachable-but-never-traversed-through, or rebuild the suspect's graph with a cut-off before the incident. If the link disappears, the bridge was all it ever was.
Gas / dust link only
The two sides meet only on fee-payment or dust edges, never on value.
Almost every TRX transfer on TRON is an energy or bandwidth top-up from one of a handful of shared rental services, and address-poisoning dust behaves the same way. Following those edges as if they were money flow manufactures overlaps out of nothing. In our reference case, restricting conclusions to value assets collapsed the independent overlaps from six to one — and the survivor was still a shared deposit service.
This link does not exist on the value graph, so it cannot support a conclusion. To claim a relationship you must find a path over value-asset edges.
Shared service
Both sides simply used the same exchange or gas service.
This intersection address has a very high counterparty count or public transaction total: it is shared infrastructure — an exchange hot wallet, a deposit address, an energy-rental service. Two unrelated people using the same exchange is ordinary life, not a relationship.
The finding has already been downgraded to weak. To go further you need something sharper: whether it is a deposit address assigned to one specific customer, whether there is a fixed-amount operational fingerprint, and how large the service's public transaction count is — the larger it is, the less the coincidence is worth.
Boundaries
Where the traversal stopped, and why. An empty result with a full boundary ledger is a finding; an empty result with no explanation is a bug report.
max_depth 30 · max_nodes 5000 (theft) / 1000 (others) · hub threshold 250 · min expand value 1.0 · max_depth 30
Conclusion
No link found
Within the limits set for this run, the value graph contains no path that would support a link. That is a definite result, not a failed query.
What we checked: TRON · USDT · max_depth 30 · as_of 2026-07-21T05:10:00Z
The on-chain evidence does not support the accusation.
Within this snapshot, not one substantive link between the accused addresses and the stolen funds survives. Every apparent link is attributable to the victim address acting as a bridge, to a shared energy-rental service, or to gas top-ups.
This conclusion produces a full report, to the same standard as a positive one: the boundary ledger (where we stopped and why), every downgraded apparent link with its reason, and a «what chain data cannot tell you» section.