◉ ChainSentry

链上数据工具全景：免费 API 与它们的能力边界

工具

做链上监控绕不开数据源。这篇是实测记录——哪些免费 API 真正可用，各自的能力边界在哪，以及踩过的坑。

所有结论基于实际调用，不是文档摘抄。

一、发现新池子：最大的难点

想监控"新上线的币"，第一个问题就是：怎么知道有新池子？

这个需求听起来简单，但免费 API 里能满足的不多。

DexScreener

最知名的免费数据源，覆盖广、数据全。但有个关键限制：

GET /latest/dex/search?q=<关键词>

这个端点返回的结果按相关性而非时间排序，而且不包含最新创建的池子。

实测数据：用 pump、SOL、bonk、new 四个词分别搜索，去重后得到 120 个独立交易对。其中上线时间中位数是 4,761 小时（约 198 天），24 小时内的只有 5 个。

也就是说，用 DexScreener 的搜索端点做新池发现，基本不可行。

另外它的 /token-pairs/v1/{chain}/{token} 端点返回的数据里缺少 liquidity、fdv、marketCap 字段，只有价格和交易笔数。做筛选不够用。

好消息是 /latest/dex/pairs/... 和 /latest/dex/search 端点数据是完整的，包括 liquidity.usd、volume、priceChange、pairCreatedAt。限流约 300 req/min，很宽松。

结论：DexScreener 适合查已知代币的详情，不适合发现新池。

GeckoTerminal

真正能用的新池发现工具。两个关键端点：

GET /api/v2/networks/{network}/new_pools
GET /api/v2/networks/{network}/trending_pools

new_pools 按创建时间倒序，返回最近 20 个池子。这正是需要的。

返回字段很完整：

{
  "address": "池子地址",
  "name": "ICAT / SOL",
  "pool_created_at": "2026-09-13T11:04:55Z",
  "base_token_price_usd": "...",
  "fdv_usd": "121062.2516",
  "reserve_in_usd": "0.248",
  "volume_usd": { "m5": "...", "h1": "...", "h24": "..." },
  "price_change_percentage": { "m5": "...", "h1": "...", "h24": "..." },
  "transactions": {
    "h1": { "buys": 1, "sells": 0, "buyers": 1, "sellers": 0 }
  }
}

reserve_in_usd 就是流动性，transactions.h1.buyers 就是独立买家数——这个字段很关键，是做刷量识别的核心。

支持 100 个网络，常用的都覆盖：solana、base、eth、bsc、arbitrum、polygon_pos、ton。

但是限流很紧。

官方文档没有明确说明免费额度。实测：

限流 25 req/min → 大量 429
限流 10 req/min → 稳定

而且即使在 10 req/min 下，连续请求 8 个端点（4 链 × 2 类型）仍会遇到 429。需要配合长退避：5s / 15s / 30s / 60s。

结论：唯一可用的免费新池源，但必须严格控制调用频率。适合低频扫描（2 分钟一轮），不适合高频。

二、合约风险：两个免费方案

Solana → RugCheck

GET https://api.rugcheck.xyz/v1/tokens/{mint}/report/summary

返回风险评分、风险项列表、持币集中度、LP 锁仓比例等。

重要坑点：对新上线的代币，经常返回：

HTTP 400 {"error": "unable to generate report"}

这是索引延迟，不是错误配置。新币创建后 RugCheck 需要时间分析。

这个坑的严重性在于：如果代码把"请求失败"当作"没有风险"，就会给一个新币打上"低风险"标签——严重误导。

正确处理：查不到就标记「风险未检测」，绝不默认安全。

另一个端点 /v1/stats/recent 返回最近被查询的代币，带 user_visits 和 visits 字段，可以当作关注度代理指标使用。

EVM → GoPlus

GET https://api.gopluslabs.io/api/v1/token_security/{chain_id}
    ?contract_addresses={address}

支持多链（1=Ethereum, 56=BSC, 137=Polygon, 42161=Arbitrum, 8453=Base 等）。

返回的检测项很全：

字段 含义
is_honeypot 蜜罐
cannot_sell_all 无法全部卖出
transfer_pausable 可暂停转账
is_blacklisted 黑名单功能
is_mintable 可增发
owner_change_balance owner 可改余额
hidden_owner 隐藏 owner
slippage_modifiable 税率可修改
personal_slippage_modifiable 个人税率可修改
buy_tax / sell_tax 实际税率

注意：所有布尔字段用字符串 "0" / "1" 表示，不是真正的 boolean。这个坑很容易踩。

限流约 30 req/min，够用。

结论：EVM 侧风控的最佳免费方案，覆盖全面。

三、实测对比

源 新池发现 风控 限流 稳定性
GeckoTerminal ✅ 最佳 ❌ ~10/min ⚠️ 好
DexScreener ❌ 不可用 ❌ 300/min 好
RugCheck ❌ ✅ Solana 宽松 新币延迟
GoPlus ❌ ✅ EVM 30/min 好

实际架构：

GeckoTerminal  → 发现新池 + 基础指标
      ↓
按链分流
      ↓
Solana → RugCheck  ┐
EVM    → GoPlus    ┘ 风控一票否决
      ↓
评分 → 推送

四、其他踩坑记录

Python 环境混乱。 系统里有两个 Python：

which python → 3.13.12（实际生效）
pip          → 3.11 的 site-packages

结果 pip install pyyaml 成功了，但 import yaml 还是失败。解法：始终用 python -m pip install。

标准库够用。 一开始想用 requests，但标准库的 urllib 完全可以胜任，还省掉一个依赖。配合 json 和自定义的重试逻辑，代码量差不多。

429 要单独处理。 指数退避（2s/4s/8s）对 429 不够——对方需要更长的恢复时间。改成针对 429 用固定梯度退避（5s/15s/30s/60s），其他错误才用指数退避。

去重必须在内存和磁盘两层。 每轮扫描 2 分钟，同一个池子会在多轮里重复出现。用带 TTL 的键值表去重（key = chain:pool_address），12 小时过期。同时要处理"同一个池子命中多类信号"的情况——按池地址聚合，只保留最高分的一条。

五、边界与限制

诚实地说清这套方案的局限：

没有实时链上事件流。 上面所有数据源都是轮询式的，最小粒度 2 分钟。真正的实时监控需要 RPC 订阅（logsSubscribe / newHeads），目前没启用。

新币的早期数据是空的。 池子创建后最初几十秒，多数 API 还没索引到。如果要做秒级抢跑，这套方案不行。

风控有滞后。 RugCheck 对新币的报告延迟从几分钟到几十分钟不等。这个窗口期就是风险敞口。

免费限流是硬约束。 想扩大覆盖面（更多链、更高频率），必须付费或自建节点。

最后

免费数据源能支撑起一个可用的链上监控系统，前提是接受它的边界：

这些限制不影响它做一件有价值的事：把人工需要几分钟的筛选流程，变成自动化的持续监控。

对绝大多数使用者来说，这就够了。真正需要毫秒级优势的场景，本来也不是免费工具能解决的。