# Onchain Forensics

> Investigate on-chain fund flows and cluster addresses using the standard 6-stage forensic workflow — multi-input ownership, change-address & FIFO mixer heuristics, bridge/DEX hop tracing, OFAC-sanctioned-cluster checks, and Daubert-grade evidence documentation. Outputs an investigator's case report with cluster table, hop-by-hop flow, attribution confidence, and reproducibility notes. Use to trace stolen funds, vet a counterparty, screen exposure, or build an investigative lead.

- Skill: `viprasol-tech/onchain-forensics` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add viprasol-tech/onchain-forensics`
- Raw SKILL.md: https://api.skillmd.com/api/skills/viprasol-tech/onchain-forensics/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: Viprasol-Tech (https://skillmd.com/u/viprasol-tech)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/viprasol-tech/onchain-forensics

---


# On-Chain Forensics

A disciplined methodology for tracing fund flows across one or more
blockchains and clustering addresses to likely-controlling entities. The skill
walks the canonical six-stage forensic workflow used by professional
investigators (Chainalysis, TRM, Elliptic): **collect → cluster → attribute →
graph → cross-chain → document**. It is grounded in the standard clustering
heuristics — **multi-input ownership** and **change-address detection** for
UTXO chains, plus account-based techniques (deposit-address clustering, common
gas funder, ENS reuse, bridge-receipt matching) for EVM and Solana — and
applies the published defeats against modern obfuscation chains (peel chain →
bridge → DEX → mixer → bridge).

> **Honest scope and limits — read first.** I cannot fetch on-chain state. I
> reason over what you provide (tx hashes, address lists, exported flow data,
> Etherscan/Arkham screenshots, prior analyst notes). I produce **investigative
> leads using probabilistic heuristics — NOT court-ready evidence**. For
> law-enforcement or litigation use, pair this with professional tooling
> (Chainalysis Reactor, TRM, Elliptic) and **subpoena-backed exchange data**.
> This is not legal advice.

---

## When to Activate

Activate this skill when the user:

- Wants to **trace stolen funds** from a hack, drainer, phishing victim, rug
  pull, or social-engineering theft across one or more chains.
- Asks to **vet a counterparty** address (OTC desk, market maker, exchange,
  vendor) for prior sanctioned or mixer exposure.
- Needs to **screen for sanctioned-cluster exposure** (OFAC SDN — e.g.
  Tornado Cash, Lazarus / DPRK wallets, named entities) on a list of addresses
  or a treasury.
- Is building an **investigative brief** or public exposé in the style of
  ZachXBT / Chainalysis / TRM / Elliptic public reports, or preparing a
  pre-subpoena lead package for counsel.
- Mentions **tx hashes, addresses, mixers, bridges, peel chains, ZachXBT,
  Chainalysis, TRM, Elliptic, Arkham, Nansen, Lookonchain, OFAC SDN, Lazarus**.

If the user only gives a single address with no context, ask for: case type,
seed tx hash(es), chain(s), approximate value at risk, timeframe, and what
exported flow data they can share. Do not fabricate transactions, balances,
flows, or attributions.

---

## Step 1: Intake & Scope

Anchor the investigation before any clustering. State each field explicitly in
the report header.

| Field | Why it matters |
|---|---|
| **Case type** | Theft / rug / sanctions screen / counterparty vet / AML exposure / public exposé. Different cases prioritize different outputs. |
| **Chain(s)** | UTXO (BTC/LTC/BCH) and account-based (ETH/EVM L2s/SOL) use **fundamentally different** clustering methods — Step 2. |
| **Seed addresses / tx hashes** | The known anchor points (victim address, exploit tx, drainer EOA). All tracing fans out from these. |
| **Value at risk** | Native units and USD where computable from user-supplied prices; sizes the case. |
| **Timeframe** | Funds older than the available exported window can't be traced; modern obfuscation completes in hours. |
| **Provided data** | Raw txs? Explorer CSV export? Screenshots? Prior analyst notes? Heuristic strength depends on what's in hand. |
| **Reporting target** | Internal brief / counsel / law enforcement / public report — controls tone, attribution thresholds, and disclosure. |

If reporting target is **law-enforcement or litigation**, repeat the limits
disclaimer at the top of the output and recommend professional tooling +
subpoena for exchange KYC.

---

## Step 2: Choose Heuristics by Chain Model

The chain's accounting model determines which heuristics apply. **Never apply
multi-input ownership to an account-based chain — it is undefined there.**

### 2a. UTXO chains (BTC, LTC, BCH, Doge)

| Heuristic | What it does | Known limits |
|---|---|---|
| **Multi-Input Ownership (MIH / common-input)** | If multiple inputs sign one tx, they're probably one entity. The most studied and *gold-standard* UTXO heuristic. | Defeated by CoinJoin / PayJoin / collaborative multi-sig — flag CoinJoin (equal-output co-spend) before clustering. |
| **Change-address detection** | Identify the change output: one-time-use address, script-type match to inputs, non-round amount, no prior history. | Probabilistic; randomized modern wallets defeat the round-amount signal. State confidence per hop. |
| **Address reuse** | Same address across deposits & withdrawals trivially links them. Powerful against sloppy actors. | None — but absence proves nothing. |
| **Behavioral / temporal patterns** | Fee bands, batching cadence, dust outputs, tx-timing fingerprints. | Soft evidence only; corroborate. |

### 2b. Account-based chains (ETH, EVM L2s, Solana)

There is **no MIH**. A single EOA can transact infinitely. Use:

| Heuristic | What it does | Known limits |
|---|---|---|
| **Direct transfer chain** | EOA→EOA→EOA preserves identity unless laundered. | Only attributes the path, not the controller. |
| **Exchange deposit-address clustering** | An exchange assigns a per-user deposit address; every cluster funding that address is the same user; the exchange's hot-wallet pattern downstream gives attribution. | Verifying which exchange needs published hot-wallet lists or KYT data. |
| **Common funding source / gas funder** | Many fresh EOAs funded for gas by the same address → same controller (sybil/wallet-mesh pattern). | A reputable exchange withdrawal can fund many *unrelated* users — exclude exchange hot wallets first. |
| **ENS / .eth / .sol name reuse** | The same ENS resolving across wallets, or a memo/transfer to an ENS, links the cluster to the named owner. | Spoofable; check resolver history. |
| **Bridge-receipt matching** | Canonical bridges emit lock-mint events with a correlatable `tx_hash` / `nonce` on both sides; AMM-style bridges (Across, LayerZero) match by event-log scan. | Intent-based / cross-domain solvers can intermediate and break direct correlation. |
| **Contract-interaction fingerprints** | Repeated calls to the same router, same approvals pattern, same dApp set → behavioral linkage. | Weak alone; corroborates other signals. |

**Every cluster claim must name (a) the heuristic, (b) its source data, and
(c) a Low / Med / High confidence.** Bare assertions are not acceptable.

---

## Step 3: Hop-by-Hop Fund-Flow Tracing

Walk each hop and classify it. Normalize to native units and USD where a
user-provided price exists; never invent a price.

| Hop type | What to record | Watch for |
|---|---|---|
| **Direct transfer** | from, to, tx hash, amount, time | Round amounts; identity preservation. |
| **DEX swap** | router (Uniswap / 1inch / CowSwap), pool, input/output tokens & amounts, slippage | Value-preserving across swaps — sum-of-USD should roughly hold. |
| **Bridge** | canonical (Hop / Across / Stargate) vs lock-mint; source tx → dest tx mapping | Bridge-receipt matching (Step 2b). |
| **Mixer (Tornado Cash / Railgun / eXch)** | denomination, deposit tx, anonymity-set context | Special handling — Step 4. |
| **Peel chain** | a big input split into a long series of small "drip" outputs | A textbook laundering signature; record the full peel. |
| **CEX deposit** | exchange hot-wallet pattern recognized on the receiving side | This is the lead — but identity needs subpoena. |

Across DEX and bridge hops, **track value preservation**: if $1.0M enters a
Uniswap router and $0.4M comes out the other side after a 60-second hop, the
delta is not slippage — find the other leg or the hidden recipient.

---

## Step 4: Handling Obfuscation Chains

> The modern criminal path of 2026 chains **3–5 techniques** in sequence:
> peel chain → bridge → DEX swap → mixer → another bridge → fresh CEX
> deposit. Reason about *obfuscation chains*, not single hops.

### 4a. Tornado Cash

- **Sanctioned by OFAC in August 2022** for facilitating ~$455M in Lazarus
  laundering. **Touching a Tornado Cash router post-sanction is itself a
  sanctioned-cluster contact** and a regulatory red flag.
- One **founder was convicted** (Roman Storm, 2024 IRS case — facilitating
  money laundering and operating an unlicensed money-transmitting business).
- Mixers break the *direct* link between deposit and withdrawal but are
  **partially defeatable**:

| Defeat | What to look for | Strength (per arXiv 2510.09433 et al.) |
|---|---|---|
| **Address reuse on the withdrawal side** | Withdrawer reuses an address with prior history. | Baseline linkage: 5.1–12.6% of withdrawals across denominations. |
| **FIFO temporal matching** | Match the i-th deposit to the i-th eligible withdrawal within a plausible time window. | +15–22 percentage points on top of address-reuse linkage. |
| **Gas-funder correlation** | The withdrawer's gas was paid by an address linkable to the depositor cluster. | High value when present; rare in disciplined adversaries. |
| **Post-withdrawal behavioral patterns** | Identical downstream behavior (same exchange, same dApps, same timing). | Soft; corroborates other signals. |
| **Anonymity-set size** | Low utilization of a denomination → smaller candidate set. | Reduces ambiguity, doesn't break anonymity alone. |

**State the FIFO caveat honestly:** without exact timestamps and the
denomination's full deposit/withdrawal list, the skill **narrows the candidate
withdrawal set** rather than producing a single match.

### 4b. Other obfuscators worth flagging

- **Railgun** — privacy-shielded EVM transfers; defeats similar to TC apply
  (entry/exit address reuse, behavioral linkage). Sanctioned-adjacency
  considerations vary by jurisdiction; flag as 🟠 by default.
- **eXch** — no-KYC swap service heavily used by hack proceeds in 2024–2025;
  treat any contact as 🟠 / 🔴 depending on amount and case context.

### 4c. Bridges

Cross-chain identity is preserved by canonical-bridge tx-hash correlation
(lock event on source ↔ mint event on dest) and by AMM-bridge event-log
scanning. Always record the **source tx hash and the destination tx hash** as
a linked pair; treat unmatched bridge legs as a leakage point to investigate.

---

## Step 5: Attribution & Evidence

Attribution turns a cluster into a real-world identity. **Be conservative.**

### 5a. Allowed sources (no hallucination)

- **OSINT** — public GitHub commits, ENS / .eth names, social-media handles
  in tx memos, doxxed Etherscan name tags.
- **Public labels** — Arkham, Nansen, Etherscan/Tronscan, Solscan tags,
  Lookonchain disclosures, Rekt / DefiLlama hacks database, Chainalysis public
  reports.
- **Sanction lists** — **OFAC SDN list** (always recompute against current).
- **Behavioral inference** — hot-wallet patterns and known exchange deposit
  patterns where published.

### 5b. What is NOT allowed

- **Exchange KYC** — requires a subpoena. The skill cannot fabricate it.
- **IP / device fingerprints** — out of scope without external evidence.
- **Personal identity claims** without a cited public source.

### 5c. Confidence labels

| Label | Standard |
|---|---|
| **Low** | One soft signal (behavioral pattern only). Useful as a lead. |
| **Med** | Two corroborating heuristics (e.g. funding source + behavioral) OR one strong source (public label). |
| **High** | Multiple independent corroborations including a hard signal (public sanction list, doxxed tag, published incident attribution). |

Every attribution row in the report **cites the evidence** (tag source, URL,
heuristic name) — no bare claims.

---

## Step 6: Red-Flags & Severity

Tag each finding with a severity icon. Bake the severity legend into the
report.

| Severity | Trigger |
|---|---|
| 🔴 **Critical** | Sanctioned-cluster contact (OFAC SDN); direct receipt of known theft / hack proceeds; Lazarus / DPRK cluster touch. |
| 🟠 **High** | Mixer-adjacent (Tornado Cash, Railgun, eXch contact); peel chain terminating into the attacker cluster; rapid multi-bridge chain-hop within hours. |
| 🟡 **Medium** | Multi-hop indirect proximity (≥3 hops) to a sanctioned or hack cluster; common gas funder shared with sybil mesh; dust-poisoning from a near-identical address. |
| 🟢 **Low** | Single soft behavioral overlap; isolated bridge use with full receipts. |
| ℹ️ **Info** | Context-only finding (e.g. address has known doxxed tag but is not in scope). |

Common triggers to scan for explicitly:

- Contact with a **sanctioned address** (always 🔴).
- Routing through **Tornado Cash / Railgun / eXch**.
- **Peel-chain signature** (one big input → long series of small drip outputs).
- **High-velocity sybil funding** from a single common funder.
- **Rapid chain-hop** across 3+ bridges in short succession.
- **Dust-poisoning** — small inbound from an address whose prefix/suffix
  mimics a legitimate counterparty (social-engineering vector).
- **Known-hack clusters** — Lazarus / DPRK, Atomic / Stake / Ronin / Bybit /
  WazirX clusters per published attributions.

---

## Step 7: Output Format — the Investigator's Case Report

Produce the report in this exact order so it's auditable end-to-end.

### 1. Header & TL;DR

```
Case:    <name>
Type:    <theft | rug | sanctions screen | counterparty vet | exposure | exposé>
Chain:   <BTC | ETH | multi-chain ...>
Window:  <ISO timestamp from – to>
Value:   <native amount + USD if priced>
Verdict: 🔴 / 🟠 / 🟡 / 🟢
TL;DR:   <2–3 sentences: who, what, where the funds went, total exposure>
```

### 2. Cluster table

| cluster_id | addresses | chain | heuristic | confidence |
|---|---|---|---|---|
| C-1 | `0xabc...` `0xdef...` | ETH | shared gas funder + behavioral | Med |
| C-2 | `bc1q...` `1AbC...` | BTC | MIH + change-address | High |

### 3. Hop-by-hop flow table

| step | from | to | tx_hash | type | amount (native) | USD | notes |
|---|---|---|---|---|---|---|---|
| 1 | victim | C-1 drainer | `0x…` | direct | 12.4 ETH | $39,680 | phishing approval |
| 2 | C-1 | TC 10-ETH pool | `0x…` | mixer deposit | 10 ETH | $32,000 | TC denomination |
| 3 | TC withdraw | C-2 | `0x…` | mixer withdraw | 10 ETH | $32,000 | **FIFO candidate** |

### 4. Mixer / bridge / DEX call-outs

For each special hop, a short paragraph: what the service is, what the
linkage attempt produced, the heuristics applied, and the candidate set or
the matched leg.

### 5. Attribution table

| cluster_id | likely entity | evidence | confidence |
|---|---|---|---|
| C-1 | known phishing operator (illustrative) | Lookonchain disclosure 2025-04-12; Etherscan tag | Med |
| C-3 | Exchange X deposit address (illustrative) | hot-wallet pattern; public label | Med |

### 6. IOCs

Sanctioned addresses touched. Known-bad cluster IDs. Mixer routers contacted.
Phishing-drainer signatures.

### 7. Reproducibility log

Every step labeled with the **heuristic name** + the source/link a human can
re-walk to verify the claim. This is what makes the report defensible.

```
Step 1: direct transfer — Etherscan tx <hash>
Step 2: TC deposit — TC contract router 0x910C... (sanctioned 2022)
Step 3: TC FIFO candidate — arXiv 2510.09433 method; candidate set of 3 withdrawals
        within +90 s window of the 10-ETH denomination
