Gmgn Wallet Style

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 for data. Never WebFetch, curl, or browse gmgn.ai — the wallet page requires login and renders dynamically, so scraping it returns nothing useful and risks a ban. If the user wants the tag shown on the real page layout, ask them to paste a screenshot; do not attempt to fetch one.

This skill takes a WALLET address, not a token contract address. If the user says 「CA」 they usually mean a token contract — see Step 0 before running anything. Never silently treat a token address as a wallet: the call will succeed and return an all-zero profile, which looks like a real answer and is not one.

This skill has one required part and one conditional part. Part A computes the tag from real data — always run it. Part B renders that tag as a clickable HTML preview — run it only when the user's ask involves seeing the tag in context (a screenshot, a mockup, "预览", "界面", "叠加", "效果图"). A plain style-tag question gets a plain-text answer from Part A alone; do not build a page nobody asked for.

Sub-commands

Two calls, one wallet. Everything below is computed by you from those two responses — no script, no third call.

Supported Chains

sol, bsc, base, eth, arbitrum, hyperevm, robinhood, arc, stable — the chains gmgn-cli portfolio stats and portfolio activity accept. Treat this as an allowlist: any other value is rejected before a command runs, never passed through.

Prerequisites

• gmgn-cli installed: npm install -g gmgn-cli
• API key configured: gmgn-cli config

Nothing else. No Python, no local script, no other tool.

Parameters

Step 0 — Confirm it's a wallet, not a token

Run this check before the first command, in this order:

1. The user said 「CA」, 「合约」, 「代币」, "contract", or "token" → they most likely mean a token contract address. Ask which they want: a wallet style profile (this skill), or a token analysis. Do not guess.
2. The address is malformed — an EVM address must match ^0x[0-9a-fA-F]{40}$ and a Solana address ^[1-9A-HJ-NP-Za-km-z]{32,44}$; anything else (spaces, quotes, ;, $, a leading -) → say so and stop. Do not "fix" it. Only a validated address and an allowlisted chain may be put into a command, each as its own quoted argument.
3. Two or more addresses in the message → if the user said which one to profile, use that one and say which you used. If they did not, ask. Never pick one silently.
4. No address at all, only a token symbol or name → ask for the address. This skill cannot resolve names.

After portfolio stats returns, apply one more check: if buy + sell is 0 and pnl_stat.token_num is 0 and common.created_token_count is 0, this is either a token contract address, a fresh wallet, or a wallet that only ever received transfers. Say which possibilities remain and stop — do not emit tags.

Step 1 — Pull stats

gmgn-cli portfolio stats --chain <chain> --wallet <address> --period 7d --raw

Every numeric field arrives as a JSON string, not a number — convert before comparing. Read these fields, with the fallbacks exactly as written:

realized_profit_pnl is a ratio, not a percentage: 0.35 means +35%, 2.0 means the wallet tripled its money on closed trades. Never print it raw.

pnl_stat.token_num does not reliably follow the --period window. Measured on a real wallet: period=7d returned only 8 trades but token_num=202, essentially the all-time figure. Never use token_num to decide whether the sample is big enough — use buy + sell instead (Step 6).

Step 2 — Pull activity, paginated, filtering CLI notices

gmgn-cli portfolio activity --chain <chain> --wallet <address> --limit 50 --cursor <next> --raw

--limit silently caps at 50. Measured: 30→30 rows, 50→50 rows, but 60/80/100→ falls back to 20 with no error. Always pass --limit 50 and paginate with --cursor from the previous page's next. Pull 4 pages (200 rows) — on real wallets this yields 20–70+ complete round trips.

Before parsing JSON, strip any line starting with [gmgn-cli]. That is the CLI's own injection-defense notice printed ahead of the JSON body (e.g. [gmgn-cli] Notice: neutralized 4 suspicious metadata value(s)...) — measured on real wallets, roughly 1 in 5 trips one. Feeding raw stdout straight to a JSON parser fails on exactly those wallets with a misleading "non-JSON response" error. The notice itself is a real finding about the wallet's book (a token it traded carried injection-attempt metadata) — mention it, never crash on it.

Ignore transferIn / transferOut rows entirely — airdrops and internal moves are not trades.

If you hit RATE_LIMIT_BANNED, stop immediately — it is an account-level rolling ban that extends on further requests. Do not retry until the stated reset time.

If a call fails with 401 / AUTH_KEY_INVALID, the key was rejected even though config --check passed (that only confirms a key is present). Stop, tell the user the API key needs reconfiguring with gmgn-cli config, and emit no tags. Don't run gmgn-cli config for them: it creates a new key pair.

Step 3 — Frequency axis (L)

trades  = buy + sell
perDay  = trades / (7 if period is 7d else 30)

These boundaries, the P&L rules below and the main-title gate in Step 6a are the same as freq_level / pnl_level / style_title in gmgn-wallet-analysis/analyze.py, so a wallet gets the same title in both skills. Change them together or not at all.

Step 4 — P&L axis (P)

lt50Share = pnl_lt_nd5_num / max(1, token_num)

Test in this order and stop at the first match:

P5 needs one corroborating shape, not both. Memecoin P&L is low-hit-rate with a fat right tail: requiring a 50% win rate as well pushed a wallet sitting at #3 on GMGN's own 7D leaderboard down to P4. Either a ≥50% win rate or a <15% heavy-loss share is enough alongside the return.

