---
name: smart-money-tracker
description: Discover profitable on-chain "smart money" wallets (Hyperliquid) via the local grok CLI's X/Twitter search, verify and analyze their positions and trade history with the Hyperliquid public API, distill their trading style, and generate a Freqtrade strategy for backtesting or dry-run. Use when the user asks to find/track smart money or whale wallets, copy or reference on-chain traders' strategies, analyze Hyperliquid wallets, or turn wallet behavior into a Freqtrade strategy (聪明钱/巨鲸钱包/链上跟单/持仓分析).
---

# Smart Money Tracker

Pipeline: **discover** wallets on X (grok) → **verify** on-chain (script) → **profile** trading style (judgment) → **generate** Freqtrade strategy → **validate** (backtest / dry-run).

## Step 1 — Discover wallets via grok CLI

The local `grok` CLI has native X search. Run headless:

```bash
grok --cwd <empty-dir> --no-subagents --no-memory \
  -p "You are doing pure web/X research. Do NOT run shell commands, read/write files, or use local skills. <discovery prompt>" \
  --max-turns 25 --output-format json
```

**Pitfall:** grok is Claude Code-compatible and reads `~/.claude/skills` — without the guardrails above it finds THIS skill and tries to run `grok -p` recursively, hanging until timeout (`stopReason: Cancelled`). Always use an empty `--cwd`, `--no-subagents`, and the "pure research" prompt prefix.

Parse the `.text` field from the JSON output (`jq -r .text`); if `stopReason` is not `EndTurn`, treat the output as incomplete and retry. Redirect stderr separately (`2>/dev/null` or a separate file) — grok logs WebFetch errors to stderr and they corrupt the JSON if merged. Long-running: run in background, ~1-5 min.

Discovery prompt guidelines:
- Ask for wallets shared by on-chain tracker accounts (Lookonchain, Onchain Lens, Spot On Chain, Hyperdash) AND self-doxxed traders, within a recent window
- Require full `0x...` addresses, the trader's X handle if known, claimed PnL, and source post links
- Ask for more than needed (e.g. 15 to end up with 10) — some will fail verification
- If the user has a niche (e.g. "memecoin perp traders", "low-leverage swing"), put it in the prompt

**Never trust addresses from X directly** — fake/phishing addresses circulate. Every address must pass Step 2.

## Step 2 — Verify on-chain

For each candidate address:

```bash
python3 scripts/hl_fetch.py summary 0xADDR --days 30
```

Subcommands: `positions` (current perps + account value), `fills` (trade history with per-coin stats), `portfolio` (day/week/month/allTime PnL and volume), `summary` (all three). No API key needed.

Keep a wallet only if: recent fills exist (active), `allTime` PnL is meaningfully positive, and account value is non-trivial. Note: `fills` caps at the 2000 most recent; for high-frequency wallets shrink `--days` to avoid a truncated window.

## Step 3 — Profile each wallet, then find the common factors

From the script output, characterize per wallet: coin universe, direction bias (long/short), typical leverage, trade frequency, position sizing relative to account, adds/reduces vs one-shot entries, holding period (estimate from open/close fill timing).

Then synthesize across wallets: what do the majority do that is quantifiable? Present the per-wallet table + common factors to the user before generating a strategy.

## Step 4 — Generate strategy (two modes)

**Mode A — rule induction (default, backtestable):** translate the common factors into indicator-based entry/exit rules and write a Freqtrade strategy. Be honest: this imitates their style, it does not clone their trades. Expect the first backtest to be negative — the quantifiable factors (universe, sizing, holding period) often don't contain the alpha, which lives in discretionary timing. Limit to 2-3 principled iterations (bug fixes, dropping provably harmful rules), report all variants' metrics honestly, and if still negative recommend Mode B instead of curve-fitting.

**Mode B — signal following (dry-run only):** poll wallet position changes as entry/exit signals. No historical signal series exists, so classic backtesting is impossible — offer only if the user explicitly wants copy-trading, and set expectations.

For the strategy template and the server backtest/dry-run commands, read [references/freqtrade.md](references/freqtrade.md).

## Step 5 — Validate

Backtest first (Mode A), review metrics with the user, then dry-run. Never suggest live trading directly; the user decides after dry-run.