Cluster C-2: MIH — same tx with 4 inputs all signed together (mempool.space tx <id>)
```

### 8. Disclaimer (always)

> Findings are **investigative leads**, not court-ready evidence. Clustering
> heuristics are **probabilistic** and have known false-positive rates. For
> use in law-enforcement, civil litigation, or regulatory action, pair this
> with professional tooling (Chainalysis Reactor, TRM, Elliptic) and
> subpoena-backed exchange data, and have the analysis reviewed by a
> qualified investigator. Not legal advice. Under the US federal **Daubert**
> standard, a methodology must be testable, have known error rates, be
> peer-reviewed, and be generally accepted — this skill cites those standards
> but does not by itself satisfy them in a courtroom.

---

## Related Viprasol Skills

- **`wallet-security-review`** — sign-time analysis: should the user sign this
  transaction / approval? Phishing-signature taxonomy. Complementary to this
  skill (this one runs **after** funds have moved).
- **`smart-contract-audit`** — contract-side: was the exploited contract's
  code itself flawed? Pair when investigating a smart-contract exploit.
- **`defi-protocol-review`** — protocol-side risk matrix (admin keys,
  oracles, TVL composition). Pair when the case involves a protocol rug or a
  governance attack.

---

## Disclaimer

This skill produces **investigative leads using probabilistic heuristics**, not
court-ready evidence. The clustering and mixer-deanonymization methods cited
here (multi-input ownership, change-address detection, FIFO temporal matching,
bridge-receipt correlation) are drawn from peer-reviewed and industry-standard
practice but each has known false-positive and false-negative rates. For
law-enforcement, civil litigation, or regulatory action, pair this analysis
with professional tooling (Chainalysis Reactor, TRM Labs, Elliptic) and
subpoena-backed exchange KYC data, and have it reviewed by a qualified
investigator and counsel. The skill cannot fetch on-chain state — it reasons
only over what you provide and will say so when data is missing. **Not legal
advice. Not affiliated with or endorsed by Anthropic** or any forensics
vendor.