The token_num >= 5 clause on P5 is not optional. Without it a wallet that traded one coin and got lucky satisfies every other condition — winrate is 1.0, lt50Share is 0 — and gets tagged 一击必杀/一击必杀-tier. Luck is not skill; five tokens is the floor for calling a record a record.

Open limitation, not silently patched: pnl is realized profit ÷ cumulative cost. A high-frequency wallet re-buys constantly, so its cost basis balloons and a genuinely profitable wallet can still show a thin ratio. Measured on 10 real high-frequency wallets: 4 were net-positive ($2,300–$21,000 over 7 days) but still landed on 🪫 磨损户 because the ratio was in the low single digits. Always print the absolute realized_profit dollar figure next to the title so the reader is not misled by the ratio alone. A proposed absolute-dollar override threshold ($50K/$5K) was backtested against a second batch of wallets at a different size scale and only changed 1 of 10 verdicts — it does not generalize across chains/wallet sizes, so it is not applied here. Say the tension; do not invent a fix.

Step 5 — Main title

One cell, from L and P:

One line of colour for whichever cell you land in:

English names above are not translations — they are the actual English strings shipped in gmgn-wallet-analysis/analyze.py, the production Skill this logic lives in upstream: money printer, full-auto grinder, worn down, gas burner, self-destruct, harvester, active winner, spinning top, fee donor, bleeding out, old hunter, steady hand, lukewarm, retail loser, deep underwater, one-shot, zen winner, bystander, toe in the water, wiped out. Use them verbatim for an English speaker rather than re-translating — some (全自动P机 → "full-auto grinder") only work because they were re-authored, not translated; "P" is Chinese trading slang for "profit" and has no literal English equivalent.

Step 6 — Speed subtitle, from a MEDIAN copy window — never from avg_holding_period

pnl_stat.avg_holding_period is unreliable: it counts positions never sold, so it drags the average up. Measured on 20+ real wallets across two chains: the API-reported average was 1,728×–22,931× larger than the wallet's actual median round-trip time — a 15-second scalper reported as a "4-day" holder, repeatedly, not as an outlier.

Compute the true value from portfolio activity:

1. Group activity rows by token.address.
2. Per token, find the first buy and the first sell after it; the gap is one "copy window" sample.
3. Take the median across all tokens with a valid gap. Call this cw_s, and the sample count cw_n.
4. If cw_n < 3 or cw_s is 0, do not print a speed subtitle at all — say the sample was too thin, don't guess one.

If avg_holding_period is more than 8× cw_s, that is expected, not a bug in your math — it just confirms the API field is the wrong one to use. Do not report both numbers to the user or explain the discrepancy; just use the median silently and move on.

Step 7 — Badges

Orthogonal — award every one that triggers, or none.

Step 6a — sample-sufficiency, gated on buy + sell, never on token_num: if buy + sell < 20, award ⚠️ and say the exact count (e.g. "7D 仅 8 笔交易"). An earlier version of this rule gated on token_num < 5, which never fired on real wallets — one had 8 real trades but token_num=202, sailing through as "plenty of data." Still give the main title alongside ⚠️ — a hedged answer with numbers is more useful than none, but the hedge has to be stated, not implied. The one exception is token_num < 5: then print no main title at all, only ⚠️ and the numbers, exactly as style_title in analyze.py does. A four-token wallet has nothing to label yet.

🚩 wash_trader is a flag, not a veto. State it plainly ("GMGN 官方将该地址标记为 wash_trader —— 交易笔数与账面盈利都可能是自成交刷出来的") and let the reader weigh it. Do not silently suppress the wallet's other numbers, and do not launder the tag into a positive spin. Every other number in the report stays exactly as computed.

Step 8 — Output format

{main emoji} {main title} · {speed emoji} {speed subtitle}
{one line of colour for the cell}

{badge emoji} {badge name} · {the number that triggered it}
{badge emoji} {badge name} · {the number that triggered it}

判定依据
  频次   {buy} 买 + {sell} 卖 = {trades} 笔 / {days} 天 = {perDay} 笔/日  → {L} {name}
  盈亏   pnl {pnl as %}  胜率 {winrate as %}  重亏占比 {lt50Share as %}  已实现 {realized_profit as USD}  → {P} {name}
  持仓   平均往返 {cw_s, humanised}（{cw_n} 次真实往返）
  样本   {token_num} 个币种 · activity {n} 条，覆盖 {hours} 小时

Rules for the output:

• Never print a title without the 判定依据 block. A label with no numbers under it cannot be checked, and being checkable is the entire point.
• Print pnl and winrate as percentages, and USD with a $. Never show the raw ratio.
• If cw_n < 3, omit the speed subtitle from the title line and say in 判定依据 that the sample was too thin for a speed reading — do not fall back to avg_holding_period.
• If ⚠️ 样本不足 or 🚩 刷量嫌疑 fired, put those lines first among the badges, not last.
• Do not explain your method to the user unprompted (which field you used, why one number was preferred over another). State the conclusion and the number that backs it; save the mechanism for when someone asks "为什么" directly.
• Answer in the language the user wrote in. The tag names above are proper nouns — keep them in Chinese in both languages, and gloss them once in English on first use for an English speaker.