最近 Robinhood Chain 的链上热度明显起来了。2026 年 8 月底,Robinhood Chain 的链上交易活跃度出现明显增长。8 月 30 日,Robinhood Chain 单日处理交易数量达到约 552 万笔,DEX 单日交易量约 8.75 亿美元。与此同时,新 Token 的发行速度也开始快速增长,仅 Pons 一个发行平台当天就创建了约 22,600 个 Token。对于普通用户来说,看到的可能只是 Robinhood Chain 最近新币很多、交易很活跃。但对于量化开发者来说,更值得关注的是另外一个问题:能不能让程序直接监听 Robinhood Chain,在一个新的 Uniswap Pool 出现时第一时间发现它?
答案是可以。
而且我们不需要不断刷新网页,也不需要依赖第三方的新币推送网站。只需要通过 Robinhood Chain 的 JSON-RPC 接口直接读取链上事件,就可以从数据源头捕获新 Pool。本文将使用 发明者量化 FMZ,通过 Robinhood Chain 提供的 JSON-RPC 接口连接主网,并监听 Uniswap V4 PoolManager 合约,从零开始搭建一个 Robinhood Chain 新池雷达。
程序运行以后,会持续读取最新区块,通过 eth_getLogs 监听 Uniswap V4 的 Initialize 事件。当新的 Pool 被创建时,自动解析交易对、Token 信息、Fee、TickSpacing、Hook 和 Pool ID,并重点筛选 ETH/WETH 与新 Token 组成的交易池。本文先解决整个系统最基础的问题:
如何第一时间发现一个新的 Uniswap V4 Pool。
后续我们还可以基于这个框架继续增加流动性监控、Swap 监听、地址分析、风险检测、新币评分以及自动交易等功能。
1. Robinhood Chain 为什么值得关注?
Robinhood Chain 是一条基于 Arbitrum 技术栈构建的 Ethereum Layer 2 网络。对于使用 FMZ 开发链上策略的人来说,它有一个非常重要的特点:兼容 EVM。
这意味着我们以前在 Ethereum 等 EVM 网络中使用的 eth_blockNumber、eth_getLogs、eth_call、eth_getBalance、eth_getTransactionReceipt 等标准 JSON-RPC 方法,在 Robinhood Chain 上仍然可以继续使用。
Robinhood Chain 主网目前的核心参数如下:
| 参数 | 数据 |
|---|---|
| Network | Robinhood Chain |
| Chain ID | 4663 |
| Chain ID HEX | 0x1237 |
| Native Gas Token | ETH |
| EVM | Compatible |
| Public RPC | https://rpc.mainnet.chain.robinhood.com |
| Explorer | https://robinhoodchain.blockscout.com |
Robinhood 官方提供了免费的公共 RPC,所以开发阶段甚至不需要购买第三方节点就可以开始测试。不过官方同时说明 Public RPC 存在 Rate Limit,因此如果后续策略需要长期运行、大量查询或者更高稳定性,可以再考虑 Alchemy 等专业 RPC Provider。Robinhood Chain 官方连接文档
从 FMZ 的角度来看,接入 Robinhood Chain 与接入其他 EVM 网络并没有本质区别。我们真正需要解决的只是三个问题:连接正确的 RPC、找到目标智能合约、监听正确的链上事件。
2. 为什么选择 Uniswap V4 新池作为监听目标?
我们的目的并不是单纯知道 Robinhood Chain 又产生了一个新区块。
真正有价值的信息是:有没有新的 Token 交易池出现?
例如我们实际运行程序时已经捕获到了 ETH / GREAT、ETH / MERRY、ETH / ANTIDOTE 等 V4 Pool。
如果能够第一时间发现这些 Pool,后面就可以继续分析这个 Token 是什么、加入了多少 ETH 流动性、初始价格是多少、有没有用户开始交易、第一批买入地址是谁、买卖比例怎么样,以及 Token 本身有没有明显风险。
因此,新池发现其实是整个新币链上监控系统的入口。
尤其是 Uniswap 已经部署到 Robinhood Chain,V2、V3、V4 以及 UniswapX 均已进入这个生态。2026 年 8 月,Uniswap Labs 还推出了面向 Robinhood Chain 的 Pools.trade,为新 Token 的发行和流动性创建提供基础设施。Uniswap — Robinhood Chain is Live
所以对于我们来说,首先建立一个 Uniswap V4 新池雷达,是一个非常自然的切入点。
3. 理解 Uniswap V4 的 PoolManager
在真正写代码之前,需要先简单理解一下 Uniswap V4 与过去 V2、V3 的一个重要区别。
在 Uniswap V2 和 V3 中,我们经常会把不同交易池理解成不同的 Pool 合约。而 Uniswap V4 引入了 Singleton Architecture(单例架构),大量 Pool 的核心状态统一由一个重要合约进行管理,这个合约就是 PoolManager。
因此在 V4 中,我们不需要到处寻找新部署出来的 Pool Contract。对于新池监控来说,更重要的是直接监听 PoolManager 产生的事件。
这会让我们的监控逻辑简单很多。
Robinhood Chain 上 Uniswap V4 的 PoolManager 地址为:
0x8366a39cc670b4001a1121b8f6a443a643e40951
Robinhood Chain 的 WETH 地址为:
0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73
后面的程序会直接使用这两个地址。
4. 新 Pool 是怎么被发现的?
当一个新的 Uniswap V4 Pool 被初始化时,PoolManager 会产生一个非常重要的事件:
Initialize
它的结构可以简单表示为:
solidity
event Initialize(
PoolId indexed id,
Currency indexed currency0,
Currency indexed currency1,
uint24 fee,
int24 tickSpacing,
IHooks hooks,
uint160 sqrtPriceX96,
int24 tick
);
这里已经包含了大量对新池监控非常有用的信息,包括 Pool ID、两个交易资产、Fee、TickSpacing、Hook、初始价格以及 Tick。
整个监听原理其实并不复杂。
当用户调用 PoolManager.initialize() 初始化一个新的 V4 Pool 时,PoolManager 会产生 Initialize 事件,这条事件随后被记录到区块日志中。
FMZ 可以通过标准 JSON-RPC 方法 eth_getLogs 查询这些日志。只要同时指定 PoolManager 合约地址和 Initialize Event Topic,RPC 节点就可以直接过滤出我们需要的新池事件,而不需要把整个区块中的所有交易下载下来逐笔分析。
这就是本文新池雷达最核心的工作原理。
5. 在 FMZ 中添加 Robinhood Chain
下面正式开始操作。
首先在发明者量化平台添加一个 Web3 交易所对象。
因为 Robinhood Chain 是 EVM 网络,所以 ChainType 选择:ETH
这里需要注意,选择 ETH 并不意味着我们连接的是 Ethereum Mainnet,而是告诉 FMZ 使用 Ethereum/EVM 类型的 Web3 接口。
RPC Address 测试填写 Robinhood Chain 官方主网 RPC:https://rpc.mainnet.chain.robinhood.com
最终配置如下:
| 配置项 | 内容 |
|---|---|
| ChainType | ETH |
| Private Key | 测试钱包私钥 |
| Rpc Address | https://rpc.mainnet.chain.robinhood.com |
| Rpc Api Key | 留空 |
虽然本文的新池雷达只读取公开链上数据,不会发送交易,但是后续如果加入 Approve、Swap 等功能,钱包私钥就会真正参与交易签名。因此开发阶段建议单独创建一个测试钱包,不要直接使用存放大量资产的主钱包,更不要向任何人提供 Private Key 或 Seed Phrase。
6. 测试 FMZ 与 Robinhood Chain 的连接
Web3 策略开发中,我比较建议先做最小化测试。不要一开始就写几百行代码,而是先确认 FMZ → RPC → Robinhood Chain 这条最基础的数据通路是否正常。
建立一个最简单的 FMZ JavaScript 策略:
javascript
function main() {
var chainId = exchange.IO(
"api",
"eth",
"eth_chainId"
);
var blockNumber = exchange.IO(
"api",
"eth",
"eth_blockNumber"
);
Log(
"Chain ID:",
chainId
);
Log(
"Block Number:",
blockNumber
);
}
运行以后,我们实际得到:
其中 0x1237 转换成十进制就是 4663,与 Robinhood Chain Mainnet 的 Chain ID 完全一致。这意味着 FMZ 已经成功通过 JSON-RPC 接入 Robinhood Chain 主网。这个测试虽然非常简单,但很重要。因为后面如果新池监听出现问题,我们至少已经知道 RPC 连接本身是正常的。
7. 计算 Uniswap V4 Initialize Event Topic
Ethereum Event Log 中,topics[0] 对应事件签名的 Keccak256 Hash。
因此我们可以直接在 FMZ 中计算 Initialize 的 Topic:
javascript
function getInitializeTopic() {
var signature =
"Initialize(bytes32,address,address,uint24,int24,address,uint160,int24)";
return (
"0x" +
Encode(
"keccak256",
"string",
"hex",
signature
)
);
}
计算以后得到:
后面调用 eth_getLogs 时,只需要把这个值放到 topics[0],就可以让 RPC 节点帮助我们过滤 Initialize 事件。
8. 使用 eth_getLogs 查询新 Pool
FMZ Web3 可以通过 exchange.IO() 直接调用 Ethereum JSON-RPC。
例如:
javascript
var logs = exchange.IO(
"api",
"eth",
"eth_getLogs",
params
);
我们的查询参数主要包含三个条件:起始区块、结束区块、PoolManager 地址以及 Initialize Topic。
javascript
var params = {
fromBlock:
numberToHex(fromBlock),
toBlock:
numberToHex(toBlock),
address:
"0x8366a39cc670b4001a1121b8f6a443a643e40951",
topics: [
getInitializeTopic()
]
};
这样 RPC 节点返回的就不是区块中的全部交易,而是 指定区块范围内,由 Uniswap V4 PoolManager 产生的 Initialize Event。
对于一个长期运行的新池雷达来说,这种方式要比逐块下载所有交易再分析高效得多。
9. 解析 Initialize Event
得到 Event Log 后,还需要把原始十六进制数据转换成人类能够理解的信息。Initialize 中前三个参数是 indexed 参数,因此分别位于 topics[1]、topics[2] 和 topics[3]。
javascript
var poolId =
log.topics[1];
var currency0 =
topicToAddress(
log.topics[2]
);
var currency1 =
topicToAddress(
log.topics[3]
);
其他参数则位于 log.data 中。
javascript
var fee =
wordToUint24(
getWord(
log.data,
0
)
);
var tickSpacing =
wordToInt24(
getWord(
log.data,
1
)
);
var hooks =
wordToAddress(
getWord(
log.data,
2
)
);
经过解析以后,原本很难阅读的一串 Blockchain Log 就可以转换成 Pool ID、Token 地址、Fee、TickSpacing、Hook 等结构化信息。
10. V4 中 Native ETH 的一个容易踩坑的地方
在 Uniswap V4 中,Native ETH 可以直接作为 Currency 使用。因此如果程序看到:
0x0000000000000000000000000000000000000000
不能简单地认为这是一个错误地址。在这里它可能代表的就是 原生 ETH。所以我们的程序需要同时识别 Native ETH 和 WETH。
Native ETH:
0x0000000000000000000000000000000000000000
Robinhood Chain WETH:
0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73
这样才能把 ETH / 新 Token 和 WETH / 新 Token 类型的交易池单独筛选出来。对于新币雷达来说,这类 Pool 通常比普通的 Token/Token Pool 更值得优先展示。
11. 继续读取新 Token 信息
只显示一个 Token Contract Address,可读性还是比较差。
例如:
0xffb1e3a069d2060cf42247ed67a8e712a05064de
我们并不知道它是什么。因此在发现新 Token 以后,可以继续通过 eth_call 调用标准 ERC20 的 symbol()、name() 和 decimals()。
首先注册一个简单 ERC20 ABI:
javascript
var ERC20_ABI = `[
{
"inputs": [],
"name": "symbol",
"outputs": [{"type":"string"}],
"stateMutability":"view",
"type":"function"
},
{
"inputs": [],
"name":"name",
"outputs":[{"type":"string"}],
"stateMutability":"view",
"type":"function"
},
{
"inputs":[],
"name":"decimals",
"outputs":[{"type":"uint8"}],
"stateMutability":"view",
"type":"function"
}
]`;
然后:
javascript
exchange.IO(
"abi",
addr,
ERC20_ABI
);
var symbol = exchange.IO(
"api",
addr,
"symbol"
);
这样原来的 Token 地址就可以进一步展示为 Symbol、Name、Decimals、Contract Address。另外,实际链上并不能保证每一个 Token 都严格按照标准 ERC20 ABI 实现,所以读取 Token 信息的部分最好使用 try...catch。即使某个奇怪 Token 无法读取 symbol(),也不能让整个新池雷达停止运行。
12. 实际运行:真的抓到了 Robinhood Chain 新池
完成上面的逻辑以后,我们把程序放到 Robinhood Chain 主网实际运行。很快就捕获到了真实的 Uniswap V4 Initialize Event。
这意味着我们已经真正跑通了 Robinhood Chain → Uniswap V4 PoolManager → Initialize Event → FMZ 新池监控 这条数据链路。
13. 使用 LogStatus 制作实时新池雷达
如果只是不断调用 Log(),程序运行几个小时以后日志会非常多,很难快速判断系统当前状态。
因此我们继续使用 FMZ 的 LogStatus() 制作一个简单的实时 Dashboard。这里主要展示 网络状态、最新区块、RPC 延迟、扫描次数、新池数量、ETH/WETH Pool 数量、最近发现的新 Pool,以及重点的新 Token 信息。
到这里,整个程序已经不再只是一个简单的 Event Log 脚本,而开始具备一个链上监控系统的基本形态。
14. RPC 节点选择以及实际踩过的坑
Robinhood Chain 官方提供 Public RPC:
text
https://rpc.mainnet.chain.robinhood.com
在我们实际测试过程中,官方免费 RPC 已经能够正常完成 eth_blockNumber 和 eth_getLogs 查询,所以开发阶段完全可以直接使用。
但是如果程序准备长期 7×24 小时运行,或者以后加入大量 Swap、Liquidity、Token 查询,就需要考虑 RPC 稳定性和 Rate Limit。
因此我们也测试了 Alchemy。
Alchemy 的 Robinhood Chain HTTP Endpoint 格式类似:
text
https://robinhood-mainnet.g.alchemy.com/v2/YOUR_API_KEY
FMZ 中只需要把 Rpc Address 换成对应 Endpoint,策略代码仍然继续使用标准 JSON-RPC,不需要因为更换 Provider 而重新修改核心逻辑。
不过这里我们实际遇到了一个很有意思的问题。
Alchemy Free Plan 在执行一次范围较大的 eth_getLogs 时返回:
text
400 Bad Request
Under the Free tier plan,
you can make eth_getLogs requests
with up to a 10 block range.
原来的程序设置:
javascript
maxBlockRange: 100
意味着单次查询最多可能覆盖 100 个区块,因此触发了免费套餐限制。
解决方法很简单:
javascript
maxBlockRange: 10
然后让程序自动进行分段查询。例如机器人掉线一段时间以后,需要补查 35 个区块,就把它自动拆成四次 eth_getLogs 请求,每次最多查询 10 个区块。这个修改看起来很小,但实际上很有价值。
**链上监控程序不能假设 RPC 永远稳定,也不能假设所有 Provider 的限制完全一样。**以后如果把这个项目继续完善,还可以增加主 RPC、备用 RPC、自动 Failover、429 重试和指数退避等机制。
15. 完整 FMZ 新池雷达代码
下面给出本文最终使用的完整策略。这一版本的定位非常明确:只监控,不交易。
Robinhood Chain - Uniswap V4 新池雷达
它不会执行 Approve,不会调用 Swap,也不会自动购买任何 Token。我们先把链上数据层做好,再在这个基础上继续扩展交易策略。
16. 为什么发现 Pool 以后不能直接买?
做到这里以后,很容易产生一个想法:既然已经能够第一时间发现新 Pool,是不是发现以后直接 Swap 就可以了?
实际上还差得很远。Initialize 只代表这个 Pool 已经被初始化,并不代表它已经具备值得交易的流动性。
一个 Pool 被创建以后,后面可能才开始添加流动性。即使已经加入流动性,也仍然需要判断流动性规模、初始价格、Fee、Hook,以及 Token 本身的合约风险。因此,“发现新池”和“发现交易机会”是两件完全不同的事情。
我们现在解决的是第一件事。下一步则需要在捕获 Initialize 以后继续监听与流动性变化有关的事件。这样当程序发现 ETH / GREAT 以后,就不再只是显示 Token 名字,而是能够继续回答:这个 Pool 有没有真正加入流动性、加入了多少 ETH、对应多少 Token,以及当前初始价格大概是多少。
这一步完成以后,新池雷达才会真正向新币雷达演变。
17. 下一步:增加流动性雷达
本文建立的代码框架并不是一个一次性脚本。目前我们已经拥有 Pool ID、Currency0、Currency1、Fee、TickSpacing、Hook、Block、Transaction Hash 和 Token 基础信息,这些数据都可以成为后续模块的输入。下一篇最值得实现的是 Liquidity Radar(流动性雷达)。
当 Initialize 发现一个 ETH 新币池以后,程序继续跟踪这个 Pool 的流动性变化,并尝试计算 ETH 流动性、Token 流动性、初始价格以及流动性变化速度。
再往后,可以继续监听 Swap。一旦能够实时解析 Swap,就可以统计 第一笔成交、前 10 笔成交、买入次数、卖出次数、成交量、独立交易地址数量和早期交易速度。
有了这些数据以后,系统就不再只是告诉我们“出现了一个新 Token”,而是可以逐渐形成类似这样的信息:
| 指标 | 数据 |
|---|---|
| Token | GREAT |
| Pool | 已创建 |
| ETH Liquidity | 12.6 ETH |
| Swap | 38 |
| Buyers | 27 |
| Sellers | 4 |
| Hook | 无 |
| Risk | 中 |
| Score | 76 / 100 |
再进一步,就可以研究部署者地址、第一批买家、地址历史行为、流动性撤出、Token 权限以及异常交易模式。这些模块最后可以统一进入一个 Scoring Engine,把大量新 Pool 自动划分为忽略、观察和重点关注。只有到了这个阶段,再讨论自动交易才更有意义。
18. 后续可以继续研究什么?
整个系列可以围绕本文的代码逐步扩展,而不是每次重新写一个完全不同的程序。
第一阶段是 Pool Discovery。 也就是本文完成的 Initialize 监听,负责解决“什么时候出现了一个新 Pool”。
第二阶段是 Liquidity Intelligence。 重点研究新池加入多少 ETH、多少 Token,流动性什么时候增加,又什么时候被撤走。
第三阶段是 Trading Intelligence。 开始监听 Swap,统计第一批交易、买卖方向、成交速度和成交金额。
第四阶段是 Wallet Intelligence。 分析谁在买、谁在卖、部署者有没有参与交易,以及某些地址过去是否多次出现在高表现新币的早期交易中。
第五阶段是 Risk Engine。 对 Token 权限、Hook、Fee、流动性、地址集中度和异常交易行为进行统一检查。
最后才是 Strategy Engine。根据前面的链上数据形成规则或者评分,然后决定是否进入观察列表,以及未来是否允许策略自动执行 Swap。
这样,一个最开始只有几百行代码的新池监听程序,就可以逐步发展成一套完整的 Robinhood Chain 链上量化数据与策略系统。
19. 结语
这次实践验证了一件比较有意思的事情。对于一条新的 EVM Chain,我们并不一定需要等待完整 SDK、第三方数据平台或者现成的量化框架准备好以后才能开始开发。只要网络提供标准 Ethereum JSON-RPC,FMZ 就已经可以直接从底层读取链上数据。
本文实际使用的核心接口并不多,主要就是 eth_chainId、eth_blockNumber、eth_getLogs 和 ERC20 eth_call。但是依靠这些非常基础的接口,我们已经完成了 Robinhood Chain 主网连接、Uniswap V4 PoolManager 监听、Initialize Event 解析、Token 信息查询、ETH/WETH 新池筛选以及实时 Dashboard 展示。更重要的是,在实际运行过程中,我们已经真实捕获到了 ETH / GREAT、ETH / MERRY、ETH / ANTIDOTE 等新创建的 V4 Pool。
策略描述:Robinhood Chain - Uniswap V4 新池雷达
本文仅作为 Web3 技术研究和程序开发实践,不构成任何投资建议。新发行 Token 和低流动性链上资产具有很高的价格、智能合约及流动性风险。在加入自动交易功能之前,应充分测试并建立完整的风险控制机制。
- 1







