记录一次 GMGN 接口的摸底（2026-06-07）

平台真正的能力边界，从来不在文档里

前一天的教训还热着：trenches 有个 type=completed，文档里没写，但返回的是全网热榜，而前十轮调优一直在最冷的数据源里打转。

所以这天不干别的，把 GMGN 到底有什么接口，从头到尾摸一遍。

为什么不能信文档

用第三方数据源做量化，最大的成本从来不是写代码，而是搞清楚它到底能给你什么。

文档的问题有三个：漏的（有的端点根本没写）、错的（写了但已经不返回数据了）、含糊的（写了但字段含义和你以为的不一样）。而交易系统对这三件事全都零容忍——字段理解错一个，整套策略就是反的。

所以这一天的原则很简单：文档只当线索，结论必须自己打出来。

摸的办法：从 npm 包里挖

官方客户端 [email protected] 是个 npm 包。它在服务器上跑，跟服务端保持一致——所以它里面写的路径，就是真实存在的路径。

装一个干净的探测目录：

1
mkdir _npm_probe && cd _npm_probe && npm init -y && npm install gmgn-cli

然后 npx gmgn-cli <cmd> --help 看参数。有一个细节差点卡住：npm 不自动走代理，必须显式带上 HTTPS_PROXY=http://127.0.0.1:7890，否则连不上。

27 个能用的端点

最后打出来 27 个全部 HTTP 200、code=0 的端点。挑几个关键的：

GET /v1/market/rank —— 热榜。支持 chain=sol/bsc/base，interval=1m/5m/1h/6h/24h，limit<=100，还能按 orderby、filter、platform 筛。返回 95 个字段，成交量、流动性、买卖笔数、持有人数、sniper 数、聪明钱数、KOL 数、是否蜜罐、是否刷量，全在里面。

这个端点后来被证明比之前用的 trenches completed 更好用——因为它的时间粒度可切。

POST /v1/market/token_signal —— 智能信号。按 signal_type 分组查询，每组返 50 条。

POST /v1/trenches —— 新版同时支持三种类型：new_creation + near_completion + completed。不过实测 near_completion 在 sol 上是 0 条（大概都已经毕业了），bsc / base 待验。

其余还有：/v1/token/info（详情）、/v1/token/security（安全指标：蜜罐、rug 比率、top10 持仓）、/v1/token/pool_info（流动性池）、/v1/market/token_top_holders（top 持有人）、/v1/market/token_top_traders（top 交易者，可按 smart_degen / renowned / sniper 打标签）、/v1/user/smartmoney 和 /v1/user/kol（平台定义的聪明钱和 KOL 名单）、/v1/user/created_tokens（创作者发币历史，带 open_count / open_ratio）、/v1/user/wallet_stats（钱包 7 日 / 30 日 PnL）、/v1/trade/gas_price、/v1/cooking/statistics（9 个 launchpad 平台统计）等等。

还有一类是需要签名鉴权的（带 GMGN_PRIVATE_KEY）：跟单钱包交易、钱包持仓、swap、报价、创建代币。这类没私钥调不了，先记着。

三条死路

同样重要的是打不通的那些。实测有 70 多个端点 404，包括 /v1/rank/*（老版本，现在用 /v1/market/rank）、/v1/wallet/*（老版本，现在用 /v1/user/wallet_*）、/v1/launchpad/*（现在用 /v1/cooking/*）、/v1/search、/v1/sol/priority_fee 等等。

它们在 npm 包里曾经出现过，config.json 里还提过——但服务端已经不实现了。这就是"文档写了但没用"的典型：只看名字，你会以为有这些能力，写进代码才发现全是 404。

两个信号：type 分布里的怪事

token_signal 的探测结果里有两个值得记的细节：

  • type 1/3/5/6/7/8/9/10/11/12/13/17/18 —— 每个都返 50 条（满额）
  • type 2 —— 只返 4 条
  • type 4 —— 返 0
  • type 14/15/16 —— 报错，服务端不认

type 2 只返 4 条这件事，当时没研究出它到底是什么（trigger_mc 落在 1 万到 50 万之间，可能是"大额买入"或"KOL 信号"）。但它很显眼——在一个所有类型都满额的列表里，突然出现一个只有 4 条的，说明它的触发条件极其严格。严格就意味着稀缺，稀缺就可能意味着价值。

这个没结论的发现被记了下来。有些线索当时用不上，但它标注了一片值得以后回头看的地方。

从摸底到落地

摸完之后立刻就能用上了，方向有三条：

  1. combo 入口加一道"是否在 1 小时热榜前 30"的判断 —— 用 /v1/market/rank 的 1h 榜、按 volume 排序取前 30 入库
  2. 加"信号出现次数 ≥ 3"的软信号 —— 用 token_signal 的 type [1,5,7]（价格突涨 + 大单 + 聪明钱）做交叉
  3. 给创作者历史降权 —— 把 creator_open_ratio 入仓，创作者过往成功率低于 30% 就直接降权（这条来自 /v1/user/created_tokens，是之前完全没利用过的维度）

第三条我特别喜欢，因为它是**从"这个币长什么样"转向"发这个币的人是谁"**。同一个币的形态可以伪装，但一个地址连续发币的成功率伪装不了。

那段不太肯认的数据

同期部署的是 v1.13，接入了新币、聪明钱、smart_degen、sniper 等几条信号线，平均单笔亏损从 −5U 收窄到 −1U 级别。

第一版统计出来是：**61 笔，净 +39.12U，胜率 41%**。看着像终于翻身了。

但再核对一遍，发现了问题：其中有一笔 95U 的异常单。

把这笔剔掉之后，真实情况是：60 笔，净亏 −56U。

也就是说，那 39U 的"利润"，完全是由一笔异常单撑起来的。真实水平是亏的。

这件事对我的触动比任何一次技术排障都大。因为如果当时不看第二遍，这份数据就会被当成"v1.13 是个成功版本"存档，然后基于它继续往上叠策略——在一个错误的结论上盖楼。

所以那天把这条也写进了记录：统计口径必须能剔除异常单。不是事后找理由，而是**在下结论之前，先问一句"这个结果是不是被某一笔撑起来的"**。一笔异常单能翻转整体盈亏的时候，样本量本身就在喊"还不够"。

最后

那天的收获分三层。

最表面的是那 27 个端点——一份可以直接用的能力清单。

中间一层是那条工作方法：对着官方客户端的源码去探，而不是对着文档去信。文档会滞后，代码不会。而且这个方法是可以复用的——换任何一个有官方客户端的平台，都是同一套打法。

最里面一层，是那份"剔除异常单"的自我要求。

技术活做久了，最大的风险从来不是写错代码，而是在自己的数据里挑自己想看的。策略跑出 +39U 的时候，人是有倾向性的——你会先接受它，然后才去想那个异常单的事。而一个交易系统最不能有的，就是这种倾向。

那天之后我把这条当成了硬规矩：先把难听的那部分算出来，再决定要不要高兴。