/gmgn-holder-analysis

name: gmgn-holder-analysis
description: Token holder chip analysis — deep analysis of holder structure including chip distribution, entry cost, whale/dev/KOL behavior, risk wallets (rat traders, bundlers, snipers), related wallets, smart money signals, and an AI rating based purely on token structure. Use when user asks about holder analysis, 筹码分析, 持仓分析, chip structure, who is holding, or whether a token is safe to buy based on its holder composition.
argument-hint: "--chain <sol|bsc|base|eth|robinhood|arc|stable> --address <token_address>"
metadata:
  cliHelp: "gmgn-cli token holders --help && gmgn-cli portfolio created-tokens --help"

**BEFORE RUNNING ANY COMMAND: Run `gmgn-cli config --check`. If exit code is 0, proceed normally. If exit code is 1, run `gmgn-cli config` and show output, then apply the key with `gmgn-cli config --apply <KEY>`. If unknown option, tell user to run `npm install -g gmgn-cli`.**

**IMPORTANT: Always use `gmgn-cli` commands. Do NOT use curl, WebFetch, or visit gmgn.ai.**

When the user asks to analyze holders for a token, extract `--chain` and `--address` from their message, then run the analysis script below. Also detect the user's language: set `LANG` to `'zh'` if the user wrote in Chinese, `'en'` if in English (default `'zh'`).

Analysis Script

Run the following command, replacing the placeholders with the actual values:

python3 ~/.claude/skills/gmgn-holder-analysis/analyze.py <FILL_IN_TOKEN_ADDRESS> <FILL_IN_CHAIN> <FILL_IN_LANG>

• FILL_IN_CHAIN: `sol` for Solana addresses; for EVM `0x...` addresses use `auto` unless the user explicitly specifies a chain (`bsc`/`eth`/`base`)
• FILL_IN_LANG: `zh` if user wrote Chinese, `en` if English, default `zh`

Output Rule

After the script finishes, paste the complete stdout verbatim into your reply — every line, every section, nothing omitted or summarized. Do NOT add any introduction, commentary, or summary before or after the output block.

Field Reference

All holding percentages the script prints are **share of tradeable float** (`1 - burn - DEX`), not share of total supply. `amount_percentage` from the API is share of total supply; the script re-bases it. Because only the top 100 holders are fetched, a float percentage is a floor **when those 100 wallets do not cover the whole float**; the footer reports the actual coverage and states which case applies — floors when coverage <99.5%, complete values when the top 100 cover all of it.

When burn + DEX leave less than 2% of supply tradeable (typically a launchpad token before migration), the float denominator degenerates: every `/ float_share` inflates dust wallets to double digits or 100%. The script detects this, prints a banner with absolute token/USD figures instead, and sets the rating to ⚪ Cannot Assess.

The same suppression applies when `token holders` returns an empty list (token has no active holders left, or upstream stopped indexing it). Every percentage would render 0.00% and every threshold would pass, so the report would otherwise read "✅ Normal — no obvious dump risk". The script prints a no-data banner instead, replaces each "none found 🟢" line with ⚪, and rates ⚪ Cannot Assess. "No data" is never reported as "no risk".

In both cases **no float percentage is printed at all** — every one renders as `n/a` (`无法评估`) and every percentage flag renders ⚪. Printing the number with a caveat was not enough: a divide-by-zero float puts `hold 100.00%` and `hold 0.00%` in the same report, and a reader skimming past the banner reads `Rat Trader 1 hold 100.00%` as a finding. Wallet counts, token amounts, USD values, and market caps still print — they do not pass through `float_share`. Percentages on a **total-supply** basis also still print (`burn`, `DEX`, float share itself, and the chip-quality buckets), because those denominators are unaffected.

"Zero cost" must be proven, not inferred from a missing buy count

`buy_tx_count_cur == 0` does **not** mean the wallet received its chips for free. Measured on musebook (robinhood): 38 wallets read `buy_tx_count_cur: 0` and `avg_cost: null`, but **34 of them carry a finite `unrealized_pnl` ratio** (+2.7%, +76.5%, +546%) — a ratio that cannot be computed without a cost basis — and 32 carry a `fomo` frontend tag, 2 a `gmgn` tag, which is the trace of active trading, the opposite of receiving an airdrop. What is actually missing is buy-transaction indexing on that chain, while the PnL fields come from a separate computation and arrive populated.

The error was systematic per chain, not per token. Never-bought share of supply, same batch: **robinhood 27.0% and 41.2%, arc 26.3%, sol 4.8%.** The 20% airdrop warn gate therefore fired on essentially every robinhood/arc token and essentially never on a sol token — a difference in index coverage, not in chip structure. Reporting an unpopulated field as a risk conclusion is exactly what this skill forbids.

So a wallet counts as zero-cost only when **no cost evidence exists at all**:

def has_cost_basis(h):
    return (h.get('avg_cost') or 0) > 0 or h.get('unrealized_pnl') is not None

Wallets with no indexed buy count but a real cost basis are **not dropped from the report** — they get their own neutral line, `买入未记录 / Buy count unindexed`, with their float share. The fact that upstream did not index their buys is true and stays visible; it just does not drive a zero-cost gate. The same predicate now governs the `钻石手 / Diamond` cohort (its stated rationale is "a wallet that never paid has no cost to hold through", which a proven cost basis satisfies), the `转入筹码未动 / Idle airdrop` line (its "zero cost" caption was a false statement for those wallets), and the Top5 sell-risk classification (which was labelling a wallet at +6.6x as "zero-cost airdrop — can dump anytime").

Known limit: a genuine airdrop wallet whose `unrealized_pnl` is a huge ratio computed against a dust-level cost would be missed here. No second ratio threshol