Skip to content
04 / docs

Method.

Cabalwatcher scores correlation between wallets from onchain evidence. It never asserts ownership. This page is the whole method, so you can disagree with it precisely.

01Pipeline

  1. 01Validate the address and resolve token metadata across providers.
  2. 02Index holders, token transfers and trades; reconstruct holders from transfers when no indexer is available.
  3. 03Select important wallets: creator, top holders, earliest buyers, largest buyers, creator-linked wallets (capped).
  4. 04Trace native transfers into those wallets and their funders, stopping at exchange-like and bridge-like addresses.
  5. 05Score every pair of important wallets across seven signals with configurable weights that sum to 100.
  6. 06Group pairs above the threshold with union-find; each member's cohesion is its mean pair score.
  7. 07Detect coordinated windows, bundles and funding bursts; match member sets against clusters seen before.
  8. 08Emit findings with what, why, evidence, when, source and the calculation; build the timeline and wallet DNA.

02Signals and default weights

  • Shared funding30Both wallets were funded by the same non-exchange address. Full strength when the transfers landed inside the funding-burst window, weaker when days apart, weakest when only the funders share a funder.
  • Temporal coordination20Share of one wallet's trades mirrored by the other on the same side inside the coordination window (60 s by default).
  • Historical overlap15Both wallets belonged to an earlier cluster on this instance, or appear on the same earlier tokens.
  • Repeated counterparties10Jaccard overlap of native-transfer counterparties, excluding exchange-like addresses.
  • Behaviour similarity10Position sizes within tolerance, entry in the same early window, and the same exit pattern.
  • Repeated launch participation10Both wallets were early on two or more of the same launches.
  • Transfer topology5A direct transfer between the wallets, a shared purchase transaction, or one intermediary between them.

Score = Σ strength × weight. Confidence: high ≥ 70, medium ≥ 40, low below. Labels: “High correlation” ≥ 85, “Likely related” ≥ 70, “Potentially linked” ≥ 40, otherwise “Weak signal”. Override weights with SCORE_WEIGHTS_JSON; they must still sum to 100.

03Language

We say
  • Potentially linked
  • Likely related
  • High correlation
  • Shared funding source
  • Coordinated activity
  • Insufficient evidence
We never say
  • “These wallets belong to the same person”
  • “Rugged” without a deterministic rule
  • Anything without a transaction, a timestamp and a source

04Data modes

With DEVELOPMENT_MODE on, the engine answers only for its fixture tokens and every result, event and badge reads DEMO DATA. With live providers configured, demo fixtures are never consulted. When a provider fails, the investigation continues with the others and the coverage panel says what was missing; a result with gaps is labelled PARTIAL INVESTIGATION.

05API

  • POST /api/investigations {address, chain?, refresh?}
  • GET /api/investigations/:id · /progress · /stream (SSE)
  • GET /api/tokens/:chain/:address
  • GET /api/wallets/:chain/:address
  • GET /api/clusters · /api/clusters/:id
  • GET /api/search?q=
  • GET /api/live · /api/live/stream (SSE)
  • GET /api/status · /api/health · /api/ready