Gmgn Wallet Review

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

Always use gmgn-cli for data. Never WebFetch, curl, or browse gmgn.ai — the wallet page needs login and renders dynamically.

This skill is a single file on purpose: there is no bundled script. You pull the data with gmgn-cli, compute the numbers below yourself (a throwaway jq or python3 -c over the saved responses is fine and usually more accurate than reading 300 rows by eye), apply the rules, and fill the fixed sentence templates. Follow the rules and templates exactly — they are what makes two runs on the same wallet say the same thing.

What this skill produces

Three lines, nothing more:

⚙️ 全自动P机 · ⚡ 秒杀流  （7D）
一句话复盘：你近 7 天赚了 $41.9K，止损干脆，但手续费吃掉了 78% 的利润。
下一步：少做持仓不到 1 分钟的单子（这部分在亏钱），持仓 1–30 分钟的单子收益率有 17%。

• Tag: one title from the closed 20-cell grid plus a speed subtitle. No badges.
• 一句话复盘: how much it made or lost in the period, the single best strength, the single biggest problem.
• 下一步 (own wallet) / 参考建议 (someone else's): the single most actionable fix.

This shape is deliberate. It is designed for a small slot on an already number-heavy wallet page, where dense columns, badge rows, KPI lines or a detail popover read as noise next to the page's own numbers. Evaluate every rule, but let only the top strength, the top problem and the top fix reach the output. Don't add lines, badges or numbers unless the user asks.

Step 0 — Validate the input before any command

The address and chain go straight into shell commands, so check them first. Never "fix up" a string to make it pass.

• Chain must be one of sol bsc base eth arbitrum hyperevm robinhood arc stable. A base58 address is sol. A 0x… address could be on any of the eight EVM chains: if the user named one, use it; otherwise find it with the probe in Step 0a.
• Address: EVM must match ^0x[0-9a-fA-F]{40}$. Solana must match ^[1-9A-HJ-NP-Za-km-z]{32,44}$. Anything else (spaces, quotes, ;, $, a leading -) → say it isn't a valid wallet address and stop.
• 「CA」/「合约」/「代币」/ "token" / "contract" in the message → the user probably means a token. Ask which they want before running.
• Several addresses and no indication which → ask. Only a name or symbol → ask for the address.
• Pass the validated address as its own argument, and quote it in the shell.

Step 0a — Find the chain for a 0x address (only when the user didn't name one)

The same 0x address exists on every EVM chain, and many wallets trade on only one of them. Guessing BSC and reporting 「没有交易」 would be wrong for a Base or ETH trader, so probe first:

1. Run gmgn-cli portfolio stats --chain <c> --wallet W --period 30d --raw for all eight EVM chains (bsc, base, eth, arbitrum, hyperevm, robinhood, arc, stable), one after another, and take buy + sell from each.
2. Use the chain with the most 30D trades. If none has any, continue on bsc so the token-contract check in Step 2 can tell a contract or a transfer-only address from a wallet.
3. If a second chain also has ≥ 20 % of the winner's trades, add one line after the three lines: 「他在 {chain} 上也有交易，这里按 {chosen} 统计。」

Probe all eight, not the popular ones first. In a test of nine active wallets, several traded mainly on Robinhood or Arc while also showing a few hundred trades on BSC or Base: one had 5,227 trades on BSC and 24,691 on Robinhood. Stopping at the first chain with trades would have profiled the wrong book.

Each probe is one call. Stop probing on a rate limit, and use the best chain found so far if any trades were seen. A probe response is also the 30D stats for that chain, so reuse it rather than asking for it again in Step 2. Name the chain in the reply's title line when it wasn't given, e.g. （7D · Base）. Chain display names: BSC, Base, ETH, Arbitrum, HyperEVM, Robinhood, Arc, Stable, SOL.

Step 1 — Pick the voice

• self when the user talks about their own wallet: 「我的钱包」, 「我的打法」, 「我该怎么改」, "my wallet". other otherwise, which is the default. If it's genuinely unclear, ask.
• In the product this is decided automatically (logged-in wallet == page address). Here, infer it from how the user talks. Don't call portfolio info to guess: it only knows wallets bound to the API key and would misclassify the user's unbound wallets.

The voice changes more than the pronoun. For the owner, the advice is about their own play. For a visitor, telling them what a stranger should change is useless, so the same finding becomes guidance for the reader.

Step 2 — Pull the data

Save every response to a file in a temp directory so you can compute over it. Run the calls in this order; --raw gives single-line JSON.

Rules for pulling:

• Strip lines starting with [gmgn-cli] before parsing. That is the CLI's own injection-defense notice printed ahead of the JSON. A token in the wallet carried suspicious metadata; it is not an error.
• --limit above 50 silently falls back to 20. Always use 50 and paginate with next.
• Every numeric field is a JSON string. Convert before comparing.
• How to recognise a rate limit. It shows up as a failed command, with a non-zero exit and an error message mentioning 429 or RATE_LIMIT. It never arrives as a normal JSON body. Don't search the returned data for "429": prices, amounts and timestamps contain it all the time.
• Rate limits: one 429 / RATE_LIMIT stops everything. Make no further calls and don't retry; retries extend a RATE_LIMIT_BANNED ban. If calls 1–4 succeeded, continue without 5–6 and say those parts were skipped. If 1–4 did not finish, tell the user to wait for the reset time and stop.
• A rejected key stops everything too. config --check only confirms a key is present, not that GMGN accepts it. If a call fails with 401 / AUTH_KEY_INVALID, make no further calls, tell the user the API key was rejected and needs reconfiguring with gmgn-cli config, and give no tag or sentences. Don't run gmgn-cli config for them: it creates a new key pair.
• holdings needs critical auth (GMGN_PRIVATE_KEY). If it errors, fall back as described in Step 3d. Don't ask the user to configure a key just for this.
• Token contract check: if 7D buy+sell is 0, pnl_stat.token_num is 0, common.created_token_count is 0, and all-time profits buy is 0, the address has no trades at all. It is a token contract, a fresh wallet, or transfer-only. Say that and stop; do not invent a tag.

Step 3 — Compute

3a. Per-period numbers

7D and 30D come from stats ("full" periods). 1D and 全部 exist only in profits, so they have no win rate, fees or P&L buckets.

• tn = pnl_stat.token_num, the same field analyze.py and gmgn-wallet-style use (in live responses it equals the sum of the five buckets; use that sum only if token_num is missing).
• lt50 = pnl_lt_nd5_num ÷ max(1, tn) (share of tokens down more than 50%).
• small = pnl_nd5_0x_num ÷ max(1, tn) (share of tokens down 0–50%).
• A period with buy + sell = 0 has no reading. Show 「{period} 没有交易」 for it.
• The ROI of each window (1D / 7D / 30D / 全部) is needed for the decline rule.

3b. Behaviour sample (from activity; the same for every period)

Use only buy / sell rows; ignore transfers. Group rows by token.address.

• Round-trip time cw: per token, the time from the first buy to the first sell after it. Take the median across tokens. If fewer than 3 tokens have one, or the median is 0 s, there is no speed reading.
• flash5s: share of those round trips that took 5 seconds or less.
• Entry mcap: the median of price_usd × token.total_supply over buy rows, ignoring zeros.
• Payoff: per token with sells, sum cost_usd − buy_cost_usd over its sell rows. Payoff = average win ÷ average loss. It counts only when there are at least 5 winning and 5 losing tokens. Skip sell rows where buy_cost_usd is missing or empty; treating it as 0 turns every such sale into a pure win and inflates the payoff. Apply the same skip in the Step 3d fallback.

Never use pnl_stat.avg_holding_period. It counts positions that were never sold and overstates hold time by orders of magnitude on active wallets.

3c. Wallet-level facts

• follow = common.follow_count.
• created = common.created_token_count.
• graduated = created-tokens open_count. If call 5 failed, use 0 and skip the launcher rule.

3d. Holding-time split

Build one list of closed positions, each with (hold seconds, realized $, cost $):

• From holdings (preferred): rows with start_holding_at > 0, end_holding_at ≥ start_holding_at, and history_total_sells > 0. Hold = end − start, realized = realized_profit, cost = history_bought_cost.
• Fallback, if fewer than 30 such rows: from activity, per token that has both buys and sells. Hold = last sell − first buy, realized = Σ(cost_usd − buy_cost_usd) over sells, cost = Σcost_usd over buys.
• If still fewer than 30 positions, skip the split.

Put positions into four groups: 「不到 1 分钟」 (≤60s), 「1–30 分钟」 (≤30 min), 「30 分钟到 6 小时」 (≤6 h), 「超过 6 小时」. For each group compute n, share of positions, and ROI = Σrealized ÷ Σcost.

• W = the group with the largest share.
• B = among the other groups with n ≥ 10, the one with the highest ROI.
• The split fires only if W's share is ≥40%, W's ROI is <5%, B's ROI is ≥15%, B's ROI is ≥ 5 × max(W's ROI, 0.001), and B's realized total is >0.

Choose by ROI and count, never by dollar totals. holdings P&L is cumulative per token, so a few long-held large caps can dominate the dollars and point at the wrong group.

3e. Trading discipline (from holdings only; the same for every period)

Use the same closed positions as 3d, from holdings only. The activity fallback is too thin for these, so if holdings gave fewer than 30 closed positions, skip all four. Winners have realized_profit > 0, losers < 0, and hold = end_holding_at − start_holding_at.

B must use the per-buy ticket, never history_bought_cost itself. That field is cumulative volume: a tokenized stock traded hundreds of times shows $248K of "cost" on a $75 loss, and the mean over such rows made B fire on six of six test wallets that in fact sized every buy the same. Use the median for the same reason.

The $50 floor in D keeps dust out: a wallet that snipes hundreds of tiny launches is left holding dozens of worthless crumbs, which says nothing about its loss-cutting.

Hold times in sentences: <60s → N 秒, <1h → N 分钟, <1d → X.X 小时, otherwise X.X 天.

Step 4 — The tag

The tag rules below are the same as freq_level / pnl_level / style_title / style_speed in gmgn-wallet-analysis/analyze.py (and gmgn-wallet-style), so a wallet gets the same title whichever skill the question lands on. The single deliberate difference is the L4 净盈 line (see below). If you change a threshold here, change it there too.

Too few tokens → no reading. If the period's tn is below 5 (for 1D and 全部, use the 7D tn), there is no tag, recap or next step for that period. Output 「{period} 交易太少（不足 5 个币）， 暂不给结论」 instead, the same "no read" the production dossier gives a sub-5-token wallet.

Frequency perDay = (buy + sell) ÷ days → L1 <1, L2 <10, L3 ≤50, otherwise L4 (exactly 10 trades a day is L3; exactly 50 is L3).

P&L, first match wins:

1. P5 — full period ∧ pnl > 0.5 ∧ tn ≥ 5 ∧ (winrate ≥ 0.5 or lt50 < 0.15 — one corroborating shape is enough). Memecoin P&L is low-hit-rate with a fat right tail; requiring both drops genuine top performers to P4.
2. P4 — pnl > 0.1, or L4 ∧ pnl > 0.03 ∧ realized > 0
3. P1 — full period ∧ lt50 ≥ 0.4 ∧ realized < 0
4. P3 — |pnl| ≤ 0.1
5. P2 — realized < 0 or pnl < 0
6. otherwise P3

The L4 exception exists because 全自动P机 means exactly "thin margin, huge volume". A machine-speed wallet re-buys constantly, which inflates cumulative cost and keeps its ratio low even when it is clearly making money: one wallet made $73K in a week at 8.4%. 磨损户 is kept for machine-speed wallets whose ratio is near zero or negative, where fees really do take the gains back. This threshold is specific to this skill; gmgn-wallet-style and analyze.py still use 10% for every level, so at machine speed with a 3–10% ratio this skill says 全自动P机 where they say 磨损户.

Speed from the median round trip: <60s ⚡ 秒杀流, <24h 🐇 日内流, <7d 🧭 波段流, otherwise 💎 长持流. Omit it if there's no speed reading, i.e. fewer than 3 round trips or a median of 0 s.

Tone (for rendering): P4/P5 win, P3 flat, P1/P2 loss.

Step 5 — Recap and next step

Number formats

• Money: ≥1M → $1.23M; ≥1K → $73.0K; <20 → $12.3; otherwise $456. Always the absolute value; 赚了 / 亏了 carries the sign.
• Percent: below 10% → one decimal (3.3%); otherwise a whole number (32%).
• Followers: ≥10,000 → N 万 rounded (99,586 → 10 万); otherwise with commas.
• Seconds (the round-trip time in the fast sentence): a whole number, rounded half up (9.5 → 10).
• Windows: 1D → 近 24 小时 · 7D → 近 7 天 · 30D → 近 30 天 · 全部 → 累计.

Strength (first match, may be none)

1. 止损干脆 — full period ∧ tn ≥ 5 ∧ lt50 < 0.05 ∧ neither hold_losers nor bag_hold fired (they say the opposite, and 「止损干脆，但亏的单拿得比赚的单久」 contradicts itself)
2. 胜率 X% — full period ∧ tn ≥ 5 ∧ winrate ≥ 0.6 (a wallet with two closed tokens both up is not a 100% win rate worth stating)
3. 盈亏比 X.X : 1 — payoff exists and ≥ 2