CASE FILE — WALLET INVESTIGATION

Every wallet
leaves a trail.

Give ChainHound an address. It reads the wallet's full history, follows where its funds came from and went, and names every account it finds along the way.

NEW INVESTIGATION/api/wallet

Every wallet found is named onchain via ENSv2

Live workflow

/api/wallet · idle
investigation.logREADY
[0.0s]$awaiting POST /api/wallet
 

How the trail is built

running done failed

Every stage below streams into the live console above as your investigation runs — the step keys shown are the exact lines you'll see, in order, in real time. Nothing here is precomputed.

01

Live data

A natural-language agent runs prescribed queries against Uniswap V3 and Aave V3 subgraphs — live indexed data, not a cached snapshot or a mock fixture.

THE GRAPH · SUBGRAPH MCP
subgraph:swapssubgraph:lending
02

Fund flow

In parallel, ethers.js scans Transfer event logs directly against an RPC node to reconstruct every token this wallet has sent and received — the spine the trace walks.

ETHERS.JS · RPC LOGS
fundflow
03

Risk analysis

The model never invents a score — it explains a severity, a title, and a detail per flag over the fund-flow + protocol data it's given, and states plainly what it can't see.

GEMINI / CLAUDE · STRUCTURED EVIDENCE
risk
04

Onchain identity

Every wallet in the trail is registered as a real ENSv2 subname under its own subregistry, so the report reads root.chainhound.eth and its counterparties, not raw hex.

ENSv2 · SEPOLIA
ens:rootens:counterparty:n
05

Trail verification

Fund Trace mode re-runs stages 01–04 on the root wallet's most recent counterparties, one hop out — Wallet 1, Wallet 2, Wallet 3… each link in the trail independently scored, not just displayed.

1-HOP RE-VERIFICATION
trace:wallet1trace:wallet2trace:wallet3