Single-address analysis
Per-asset wallet profiling, a one-hop transfer table, and N-hop expansion — all accompanied by a boundary ledger.
Capabilities
Grouped by requirement area. Every item carries the phase it belongs to and whether it is «verified» or «designed». We do not write designs up as capabilities.
How to read this page
«Verified» means the algorithm has produced results on the reference case. «Designed» means the spec and parameters are complete but it is not yet frozen into the API contract. Neither label promises that you will see a finished screen for it today — TCP v2 is on its review hosts.
«Verified» means the algorithm has produced results on the reference case. «Designed» means the spec and parameters are complete but it is not yet frozen into the API contract. Neither label promises that you will see a finished screen for it today — TCP v2 is on its review hosts.
Multi-address (N-way) analysis
Our strongest product bet, and a white space across the market we reviewed. 2 to 25 seed addresses, 15 modes, one traversal engine, one shared crawl cache. That shared cache is the difference between a four-minute and a forty-minute investigation.
| Mode | The question it answers | Phase |
|---|---|---|
Common counterpartiescommon_counterparties | Which counterparties do all N — or at least k of N — of these addresses touch? Computed over complete histories, so it is exact, not a bounded sample. | Phase 1Verified |
Pairwise intersectionpairwise_intersection | Which pairs among these N are actually related, ranked? All pairs, but N crawls rather than N². | Phase 1Verified |
Clustercluster | Which of these addresses behave as one entity? A signal ensemble, never a single heuristic. | Phase 1Verified |
Common funding sourcecommon_funding_source | Who funded all of them? Upstream ∩ upstream, with exact direct funders and bounded reachable funders kept as separate lists. | Phase 1Verified |
Common payeecommon_payee | Where did they all end up paying — and did they all cash out in the same place? Operational payees and cash-out endpoints are never merged. | Phase 1Verified |
Flow betweenflow_between | How much value moved among these N, in which direction, and is anyone round-tripping? | Phase 1Verified |
Timelinetimeline | Do these addresses act together in time? Merged swimlanes, burst detection, lead–lag. | Phase 1Verified |
Comparative profilecomparative_profile | Before anything expensive: what are these addresses? The cheapest useful mode in the list, and the natural landing page. | Phase 1Verified |
Exclusive counterpartiesexclusive_counterparties | What does A touch that B…N never do? This is the exoneration mode, and we could not find a competitor selling one. | Phase 2Designed |
Co-spend batchco_spend_batch | Were any of these addresses paid by the same sender in the same transaction? The closest thing to a deterministic co-membership signal available on TRON. | Phase 2Designed |
Activation sequenceactivation_sequence | Who created and funded this set of wallets, in what order? | Phase 2Designed |
Behavioural similaritybehavioral_similarity | Do these addresses behave like the same operator? Compared feature by feature — never as one blended similarity number. | Phase 2Designed |
Minimal connecting subgraphminimal_connecting_subgraph | Show me the smallest picture that connects these — or tell me they do not connect. | Phase 2Designed |
Group flowgroup_flow | How much value moved from group A to group B, and through whom? | Phase 2Designed |
Exposure matrixexposure_matrix | What exposure does each address have to each risk category, inbound and outbound? | Phase 2Designed |
Phase 1 has a soft cap of 12 seeds and a hard cap of 25. Exceeding it returns a 422 rather than silently truncating. · N = 2…25
Two-address analysis
Bidirectional N-hop expansion of both addresses, intersected and tiered, presented alongside the exact set of one-hop shared counterparties computed from complete histories. The exact set is stronger evidence than multi-hop reachability, so it is always shown alongside and labelled differently.
Stolen-funds investigation
A case wizard that validates the anchor transaction first, then runs post-incident temporal taint tracing, gas-funder analysis, money-conservation accounting and suspect ranking, and produces a report plus a law-enforcement freeze-request packet.
Live detection and alerting
A resumable, ordered live feed built on roughly 3-second block polling, driving watchlists and six kinds of alert rule across three delivery channels.
User labelling
Addresses, transactions and clusters can all be labelled. Source detail is mandatory on every label, so every label knows who said it, when, and what the raw value was.
A user label, an explorer tag and a heuristic can all coexist and contradict each other. The interface shows all of them with their sources and trust tiers. We do not decide for you which one is right.
Evidence integrity and reproducibility
A contract, not an adjective.
- The as_of instant is fixed at case creation and clamped into every subsequent provider call.
- Provider responses are kept verbatim, keyed by sha256 of the canonical URL, with the source URL and fetch time recorded.
- There is a SHA-256 manifest over every produced artifact.
- A validate operation re-asserts every claim against hard-coded expected results — it does not simply re-run itself.
- A challenge operation performs adversarial re-verification, and it is a button the user can press.
- A recrawl creates a new snapshot linked back to its parent, and the two can be diffed.
The five false-positive detectors
Each one corresponds to a real false accusation that happened before it was caught. They are named, shown, downgraded and explained.
False-positive checks5 flagged
These flags mean a finding has a known, ordinary alternative explanation. A flag never hides the finding — it downgrades it and says why.
Temporally impossibleHard failure
Part of this path happened before the incident.
For funds to move from A to B, B must receive at or after the moment A sends. This path breaks that order: at least one hop on it predates the theft, so it cannot be carrying the stolen funds.
What to do next
This is a hard failure, not a matter of degree, and the result has been marked unusable. Check that the incident timestamp on the case is correct and that the time fields are in milliseconds.
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.
What to do next
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.
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.
What to do next
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.
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.
What to do next
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.
Reused wallet
This address had substantial activity before the incident, which dilutes its statistics.
This is not a wallet opened for this case. It was already in ordinary use before the theft. Counting counterparties from before and after the incident together answers "who is this address connected to?" with a number that history has watered down, and sometimes actively misleads.
What to do next
The statistics on this page are already split at the incident time — read the two halves separately. Counterparties that recur *before* the theft usually represent real business relationships, and are often the best lead to who actually operates the address.
Where we sit in the market
We reviewed the public material of 16 products, including Chainalysis, TRM Labs, Elliptic, Crystal, Merkle Science, Scorechain, Global Ledger, AMLBot, MistTrack, Bitrace, Breadcrumbs, MetaSleuth, Arkham, Bubblemaps, Nansen and the open-source GraphSense.
Capabilities we could not find documented by any reviewed vendor
- The two-graph doctrine — the graph that visualises is separated from the graph that concludes.
- An explicit time-causal traversal invariant — stated, enforced and tested.
- A named false-positive taxonomy (FP1–FP5) that labels and downgrades rather than hides.
- Evidence tiering — {tier, strength, basis} on every finding.
- The boundary ledger as a deliverable — «we stopped here, and why».
- A reproducibility contract — fixed as_of, verbatim payload cache, SHA-256 manifest, validate re-assertion.
- Adversarial self-review as a user-facing button.
- «No link found» as a first-class, fully reported outcome.
- Gas-funder analysis on account-model chains.
- N-way multi-address analysis as a designed product surface.
- A Traditional-Chinese-first product interface.
Where we are structurally behind
- A proprietary entity-attribution database — we will not have one, and the design does not depend on one.
- Chain breadth — competitors cover 27 to 330 chains; in Phase 1 we cover one.
- Cross-chain bridge attribution — our single biggest coverage gap. Funds that bridge out of TRON vanish from our graph.
- Mixer demixing.
- Off-chain intelligence, VASP due diligence and Travel Rule.
All of the above is based on each vendor's public documentation. Absence of evidence is recorded as unknown, not as absent — several of these vendors document their products poorly.