源文件：research/quant_digests/2026-04-03_1425_hyperliquid-public-trigger-cluster-alpha.md
> 一句话先定性：这轮不把 2026 新 repo 的主叙事继续写成“funding + OI + liquidation 老三样”，而是把里面更适合我们 desk 的旁支单独拎出来——用 Hyperliquid 公共 frontendOpenOrders + clearinghouseState 做可扫描的 stop / liquidation map，再交易“向 cluster 逼近时的短时级联 continuation”。
这轮它比再补一篇泛 breakout/filter 更值钱，原因很简单：
1m/3m/5m 往往先看“打到它”。info endpoint 公开给出：frontendOpenOrders：isTrigger / orderType / triggerCondition / triggerPxclearinghouseState：持仓、杠杆、liquidationPxallMids / trades：当前中间价与实时成交1m/3m/5m，15m 更像管理与二次确认层。这也符合当前 intake 优先级：它不是纯解释，不是纯 overlay，而是一个能直接下手做最小实验的 raw alpha 候选。
---
wilsontiger22222026-02-082026-02-08Liquidation cascade trading strategy for crypto perpsREADME.mdconfig.yamlmain.pysrc/data/hyperliquid_client.pysrc/data/positions.pysrc/signals/liquidation_map.pysrc/signals/signal_aggregator.pytests/test_signal_aggregator.pyopenOrdersfrontendOpenOrdersallMidsfrontendOpenOrders 返回 isTrigger / orderType / triggerCondition / triggerPx / reduceOnly，足够拼 stop-mapwss://api.hyperliquid.xyz/ws 订阅 trades，给 cluster touch / break / follow-through 做实时触发。10.1093/rfs/hhs053> 这篇不是直接讲 crypto stop-map，但它给了足够硬的地基：当订单流已带方向性且流动性脆弱时，接下来短时价格并不“中性”，而是容易继续沿冲击方向走。 public stop/liq cluster 可以理解成把“脆弱位置”显式化了。
---
repo headline 是 liquidation cascade strategy；但对我们更值钱的，其实是 README 里一句很关键的话：
liquidationPx、trigger orders、order book depth，可以自己建 map这意味着：
> 真正可复现的不是“看现成 heatmap 猜方向”，而是自己扫描公开钱包 → 聚合 stop / liq cluster → 交易 cluster 附近的短时 path。
这就从“可视化看板”升级成了可以编码的 raw alpha。
---
src/data/hyperliquid_client.py 明确封装了：
``python {"type": "allMids"} {"type": "clearinghouseState", "user": user} {"type": "frontendOpenOrders", "user": user} ``
这三条已经足够做最小 stop-map：
allMids 给当前价clearinghouseState 给仓位与 liquidationPxfrontendOpenOrders 给 trigger orders 的 triggerPx换句话说，公开 API 本身就支持把“谁会在什么价位被动出手”拼出来。
src/signals/liquidation_map.py 的做法很直接：
liquidation_price 按 bin_pct = 0.5% 分箱volume 与 countdistance_pct信号强度：
``text strength = 0.6 * distance_factor + 0.4 * volume_factor ``
方向定义也很清楚：
这个框架直接就能迁到 trigger-order map：
triggerPx 替代 liquidationPxorigSz / sz / reduceOnly / tpsl 类型做权重src/signals/signal_aggregator.py：
``python WEIGHTS = { "funding": 0.35, "oi_divergence": 0.30, "liquidation": 0.35, } ``
它把 funding / OI / liquidation 三条线合成一个 direction + confidence + target_price。
对我们更有用的不是照抄 35/30/35，而是看到：
> cluster 本身完全可以做主信号，funding / OI 只负责 admission / veto / sizing。
这点很重要，因为当前 desk 更需要 raw alpha，不该把所有 crowding 数据都写成 filter。
---
下面给一版适合 1m/3m/5m/15m 的最小可交易版本。
先只做：
BTCETH原因：
SOL 可以放二期。
frontendOpenOrdersclearinghouseStateallMidstradestrigger / liq map：每 30s 扫一轮trades：实时1m对每个 wallet 的 frontendOpenOrders：
isTrigger = truetriggerCondition = sltp 单独记，不和 sl 混箱triggerPx 按 0.25% 或 0.5% 分箱w_notional = origSz * triggerPxreduceOnly = true 给予更高可信度sl 权重大于 tp对每个 wallet 的 clearinghouseState：
liquidationPxmarginUsed 或 abs(size) * liquidationPx 近似体量0.25% 或 0.5% 分箱对每个 price bin：
``text cluster_score = 0.45 * stop_notional_z + 0.35 * liquidation_notional_z + 0.20 * address_count_z ``
再计算：
distance_pct满足以下条件时开多：
0.3% ~ 1.2% 内存在高分 cluster；3 根 1m bar 至少 2 根收涨；1m 主动买成交占优，或最新价重新站上最近 3m 局部高点；gap_to_cluster >= 5 * roundtrip_cost。镜像：
0.3% ~ 1.2% 内存在高分 cluster；3 根 1m bar 至少 2 根收跌；3m 局部低点；gap_to_cluster >= 5 * roundtrip_cost。0.8 ~ 1.0 * gap_to_cluster50%1m follow-through 仍强，则剩余仓位改 trailing stop1m bar 出现长反向 wick + 收回，则全部平仓取更紧者：
0.35 * gap_to_cluster0.8 * ATR(1m, 20)8~12 分钟不打到 cluster，平仓15m 级别最多不超过 1 根 bar按 cluster 质量分三档：
top decile score: 风险预算 1.00R80~90 pct: 0.70R70~80 pct: 0.40R并加两条硬约束：
1.5R这条策略不能忽略 cost，因为它交易的是剩余 gap。
最小要求：
``text expected_gap_bps >= 5 * roundtrip_cost_bps ``
其中 roundtrip cost 应含：
如果 cluster 离得太近但深度太薄，表面上“马上会打到”，实际上可能是没有足够 alpha 去覆盖冲击成本。
---
它服务的不是：
而是：
所以它确实在扩充 raw alpha 素材池，而不是继续围绕固定形态打转。
1m：主触发频率，最适合做 touch / break / follow-through3m：适合做 admission，减少假触发5m：适合做持仓管理和 cluster 打到后的确认15m：更适合风控限时，不适合拿来定义首触发换句话说：
> 信号在 1m 生成，3m 做去噪，5m 做管理，15m 做 time cap。
---
我做了一个极小的公共接口快检。
2026-04-03 14:19 UTCinfo endpointconfig.yaml 里的 13 个示例 whale walletsBTC / ETH / SOLfrontendOpenOrdersclearinghouseStateallMids当前价：
66,698.52,046.4579.6825扫描结果：
468 行公开数据BTC 9 / ETH 7 / SOL 4liquidationPx 的持仓：BTC 2 / ETH 4 / SOL 3BTC 1 笔，离现价约 13.0%1% 邻域内：BTC/ETH/SOL 都没有密集 trigger / liq cluster这不是坏消息，反而把最关键的瓶颈说透了：
对应 artifact：
reports/artifacts/quant_digests/hl_trigger_map_probe_20260403_1420/summary.jsonreports/artifacts/quant_digests/hl_trigger_map_probe_20260403_1420/wallet_summary.csvreports/artifacts/quant_digests/hl_trigger_map_probe_20260403_1420/details.csv---
这轮最诚实的 MVE 不是直接上实盘，而是先做事件研究。
连续采集 7~14 天：
30s 扫一次 frontendOpenOrders / clearinghouseStatetrades1m bar先只做 BTC / ETH。
对每个 1m：
distance_pctcluster_scoreaddress_countstop_share vs liq_share定义 event：
1.0% 邻域对每类 event 测：
1m / 3m / 5m / 15mN 分钟内打到 clustercluster_score 分层后的单调性1m/3m/5m1m/3m我建议先做 A，因为 repo 原始 liquidation logic 本来就是 continuation 语义；B 可以等 A 的 cluster 数据积出来后再做。
---
这轮我会把它归档为：
raw alphaevent-driven / relative-value-of-path / stress-cluster continuationtrigger-map / stop-sweep / liquidation / Hyperliquid / public-data最关键的判断是：
> 这不是“现成 heatmap 指哪打哪”的主观交易笔记，而是一条公开 API 足以支撑、能编码、能做事件研究、也能落成完整策略壳的 short-cycle raw alpha 候选。
但也要诚实地补一句：
> 当前 repo 自带的 13 钱包白名单太稀，不能直接拿来 live trade；真正的 alpha 门槛在 wallet discovery，不在 cluster 打分公式本身。
这个结论本身就很有价值——因为它告诉我们，下一步该把研发时间花在哪。
---
按优先级只做三步：
trades / 排行榜 / 大额成交，动态生成 top active walletsBTC/ETH 的 14 天 30s cluster replaypre-sweep continuation1m 触发1m/3m/5m 优先，15m 仅作上限cluster_score + distance + short-term impulse如果这三步做下来，hit-to-cluster rate 和 forward 3m expectancy 没有随 cluster_score 单调上升，这条线就不要再浪费时间；若单调性成立，再考虑把 funding/OI 接回来做 sizing/veto。