Crab Catch
Crab Catch is a Web3 research skill that automatically collects and organizes project data and potential risks from social media, websites, code, and on-chain data, and produces a complete and objective research report.
安装 / 下载方式
TotalClaw CLI推荐
totalclaw skills install shop:github:LeoYeAI~openclaw-master-skills~crabcURL直接下载,无需登录
curl -fsSL https://skills.taituai.com/api/skills/github%3ALeoYeAI~openclaw-master-skills~crab/file -o crab.md# Crab Catch — Research Skill Orchestration
## Prerequisites
CLAWBOT **must run** these commands at session start (not just read them):
```bash
which agent-browser || npm install -g agent-browser
agent-browser install
```
## Data Sources
CLAWBOT is the research driver — responsible for analysis, judgment, iteration,
and report generation. The APIs, scripts, and tools below are **data-fetching
methods only**.
**API Base URL**: `https://crab-skill.opsat.io`
### Signature Authentication
All API requests except `/api/health` require Crab signature headers.
1. Run `node skills/scripts/crab-sign.js` **once** at session start to get headers JSON.
(First run auto-generates credentials; cached signature reused if still valid within 24h.)
2. Store the output and attach these four headers to **all** subsequent API requests:
`X-Crab-Timestamp`, `X-Crab-Signature`, `X-Crab-Key`, `X-Crab-Address`.
3. Only re-run with `--refresh` if API returns `auth_expired`.
### Twitter & Social Data (see `twitter-analysis/SKILL.md` for full params)
| Category | Key endpoints | Purpose |
|----------|---------------|---------|
| Profile | `/api/twitter/user`, `tweets`, `replies` | Basic info, content, interactions |
| Risk signals | `/api/twitter/deleted-tweets`, `follower-events` | Removed content, follow/unfollow patterns |
| Reply threads | `/api/readx/tweet-detail-conversation-v2` | Primary comment source (fast, raw data) |
| Quote tweets | `/api/readx/tweet-quotes` | KOL commentary, community opinions with context |
| Engagement data | `/api/readx/tweet-detail-v2` | Views/source — detect bot-inflation |
| Deleted content | `/api/readx/tweet-results-by-ids` | Batch fetch deleted tweet snapshots |
| Long-form | `/api/readx/tweet-article` | Technical analyses, roadmaps published as articles |
| Relationships | `/api/readx/following-light`, `friendships-show` | Inner circle, team relationship verification |
| Credibility | `/api/twitter/kol-followers`, `/api/readx/user-verified-followers` | Who credible follows them (`verified-followers` needs `user_id` not username) |
| Search | `/api/twitter/search`, `/api/readx/search2` | Risk signals, disputes, community discussions |
### GitHub Code (see `github-analysis/SKILL.md`)
Local script `skills/scripts/github_analyze.js` — no external API.
`convertToMarkdown(url, options)` or `analyzeRepository(url, options)`.
### On-chain Data (see `onchain-audit/SKILL.md`)
**Binance API** — `address` + `chainName` (uppercase: `BSC`/`ETHEREUM`/`BASE`/`SOLANA`):
| Endpoint | Description |
|----------|-------------|
| `/api/onchain/audit` | Contract audit (dual-source) |
| `/api/onchain/token-info` | Token metadata and market dynamics |
| `/api/onchain/wallet` | Wallet positions (BSC/BASE/SOLANA only) |
| `/api/onchain/token-search` | Token search (requires `keyword`) |
**Bitget API** — `chain` + `contract` (lowercase: `bnb`/`eth`/`base`/`sol`):
| Endpoint | Description |
|----------|-------------|
| `/api/onchain-2/token-info` | Token details |
| `/api/onchain-2/token-price` | Token price |
| `/api/onchain-2/tx-info` | Transaction statistics |
| `/api/onchain-2/liquidity` | Liquidity pool info |
| `/api/onchain-2/security-audit` | Security audit |
**Onchain Explorer API** — `chain` + `address` (see `API_EXPLORER.md` for full params):
| Endpoint | Chain | Description |
|----------|-------|-------------|
| `/api/explorer/contract` | ETH, BSC | Contract ABI, source code, compiler info, proxy detection |
| `/api/explorer/token-history` | ETH, BSC, SOL | Token transfer history with pagination |
| `/api/explorer/sol-address` | SOL | SOL/SPL balances + recent transfer records |
### Website Content (see `agent-browser/SKILL.md`)
CLAWBOT uses `agent-browser` CLI to open and inspect websites.
## Language Preference
Output language **matches the user's input language**; default **Chinese (zh-CN)**.
Raw API data (usernames, tickers, addresses, code) stays in original form.
## Orchestration Flow
**Callback-driven**: each module's output triggers queries in other modules.
Modules keep feeding each other until no new high-value leads remain.
```
User provides URL / Ticker / contract address + research intent
│
▼
Step 1 — Parse input, initialize entity queue
Extract: Twitter links, GitHub repos, contract addresses, tickers, chain
Aggregator URLs → extract entities from path (see rules below)
Initialize:
entity_queue = [{ entity, type, depth: 0 }]
processed = set()
claims = [] # official claims to verify later
fund_trace = [] # addresses to trace fund flow
team_members = [] # { handle, role, source }
MAX_DEPTH = 2
│
▼
Step 2 — Multi-module collection
While entity_queue is not empty:
pop → skip if processed or depth > MAX_DEPTH → route by type:
URL → 2a Website
Twitter → 2b Social
GitHub → 2c Code
Contract → 2d Chain
Ticker → 2d token-search first
After each module: extract new entities → queue at depth+1
(see Cross-module Callback Summary below for full routing)
── 2a. Website exploration ──────────────────────────────────
**Use `agent-browser` CLI** (see agent-browser/SKILL.md for commands).
agent-browser renders JS, captures interactive elements, and allows
clicking through pages — essential for DApp testing and dynamic sites.
Fallback to WebFetch only when agent-browser fails (e.g. install issue).
Visit pages in order:
Landing → Docs/Whitepaper → Team/About → DApp → Tokenomics → Footer
Extract from each page:
- Official claims → append to claims[] ("audited by X", "100M supply",
"decentralized", "LP locked", partnerships, etc.)
- Team names + social links → team_members[] + queue 2b
- Contract addresses → queue 2d
- GitHub repos → queue 2c
DApp proactive testing (key investigation step):
- Open DApp via agent-browser, wait for load
- Does the UI render real data or just a mock shell?
- Are core functions visible and interactive?
- Check network requests: broken APIs? Suspicious external calls?
- If DApp shows on-chain values → cross-check against 2d data
- Screenshot as evidence
Security check: SSL, domain age, redirects, suspicious popups.
Fallback: blank/Cloudflare → retry with `--headed`. No website → flag as risk.
── 2b. Social data collection (Twitter) ─────────────────────
Purpose: collect project claims, discover team, find community disputes.
NOT the investigation core — feeds into 2a/2c/2d for verification.
For project official account:
1. /api/twitter/user + tweets + replies + deleted-tweets (parallel)
2. Pick 1-2 high-value tweets → conversation-v2 + quotes
3. /api/readx/following-light → identify team members from following list
(mutual follows, bio mentions project, new account only posts about project)
→ add to team_members[], queue 2b at depth+1
4. Risk search: search2 "{project} scam OR rug OR hack OR exploit"
For team member accounts (depth 1+):
1. /api/twitter/user + tweets (parallel)
2. Only retain project-related tweets → append to claims[]
(team member statements carry same weight as official claims)
3. friendships-show with other known team members
(all isolated = fake team red flag)
── 2c. Code analysis (GitHub) ───────────────────────────────
github-analysis → analyzeRepository / convertToMarkdown
Focus: claim verification + security scan
- "Open source" → repo public? Code complete or stub?
- "Audited" → audit report in repo? Code matches?
- Hardcoded addresses (admin, treasury) → queue 2d + fund_trace[]
- Suspicious patterns: obfuscation, eval(), wallet-draining code,
backdoors, malicious dependencies, clipboard hijacking
- Contri