过去半个月，我一直在做一件事：把“链上抓金狗”这个行为，从拍脑袋升级成一套可以重复执行的监控筛选流程。先说结论：所谓“金狗”，本质是极短时间内完成流动性注入、持币地址增长和市场热度扩散的新代币，链上数据确实能提前暴露一部分信号。但这里必须先划一条线——本文只讲数据采集、指标筛选、脚本监控和复盘方法，不构成投资建议，更不保证任何代币会上涨。加密货币市场波动极大，绝大多数新项目会归零，请务必遵守所在地法律法规。
这次复盘不是在喊单，而是把过去半个月的链上数据监控方式整理成一套可落地的技术方案。文章会覆盖：哪些指标值得监控、怎么用 Python 批量拉取链上数据、如何设计异动筛选规则、定时任务怎么调度、数据延迟和 API 限流怎么处理，以及为什么我不建议把“抓到金狗”当成可持续策略。无论你打算做数据分析、写监控机器人，还是单纯想理解链上数据怎么用，这套流程都能直接参考。
1. 核心能力速览
先给一张总表，把这套链上监控方案的关键信息列清楚。
| 能力项 | 说明 |
|---|---|
| 数据来源 | 公共 RPC 节点、区块浏览器 API、DEX 行情接口、链上数据平台 |
| 核心功能 | 新代币部署监控、流动性池变化跟踪、巨鲸转账预警、持币地址增长统计 |
| 选型门槛 | 中等；需要 Python 基础，能够理解 JSON 返回值和基础 SQL |
| 硬件要求 | 一个 2 核 4G 的小服务器即可，数据查询接口不依赖本地 GPU |
| 启动方式 | 命令行运行 Python 脚本，配合 cron 或系统定时任务 |
| API 能力 | 支持调用公开 JSON API，返回结构化数据，便于二次开发 |
| 批量任务 | 支持；可以通过脚本轮询多个地址、多个交易对、多个区块范围 |
| 数据延迟 | 取决于数据源；公共 RPC 和 DEX API 通常有几秒到几分钟延迟 |
| 适合场景 | 链上异动观察、数据分析、自动化监控、量化信号预处理 |
| 不适合场景 | 承诺收益的投资建议、无风险套利、对时效性要求极高的抢跑策略 |
从材料看，这类监控流程最大的价值不是“预测金狗”，而是把市场上已经发生的异动，用数据化的方式记录下来，再结合交易量、持有者分布、合约安全性等维度做二次筛选。技术本身是中性的，关键在于使用边界和执行纪律。
2. 适用场景与使用边界
这套链上监控方案适合几类人：一是做区块链数据研究的技术人员，需要批量采集链上数据做统计；二是交易辅助工具开发者，想把代币异动作为信号接入自己的风控或提醒系统；三是对链上数据感兴趣的产品经理，想理解新代币从部署到热度扩散的完整链路。
它能解决的问题也很明确：新代币什么时候部署、流动性池什么时候建立、大额转账发生在哪个区块、持币地址数在短时间内增长了多少倍。这些数据都是公开的，不需要访问任何私有信息，也不需要特殊权限。
不适合什么？如果你指望它“自动抓金狗”然后就能稳定盈利，这个方向本身就值得警惕。链上数据只能反映历史事实和当前状态，不能预测未来价格。很多异动代币在数据上表现相似，但最终结果天差地别，有的短期拉升后迅速归零，有的则因为合约漏洞被攻击。数据监控可以给你提供候选池，但最终的风险判断必须由你自己完成。
安全边界在这里非常重要。所有数据采集必须使用公开、合法、合规的数据源，不要试图绕过任何平台的风控限制，不要批量抓取需要授权的私有接口。涉及合约交互时，不要在未审计合约上投入真金白银。更要强调的是，任何市场行为都要遵守所在地法律法规，本文不构成任何投资建议。
3. 链上监控的环境准备
环境准备不需要很强的机器，重点是把 Python 环境和数据源配好。
3.1 基础环境清单
建议准备一台 Linux 服务器，Ubuntu 22.04 或 Debian 12 都可以。如果你只是想本地测试，Windows + WSL 也能跑通。核心依赖有：
- Python 3.10 或更高版本
requests库，用于调用 HTTP JSON 接口web3.py，用于连接 RPC 节点读取链上数据pandas，用于处理筛选结果python-dotenv，用于管理 API Key 等敏感配置
虚拟环境建议用venv或conda隔离，避免污染系统 Python。
3.2 数据源准备
数据源是整套监控的基座。从公开渠道可以获取的数据源包括：
| 数据源类型 | 说明 |
|---|---|
| 公共 RPC 节点 | 读取区块高度、交易详情、合约调用信息；延迟受节点负载影响 |
| 区块浏览器 API | 获取地址交易列表、代币持有者、合约状态；通常需要注册 API Key |
| DEX 行情 API | 获取新交易对、流动池实时数据、价格变化；适合做异动初筛 |
| 链上数据平台 | 提供更丰富的聚合指标，但部分功能需要付费 |
RPC 节点建议优先使用自己的节点，或者使用服务商提供的稳定节点，避免使用一个公共 RPC 地址扛所有流量。API Key 要放到环境变量中，不要直接写死在代码里。
3.3 项目目录结构
建议一开始就建立清晰的目录，方便后面扩展。
onchain-monitor/ ├── config/ │ └── config.yaml ├── scripts/ │ ├── fetch_blocks.py │ ├── check_pools.py │ └── screening.py ├── data/ │ ├── raw/ │ └── output/ ├── logs/ │ └── monitor.log ├── .env └── requirements.txtdata/raw放原始接口返回，data/output放筛选后的结果，logs放运行日志。这套结构虽然简单，但能避免后期数据和脚本混在一起。
4. 数据源与监控指标设计
监控脚本只是工具，真正决定效果的是指标设计。过去半个月我重点跟踪的指标分四类：新合约部署、流动性池变化、持币地址分布、巨鲸转账行为。
4.1 新合约部署信号
新代币通常意味着新合约部署。通过监听区块链上的合约创建事件，可以第一时间发现潜在目标。这里的核心是过滤掉大量垃圾合约，只看有初始化流动性池的合约。
可以关注的数据包括：
- 合约部署时间与区块高度
- 合约是否开源
- 创建者的历史行为
- 代币总量和初始分配
这类数据可以从 RPC 节点和区块浏览器 API 获取。注意，很多新合约会刻意隐藏信息，不要只看表面数据。
4.2 流动性池变化
流动性池是代币能够交易的前提。一个代币如果建立了交易对，通常意味着项目方开始引入外部资金。重点监控：
- 交易对创建时间
- 初始流动性金额
- 流动性锁定期限
- 交易量变化与池深比值
流动性池数据可以直接从 DEX 行情接口读取，返回结果通常是 JSON，便于脚本清洗。
4.3 持币地址数量增长
持币地址数增长反映的是筹码分散速度。短期内地址数快速增长，说明热度在扩散；但如果地址增长超前于流动性增长，可能是人为刷量或者空投活动导致，不能直接当作利好。
判断方法很简单：拿今天的持币地址数去对比昨天的数据，计算增长率。重点关注持币 Top10 地址的占比是否异常集中。
4.4 巨鲸转账行为
巨鲸转账是最直接的链上异动信号。大额代币转入交易所，可能意味着抛压；大额转出交易所，可能是项目方做市或锁仓。监控时优先关注：
- 转账金额是否超过持币总量的 1%
- 目标地址是合约地址还是交易所地址
- 转账时间和区块间隔
这四种指标组合在一起，才能构成一个相对完整的异动筛选框架。只靠单一指标很容易被误导。
5. 数据采集脚本示例
数据采集脚本是整套链路的第一步。这里给出通用示例，实际接口地址和参数以你的数据源官方文档为准。
5.1 连接 RPC 节点读取最新区块
from web3 import Web3 # 示例公共 RPC，实际请使用自己的节点或服务商地址 RPC_URL = "https://eth.llamarpc.com" w3 = Web3(Web3.HTTPProvider(RPC_URL)) print("Connected:", w3.is_connected()) print("Latest Block:", w3.eth.block_number)跑通后，你可以继续扩展，比如监听指定区块范围内的合约创建事件。注意公共 RPC 有速率限制，大批量查询建议升级到付费节点或自建节点。
5.2 调用 DEX 行情接口获取新交易对
这里以常见的 DEX 行情接口为例，展示如何批量查询交易对信息。具体 URL 和参数请以官方文档为准。
import requests # 以 DEX 行情聚合服务为例，实际接口以官方文档为准 API_URL = "https://api.dexscreener.com/latest/dex/search" params = {"q": "WETH"} # 替换为实际查询参数 headers = { "Accept": "application/json" } try: response = requests.get(API_URL, params=params, headers=headers, timeout=15) data = response.json() print("Pairs found:", len(data.get("pairs", []))) for pair in data.get("pairs", [])[:5]: print(pair.get("pairAddress"), pair.get("liquidity", {}).get("usd")) except requests.exceptions.RequestException as e: print("Request failed:", e)运行后如果有返回结果，说明网络和数据源配置正常。接下来就可以把返回结果接入筛选流程。
5.3 通过区块浏览器 API 统计持币地址
区块浏览器 API 通常返回 JSON 格式的持有者列表。示例代码如下：
import requests import time # 替换为你的 API Key 和实际合约地址 API_KEY = "YOUR_API_KEY" CONTRACT_ADDRESS = "0xYourTokenContractAddress" BASE_URL = "https://api.etherscan.io/api" payload = { "module": "token", "action": "tokenholderlist", "contractaddress": CONTRACT_ADDRESS, "page": 1, "offset": 100, "apikey": API_KEY } response = requests.get(BASE_URL, params=payload, timeout=20) data = response.json() if data.get("status") == "1": holders = data.get("result", []) print("Holder count:", len(holders)) for holder in holders[:5]: print(holder.get("TokenHolderAddress"), holder.get("TokenHolderQuantity")) else: print("Error:", data.get("message"))这个接口对速率限制很敏感，批量查询时必须加入退避重试逻辑，否则很容易被封。
5.4 定时任务调度
数据采集脚本写好之后，用 cron 定时运行。这里给出一个典型的 crontab 配置示例，每 10 分钟跑一次主监控脚本。
# crontab -e */10 * * * * cd /opt/onchain-monitor && /usr/bin/python3 scripts/screening.py >> logs/monitor.log 2>&1如果脚本运行时间超过 10 分钟，建议改用重叠保护机制，避免两个任务同时跑导致的数据冲突。
6. 异动筛选规则：从数据到候选池
采集到原始数据后，下一步是根据规则筛选出候选池。筛选规则不需要很复杂，但要具备可解释性，方便回溯问题。
6.1 规则引擎设计
我把筛选规则拆成四层，按顺序执行：
# 伪代码示例，具体阈值需要根据实际市场情况调整 def screening(token_data): # 第一层：基本面过滤 if token_data["is_verified"] is not True: return False # 第二层：流动性门槛 if token_data["liquidity_usd"] < 100000: return False # 第三层：持币地址增长 if token_data["holder_growth_24h"] < 0.2: return False # 第四层：巨鲸异动标记 if token_data["large_transfer_count"] < 1: return False return True每层的阈值都可以配置化，不一定要用代码写死。更稳妥的做法是把规则配置放到 JSON 或 YAML 文件中，方便调整。
6.2 最小运行配置示例
{ "minimum_liquidity_usd": 100000, "holder_growth_24h_threshold": 0.2, "large_transfer_threshold_usd": 50000, "min_pair_age_hours": 1, "max_pair_age_hours": 72 }这份配置表示：候选代币的流动性至少 10 万美元，24 小时持币地址增长率超过 20%，存在超过 5 万美元的大额转账，且交易对创建在 1 到 72 小时之间。这样的候选池通常不会太小，也不会把明显没有交易基础的代币放进来。
6.3 筛选结果输出
筛选结果建议直接输出为 CSV 或 JSON 文件，方便后续处理。
import pandas as pd # results 是筛选后的字典列表 df = pd.DataFrame(results) output_path = "data/output/candidates.csv" df.to_csv(output_path, index=False, encoding="utf-8-sig") print(f"Saved {len(df)} candidates to {output_path}")7. 过去半个月的复盘流程
回到标题：过去半个月，我是怎么把这套流程跑起来的？这里梳理一个完整的时间线和方法论，不讲具体代币名称，只讲流程。
7.1 第 1 周：数据源接入与信号验证
第一周的核心工作是把数据源接通。我先后测试了公共 RPC、区块浏览器 API 和 DEX 行情接口，发现最大的瓶颈并不是接口延迟，而是数据口径不一致。同一个代币在不同平台上的持币地址数可能相差很大，原因是不同平台对“持有”的定义不同，有的包含锁仓地址，有的不包含。所以第一周我把重点放在数据校验上，没有急着加筛选规则。
7.2 第 2 周：规则迭代与误报压低
第二周开始跑初版筛选规则。最初版本只有流动性和持币地址数两个指标，候选池里混入了大量刷量代币和貔貅盘。经过数据回溯后发现，这些代币有明显的共同特征：持币地址数增长快，但交易对创建时间极短，流动性池在几小时内就被撤走。于是我在规则里加入了“交易对年龄”和“流动性变化率”两个维度，误报率明显下降。
7.3 复盘结果如何看
复盘时不要只看“后来涨没涨”，更要看筛选出的候选池中，有多少代币在 24 小时内出现了明显的链上活跃度提升，比如交易量放大、持币地址持续增长、流动性池稳定。这才是数据监控能做到的事情。至于最终价格表现，属于市场行为，受情绪、宏观环境、项目方操作等多种因素影响，链上数据无法覆盖。
8. 资源占用与性能观察
链上监控脚本的资源占用不高，但需要注意几个容易忽略的瓶颈。
| 观察项 | 说明 |
|---|---|
| CPU 占用 | 常规轮询脚本占用很低，1 核 CPU 足够；如果做批量历史数据回填，会明显上升 |
| 内存占用 | 缓存大量 JSON 响应时需要关注，建议每批处理后释放变量 |
| 网络带宽 | 高频轮询会连续请求接口，带宽占用小但对连接数有限制 |
| API 限流 | 公共接口通常有每分钟请求数限制，需要做退避重试 |
| 节点同步 | 自建 RPC 节点需要一定硬盘空间，同步速度取决于网络 |
性能优化的核心思路是减少请求次数。比如获取 100 个代币的交易对信息时，与其逐个请求，不如看接口是否支持批量参数。再比如持币地址数据，可以每天只拉一次，而不是每次轮询都拉。
另外，建议把日志级别调成 INFO，记录每次请求耗时和失败原因。这样一旦某个数据源挂了，可以立刻定位是接口问题还是代码问题。
9. 常见问题与排查方法
过去半个月踩了不少坑，这里按现象整理成排查表。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| RPC 连接失败 | 公共节点负载高或 IP 被限 | 检查is_connected()返回值 | 切换备用 RPC，或更换服务商 |
| API 返回空数据 | 请求参数错误或接口调整 | 直接用浏览器打开接口地址测试 | 对照官方文档检查参数格式 |
| 持币地址数异常偏高 | 包含空投合约或锁定地址 | 查看 Top10 地址类型 | 增加地址类型过滤规则 |
| 候选池误报多 | 规则阈值过宽 | 回溯最近 10 个候选代币的走势 | 加严流动性门槛和年龄限制 |
| 脚本运行到一半卡死 | 一个接口超时没有设置 timeout | 查看日志中的卡住位置 | 所有请求统一设置 15 秒超时 |
| cron 任务重复执行 | 脚本运行时间超过调度周期 | 查看进程列表是否有多个实例 | 使用文件锁或单实例保护 |
| 定时任务不执行 | cron 环境变量或路径不正确 | 手动执行一次脚本 | 在 crontab 中使用绝对路径 |
| 输出文件乱码 | CSV 编码问题 | 用文本编辑器查看文件 | 写入时使用 utf-8-sig 编码 |
10. 最佳实践与合规提醒
10.1 工程化建议
第一条建议是保持规则可配置。不要把所有筛选逻辑都堆到一个函数里，而是把阈值和参数放到配置文件中，方便随时调整。
第二条是保留原始数据。链上监控的结论需要事后验证，如果筛选结果最终被证明是错的，可以通过原始数据回溯是哪一步出了问题。原始 JSON 建议按日期压缩存储，比如每天一个目录。
第三条是接口调用要加缓存。对于短时间窗口内重复请求的相同数据，可以在内存中缓存 30 到 60 秒，减少对数据源的请求压力。
第四条是监控脚本自身也要有日志和告警。如果数据采集中断了几个小时，意味着你完全处于“盲区”，这时候需要脚本主动告警，而不是等问题发生后再去查日志。
10.2 必须注意的合规与风险边界
这个方法论的目的是技术研究和数据观察，不是喊单。
- 不要在未审计合约上投入大额资金。
- 不要跟随链上“大额转账”盲目操作，很多转账是项目方自己做市。
- 不要使用任何非公开接口、抓取工具或绕过风控限制的手段。
- 涉及任何国家或地区的交易行为，务必确认其合法性，并严格遵守当地法律。
- 链上数据分析结果不能作为投资建议，所有决策责任由操作者自行承担。
11. 总结与下一步
这套链上监控方案，最值得尝试的点是把一个听起来很玄学的“抓金狗”问题，拆解成了四个可量化的指标：合约部署、流动性池、持币地址、巨鲸转账。指标拆开后，剩下的就是数据采集、规则筛选和定时调度，每步都有标准做法。
如果第一次尝试，建议先跑最小配置：只接入 DEX 行情接口，监控新交易对，记录流动性池和交易量数据，跑一周后再决定要不要增加持币地址和巨鲸监控。第一个最容易踩的坑是数据口径不统一，所以开始前先花时间做接口返回值的字段校验。
接下来可以继续扩展的方向很多：接入更多链上数据平台做聚合分析、把筛选结果推送到钉钉或飞书机器人、加入历史数据回测来评估规则有效性、甚至把候选池结果导出到可视化面板。只要数据源稳定、规则可解释，这套流程完全可以成为你自己的链上数据基础设施。
