gmgn-holder-analysis

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

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

sec2 = _("👨💻 Dev", "👨💻 Dev")

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`.

Audit 0.4.1 · source sha 3d2ef33ba0e5 · 21 Oct 2026Report an issue or request a re-scan

• Publishergmgnai GitHub userOwner of the repository this skill is read from
• Source foldergmgnai/gmgn-skills/skills/gmgn-holder-analysisThe exact folder we audited
• LicenceMITAs the repository states it
• Commit pinned for this verdict3d2ef33ba0e5A new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its 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…

---
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:

```bash
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**:

```python
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 threshold

Excerpt, first 6,001 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/gmgnai/gmgn-skills
git -C gmgn-skills checkout 3d2ef33ba0e5

Works in

1. 2026-10-21
   ✕BLOCK D 69 / 100

   first audit · source 3d2ef33ba0e5

Questions about gmgn-holder-analysis

• github.com/gmgnai/gmgn-skills/tree/main/skills/gmgn-holder-analy — the audited source at commit 3d2ef33ba0e5 and every finding aboveObserved · 21 Oct 2026

Spotted something wrong? Report a correction · Methodology