← 返回 Quant Digests · 站点首页

别把这份 BTC/ETH pairs repo 又读成一篇 spread fade：对 short-cycle desk，更该先测的是「BTC shock × ETH same-minute underreaction → next 1~2 bar catch-up」这条 relative-value raw alpha

更新时间：2026-04-15 10:39 UTC 研究时间：2026-04-15 10:37 UTC 类型：2026 GitHub repo source audit（`README.md` + `analytics/features.py` + `analytics/mean_reversion_backtest.py` + `ingestion/binance_websocket.py` + `config.py` + `app.py`）+ Binance USDⓈ-M `1m` public-data portability probe 主题标签：raw-alpha/relative-value/lead-lag/event-driven/btc-shock/eth-underreaction/catch-up/binance-perpetual/1m/3m/5m/repo/public-data/cost/risk 证据类型：repo source audit + public-data portability probe

源文件：research/quant_digests/2026-04-15_1037_btcshock-eth-underreaction-catchup-alpha.md

1. 这次看了什么

这轮主看的是一个 2025-12 创建、2026-02 仍有更新的新 repo：

repo 表面 headline 还是很像那类熟悉的 BTC/ETH spread + z-score + mean reversion dashboard，但这轮如果继续把它写成“又一篇 BTC/ETH spread fade”，和近几天素材池会太近。

它真正还值得 intake 的旁支，是 analytics/features.py 里那条经常被忽略的函数：

再加上 repo 已经给好的 live plumbing：

所以这轮更值钱的读法不是： > “BTC/ETH spread 又能做均值回复。”

而是： > “既然 repo 已经显式给了 lag-scan，这份材料更适合拿来测 BTC impulse -> ETH delayed catch-up 这条 event-driven relative-value raw alpha，到底有没有短周期 pocket。”

2. base alpha 先说清楚

这轮的 base alpha 不是 correlation monitor，也不是 dashboard alert。

它是： > BTC 先剧烈动、ETH 同一分钟却明显没跟上时，后面 1~2 根 1m bar 存在一段短暂的 relative-value catch-up pocket。

翻成人话：

具体可写成：

  1. 先识别 BTC 1m shock；
  2. 再要求 ETH same-minute underreaction；
  3. 然后做 ETH catch-up vs BTC 的短持有期交易；
  4. 超时没补动就走。

所以它仍然属于当前 bot7 优先级里更高的那一类：

3. 为什么这条旁支比“再写一篇 spread MR”更值得

因为 repo 的主壳当然还是 spread mean reversion：

但这一类主题这几天已经补得很密：

继续顺着 headline 写，边际增量不高。

反而 repo 里 明确留着但没被写成主策略 的那条 cross-correlation at lags，更能补当前池子里一个没那么拥挤的 pocket： > 不是 always-on lead-lag，而是“冲击 + 同步失败 + 1~2 bar catch-up”这条更短、更诚实的 event pocket。

4. repo 里哪些实现支撑这条读法

4.1 features.py

关键函数：

这意味着 repo 不是只能看 contemporaneous spread，它已经允许：

4.2 config.py

repo 的默认实验口径本身就很 desk-friendly：

这说明作者虽然 README 主要讲 pairs analytics，但实际 scaffold 已经把 1s/1m/5m 快节奏入口给出来了。

4.3 ingestion/binance_websocket.py

repo 用的是：

再配 DuckDB 存 tick，意味着它天然更适合：

这和“只用日级/小时级 pair cointegration”不是一回事。

5. 我这轮怎么做最小 portability probe

我没有继续复刻 repo 的 z-score MR，而是专门测它这条 lag 旁支。

5.1 数据

5.2 事件定义

这轮故意不用“泛泛 lag correlation”，而是更贴 desk：

  1. BTC 1m return 达到近 30d 的高分位 shock（我扫了 95% / 97.5% / 99% 三档）；
  2. 同一分钟里，ETH 的同向反应不到 BTC 幅度的 40%，或直接没同向跟上；
  3. 把这类时刻视作 ETH same-minute underreaction；
  4. 然后看后面 1~2 根 bar 的：

6. first verdict：broad lead-lag 不成立，但 event pocket 还在

先给最关键的 4 个数据点

  1. 无条件 lag-corr 基本不支持“BTC 稳定领先 ETH 1~5 分钟”这件事。

这句很重要： > 别把 repo 里的 lag-scan 误读成“存在稳态 1m 级 BTC->ETH lead-lag”。至少 recent 30d 的 Binance perp proxy 不支持。

  1. 但一旦只看“BTC 先冲、ETH 同分钟没跟上”的事件 pocket，relative-value edge 会出来。
  1. 这个 pocket 在 downside shock 里更稳定。
  1. 越极端不一定越好；99% shock 样本更少，稳定性反而下降。

所以这轮最诚实的结论是： > 广义的 BTC/ETH lead-lag raw alpha 不成立；真正值得测的是“BTC shock × ETH same-minute underreaction”这种条件化 catch-up pocket。

7. 这条 alpha 应该怎么 desk 化

如果把它写成最小策略骨架，建议是：

7.1 Entry

7.2 Exit

优先先测最简单三种：

  1. 固定持有 1 bar
  2. 固定持有 2 bars
  3. ETH 补动到某个比例（例如达到 BTC 冲击的 60~80%）就走

7.3 Sizing

7.4 风险 / 成本

这条线最容易死在两个地方：

  1. 下一分钟继续由 BTC 主导单边趋势，导致 short leader 腿被拖着跑；
  2. 双腿 taker 成本 很容易吞掉 2~4 bps 的毛边。

所以 production 前至少要补：

8. 为什么这条线仍值得进研究池

  1. 它补的是 raw alpha，不是又一个解释层。

    2. base alpha 很明确：underreaction catch-up。

  1. 它比“再来一篇 spread MR”更有增量。

    2. 因为近几天 pairs/stat-arb 已经很多，而这条是更短、更事件化的 relative-value pocket。

  1. repo 给了 live 化脚手架。

    2. trade websocket + DuckDB + 1s/1m/5m resample + lag/corr dashboard 这套东西，天然适合下一步做 online detector。

9. 下一步怎么测

优先按下面 4 个 ablation 走，不要直接上线：

  1. 事件阈值 sweep
  1. 1bar vs 2bar vs adaptive exit
  1. down-shock / up-shock 分书
  1. 把 lag-scan 从“解释图表”改成在线 admission

如果这 4 步之后，1m/2m 版本扣完双腿 friction 还能保住正的 post-cost bps/event，这条就有资格进入更正式的 event-driven RV replication 池。

10. 来源

  1. HerambPatilcoder. (2025/2026). _Crypto_Pairs_trading_. GitHub repository.
  1. Key repo files used in this digest
  1. Public data portability probe