How TRONORIGIN works

The pipeline

Every analysis follows the same sequence: collect on-chain data, identify candidate addresses, score each candidate on the origin question, determine current control from permission evidence, detect whether control has changed hands, and generate a plain-language explanation of the result.

1. Data collection — Transaction history, resource delegations, permission keys, and token transfers are fetched from public TRON data sources (TRONscan, TronGrid). Standard analysis covers up to 30 inbound transactions; deep scan covers up to 200.
2. Candidate identification — Every unique address that has sent funds or resources to the target becomes a candidate. Exchange hot wallets, DEX routers, and known infrastructure are classified and handled accordingly.
3. Origin scoring — Each candidate is scored on the origin question — who funded and activated this wallet — from activation-window and funding-history evidence. Scores are normalized into relative origin shares and converted to a confidence band (Low / Medium / High).
4. Control determination — Current control — who can sign for the wallet now — is read directly from on-chain permission evidence: the account’s owner keys and its permission-change history. This is a rule-based finding, not a score. Only when no key evidence exists does the analysis fall back to behavioral signals, clearly labeled as lower confidence.
5. Takeover detection — If the genesis-era leader and the recent-activity leader are different addresses and the divergence is significant, the result is flagged and classified.
6. AI summary — The structured scoring result is passed to an AI model, which generates a plain-language explanation of the finding and any alerts. The AI reads from the result; it does not alter it.

Two questions, two axes

“Who is behind this wallet” is really two separate questions, and the answers can disagree. Origin asks who funded and activated the wallet — a historical question, answered by scoring activation-window and funding-history evidence and expressed as relative origin shares. Current control asks who can sign for it now — a present-tense question, answered rule-first from on-chain permission evidence rather than from a score. Keeping the two axes separate lets the tool surface disagreement between them instead of silently averaging it away.

When the activation-window evidence and the longer-term funding history corroborate the same candidate, origin confidence rises — with one caveat: on very young accounts the two windows largely overlap, so that agreement is discounted rather than double-counted. When the origin evidence and recent activity point to different addresses and the divergence is large enough, takeover detection fires — the wallet may have changed hands, been sold, or been compromised since it was created.

What the heuristic looks at

The analysis draws on a set of specific on-chain signals. Some are origin evidence and feed the origin shares; others are control evidence and inform the controller finding and its behavioral fallback rather than the origin percentages. What follows is a summary-level list.

• Strongest Permission keys — The account’s owner and active permission keys, and the history of changes to them, are the most direct on-chain evidence of who can sign for the wallet. The controller finding is read from this evidence as a rule, not inferred from a score.
• Strong Resource delegation — If a candidate has delegated Energy or Bandwidth to the target wallet, that is one of the clearest behavioral indications of an operational relationship — exchanges never delegate resources to individual users; only personal wallets do this. Delegation is control evidence first; it also strengthens the candidate’s funding-history record on the origin side.
• Strong Return flows — When the target sends funds back to a candidate, it is a strong indicator of an owner-operator relationship. The bonus decays with time: a same-day return is weighted more heavily than one that occurs months later.
• Strong Sponsored energy use — When the target demonstrably runs its transactions on energy a candidate has delegated, the sponsorship is functional rather than dormant — corroborating evidence that strengthens an active delegation.
• Strongest Explicit account creation — A candidate whose transaction created the account on-chain (AccountCreateContract) has definitive, irrefutable genesis credit — the strongest single piece of origin evidence.
• Moderate First sender — The chronologically first funder is statistically likely to be the origin, though this bonus is suppressed when address-poisoning signals are present.
• Moderate Repeated interactions — Multiple inbound transactions from the same candidate suggest an ongoing relationship. The bonus is logarithmically capped to prevent spam from gaming the score.
• Moderate Contract consistency — If the candidate has interacted with the same smart contract as the target’s first outbound transaction, they are likely operating together.
• Contextual Address category — Personal wallets score higher than exchanges; exchanges are neutral; faucets, bridges, and mass-funder addresses are penalized. DEX router addresses are excluded from candidate scoring entirely.
• Contextual Transfer amount — Very small (“dust”) transfers are penalized. Normal and large transfers receive positive weight. Micro-dust and zero-value transfers are treated as potential address-poisoning signals.
• Penalty Poisoning indicators — Lookalike addresses (within a small edit distance of the target), zero-value transfers, and micro-dust bursts receive direct score penalties and may reduce the global confidence band.

The AI summary

After the heuristic produces a structured result — ranked candidates, confidence band, behavioral tags, takeover flags — that result is passed to an AI model (the Anthropic Claude API), which generates a plain-language explanation for the investigator.

The AI summary does not change the result. It reads from the scoring output; it cannot override scores, confidence bands, or takeover classifications. If the underlying data is ambiguous or contradicted by competing signals, the summary will say so. That hedging is intentional — it reflects genuine uncertainty in the on-chain record, not a limitation of the language model.

Takeover detection

Takeover detection compares two scoring windows: a genesis window (roughly the first 30 days or first 10 transactions) and an operational window (approximately the last 180 days). If the leading candidate in each window is a different address and the divergence ratio is large enough, the result is flagged as a potential change of control and classified into one of five types:

• Sale — The genesis funder was an exchange or custodian, and a different address now dominates recent activity. Consistent with a wallet sold or transferred to a new user.
• Compromise — Early and recent control are held by different parties with no obvious custodial or commercial explanation. The most concerning classification; warrants further investigation.
• Secondary wallet — The divergence pattern is consistent with the same owner moving to a different operational address — a common practice for operational security or account rotation.
• DAO transition — Keys appear to have been transferred to a new governance entity or multisig structure, consistent with a protocol handoff rather than a sale or compromise.
• Hostile takeover — Long dormancy followed by new key activity with no continuity of relationship — the strongest signal that the original owner lost control against their will.

What this tool does not decide

TRONORIGIN reports its confidence level and explains the on-chain signals behind each result. It does not make the final attribution call — that is the investigator’s job. A High confidence result means the data strongly supports the identified candidate; it does not mean the case is closed.

The tool does not provide financial or legal advice. It does not attempt to link blockchain addresses to real-world identities; it attributes addresses to known clusters and labeled entities (exchanges, contracts, faucets) only where the on-chain evidence directly supports that label. When the data is thin, contradictory, or obscured — by mixer involvement, deliberate layering, or a limited transaction history — the confidence band and data quality indicator will say so. See the FAQ for more on interpreting those signals.