Robinhood Chain · Uniswap V4 New Pool Radar V2
Robinhood Chain · Uniswap V4 New Pool Radar V2
1. Core Idea: Discover Trading Pairs Through Pool Initialization
Built for FMZ Quant in JavaScript, this strategy scans the configured Robinhood Chain Uniswap V4 PoolManager for Initialize events to discover newly initialized pools, with special highlighting for pairs containing ETH or WETH.
For each detected pool, it extracts the two assets, LP fee, tick spacing, hook address, and initial tick, then retrieves token symbols, names, and decimals.
The core workflow is:
validate network → scan blocks → capture Initialize → deduplicate events → decode and classify → update logs and dashboard
The current version is MONITOR ONLY and does not execute trades. An initialization event confirms that a pool was initialized; it does not establish that liquidity is available or provide a buy signal.
2. Three Engineering Details
1) Network Validation and Batched Scanning
At startup, the strategy calls eth_chainId and requires it to match 4663 / 0x1237, as configured in the code. A mismatch raises an error.
By default, it looks back 100 blocks before continuing from its scan cursor. Each eth_getLogs request covers at most 10 blocks, limiting the range of individual RPC queries.
The strategy waits 1,000 milliseconds after each loop. Actual cycle time also includes RPC calls, token metadata queries, and dashboard updates.
2) Event Decoding and Deduplication
Pool ID and asset addresses are extracted from event topics. Fee, tick spacing, hook address, sqrtPriceX96, and tick are read from data, with tick spacing and tick decoded as signed int24 values.
Deduplication uses:
event key = transactionHash + "_" + logIndex
Different logs within one transaction remain distinguishable, while repeated delivery of the same event does not increase the counters. Deduplication records are held in memory and rebuilt after restart.
3) Token Metadata and Caching
For ordinary ERC20 tokens, the strategy queries symbol, name, and decimals, then caches the results by contract address. ETH and the configured WETH use predefined metadata.
Unavailable fields retain placeholders such as UNKNOWN, -, or ?, allowing monitoring to continue. Setting queryTokenInfo=false disables ordinary ERC20 metadata queries.
3. Pool Classification: ETH/WETH, Dynamic Fees, and Hooks
Each pool receives three independent classifications:
- Base asset: a pool is highlighted if either asset is native ETH or the configured WETH. If the other asset is a non-base token, that token becomes the radar target.
- Fee type: the
0x800000flag identifies dynamic-fee pools. Static-fee pools are labeled using the configured thresholds. - Hook presence: a nonzero hook address triggers a hook label and displays the address.
Static LP fees are converted as follows:
LP fee (%) = fee / 10000
Default classifications:
| Condition | Display |
|---|---|
Static fee < 10000 | 🟢 Normal: below 1% |
Static 10000 ≤ fee < 100000 | 🟡 High: 1% to below 10% |
Static fee ≥ 100000 | 🔴 Extreme: 10% or above |
| Dynamic-fee flag set | ⚡ Dynamic: classified separately |
| Nonzero hook address | 🪝 Hook present |
The dynamic-fee flag does not reveal the current execution fee. Hook detection identifies the presence of a hook contract without analyzing its behavior. Fee labels are not an overall safety assessment of the token or pool.
4. Runtime: Continuous Scanning and Error Logging
The main loop fetches the latest block and scans forward from the block immediately after the saved cursor:
fetch latest block → query batches → decode events → advance cursor → refresh dashboard → wait
- Continuous tracking: the cursor advances after each processed block range.
- Per-event error isolation: a failed event is logged while processing continues for other events.
- Loop-level error handling: caught exceptions increment the error counter, produce a log entry, and allow the next loop to run.
- Runtime visibility: the dashboard tracks the latest block, scan cursor, most recently measured RPC latency, loop count, and uptime.
The cursor, counters, and caches are held in memory. Restarting triggers a fresh lookback scan. Persistent checkpoints, dedicated retries for failed events, and chain-reorganization rollback are not implemented.
5. Monitoring Scope and Priority Radar
The monitoring scope is defined by the PoolManager address and Initialize event topic. All matching pools enter the statistics; ETH/WETH classification controls priority highlighting.
| Condition | Handling |
|---|---|
Initialize from the configured PoolManager | Decode and count |
| Either asset is ETH / WETH | Highlight as a priority pool |
| Exactly one asset is ETH / WETH | Add the other token to the priority radar |
| Neither asset is a base asset | Display as an ordinary pair |
| Duplicate event | Skip without recounting |
The “new token radar” shows non-base tokens from newly detected pools. It does not verify that those tokens were newly deployed. The code also does not check actual liquidity, trading volume, buy/sell availability, or token contract permissions.
The priority radar selects entries from the recent-pool list and displays at most 10 rows, so its coverage also depends on maxRecentPools.
6. Parameters and Dashboard
The main settings are defined in CONFIG:
| Parameter | Default | Purpose |
|---|---|---|
chainIdHex | 0x1237 | Network ID required at startup |
poolManager | Address preset in code | PoolManager to monitor |
weth | Address preset in code | Address used to identify WETH |
lookbackBlocks | 100 | Startup lookback depth |
scanInterval | 1000 | Wait after each loop, in milliseconds |
maxBlockRange | 10 | Maximum blocks per log request |
maxRecentPools | 15 | Number of recent pools retained |
queryTokenInfo | true | Enable ordinary ERC20 metadata queries |
highFeeThreshold | 10000 | High static LP fee threshold: 1% |
extremeFeeThreshold | 100000 | Extreme static LP fee threshold: 10% |
The LogStatus dashboard contains five separate tables: system status, pool statistics, monitored contracts, recently detected pools, and the ETH/WETH priority radar.
Detailed logs include full token addresses, Pool ID, transaction hash, fee, tick spacing, tick, and hook information for further inspection. The current version includes no order execution, position management, simulated matching, or profit curve.
// ============================================================
// Robinhood Chain · Uniswap V4 新池雷达 V2
// FMZ / 发明者量化 · JavaScript
//
// 功能：
// 1. Robinhood Chain RPC 健康检测
// 2. Chain ID = 4663 校验
// 3. Uniswap V4 PoolManager Initialize 监听
// 4. 新 Pool 去重
// 5. ETH / WETH 池重点标记
// 6. ERC20 Symbol / Name / Decimals 读取
// 7. Fee / TickSpacing / Hook / Tick 解析- 1