源文件：research/quant_digests/2026-04-18_1805_hft-pairs-obi-veto-shell.md
1m 上做 spread z-score 极值回归；盘口 OBI 只负责放行/否决更微观的入场时点看的是 SamarthChaudhary-22/Crypto_Stat-Arb_HFT_Model。它不是泛泛的“配对交易 notebook”，而是一个研究到执行分层很清楚的壳：
data_loader.py：抓 Binance USDⓈ-M 1m 数据，按 quoteVolume 先筛 top-50 流动性合约；analyzer.py：先在 1h 级别做相关性、Engle-Granger、ADF、half-life 筛 pair；optimizer.py：在 spread 上扫 window / entry_z / exit_z / stop_z；main.cpp：把结果推到一个低延迟执行器里，用 bookTicker / depth 信息加 OBI 做更细的放行。这套结构对我们最有价值的，不是“C++ 很快”本身，而是：它把 pair admission、spread alpha、本地微观结构 gate、执行线程壳分开了。
cointegrated pair spread extreme -> mean reversion。不是 trend，不是 breakout，也不是纯 execution trick。1h 做 pair admission，减少乱配对；1m 做 z-score 入场；OBI 只作为更快一级的 veto / timing layer。Z_ENTRY=2.0、Z_EXIT=0.5、BET_SIZE=1000，并且要求两腿盘口失衡不要和 spread 方向打架：z > 2 时做 leg1 short / leg2 long；z < -2 时做 leg1 long / leg2 short；|z| < 0.5 才平。1m 最近 1500 根 bar 做了一个最小 portability probe：ENAUSDT/LINKUSDT：|z|>2 触发后，平均 |z| 从 2.23 -> 1.14 (30m) -> 0.99 (60m)，94.6% 的事件在 60m 内收敛，58.9% 在 60m 内回到 |z|<1；LINKUSDT/SOLUSDT：平均 |z| 从 2.29 -> 1.03 (30m) -> 1.19 (60m)，96.5% 事件在 60m 内收敛，但只有 45.6% 回到 |z|<1。这份 repo 最值得保留的不是“低延迟 C++ 外壳”，而是 1h pair admission -> 1m spread-zscore fade -> OBI veto execution 这条可独立复现、可继续压缩到短周期的 raw alpha 结构。
它不是靠论文口头说服，而是靠工程分层 + 参数文件 + 直接执行逻辑来证明：
analyzer.py 明确先做 cointegration / ADF / half-life 过滤；optimizer.py 明确只优化 spread 交易参数；main.cpp 明确把 OBI 放在 entry gating，而不是把 OBI 当成 alpha 本体。换句话说，repo 自己已经在结构上回答了一个关键问题：base alpha 是 pair spread 回归，不是盘口失衡。盘口只是 timing layer。
当前 digest 池里虽然已经有很多 pairs / stat-arb 主题，但这份 repo 仍有一个没那么重复的价值：
pairs / stat-arb这比继续做纯 regime/filter 主题更值钱，因为它直接服务于“怎么把 pairs 从 paper signal 往实盘壳推进”。
top liquid universe -> corr filter -> Engle-Granger -> ADF -> half-life|z| > 2|z| < 0.5MAX_SAFE_Z = 25；优化器里另有 stop_zBET_SIZE=1000，第二腿按 hedge_ratio 配OBI 只决定现在这一下要不要进，不改 base alphaanalyzer.py 不是直接拿 1m 噪音去跑全市场配对，而是先 resample 到 1h，再做：
0.85p < 0.05240 分钟这很符合 desk 现实：pair selection 可以慢，entry timing 才需要快。
main.cpp 里 spread 还是用： log(p1) - hedge_ratio * log(p2)
真正进场条件则是：
这很重要，因为很多 repo 会把“看见 OBI”误写成“alpha 来自 OBI”；这份 repo 至少在结构上没犯这个错。
这对后续复现很关键：
pair admission + spread signal；bookTicker/OBI/microprice。也就是说，它天然支持分阶段验证，而不是一上来就把 low-latency、网络、线程、盘口特征全部绑死。
这里有两个明显问题，反而也是这篇 digest 最值得记下来的地方：
optimizer.py 用的是：spread = leg1 - hedge_ratio * leg2main.cpp 用的是：spread = log(p1) - hedge_ratio * log(p2)这不是小问题。它意味着：离线最优参数和线上触发空间可能根本不是同一个 spread。
main.cpp 读取 mean/std_dev，但 strategies.json 默认并不带这两个字段repo 里专门又写了个 fix_strategies.py 去补 mean/std_dev。这说明当前仓库更像“工程壳 + 研究草稿”，还不是可以闭眼上线的 production artifact。
所以这篇东西更适合作为：
先不碰低延迟和盘口，只做最小 spread 回归验证：
20~50 流动性合约；corr + EG/ADF + half-life；spread = log(p1) - beta * log(p2)z = (spread - rolling_mean) / rolling_stdentry: |z| > 2exit: |z| < 0.51h1m，再下放 5m/3m1m klines1500 根 1m barENAUSDT/LINKUSDTLINKUSDT/SOLUSDT1m/3m/5m/15m 的关系1m entry / exit。这是 repo 的原始设计频率。5m 做 spread 观测，1m 只做 child execution。15m 不该直接照抄：pairs reversion 放到 15m 容易变成更慢、更少、更受 regime 影响的版本，和这份 repo 的 HFT 壳不完全同类。所以它对我们最有价值的映射不是“把整套系统搬到 15m”，而是： 把 pair selection 慢一点保留，把 spread alpha 放在 1m/3m/5m 里重验。
最大风险不是“回测太漂亮”，而是数学与执行口径不一致：
另外，repo 给出的 pair 里不少是中小币对，流动性与冲击成本可能比纯 majors 更差。也就是说，这套壳更像：
4bps / 8bps / 12bps / maker-taker split；LINK/SOL、ETH/BTC proxy 这种更接近可交易 pair；>60m 才回收，那就和 repo 宣称的 HFT 壳不匹配；1m 过于吃成本，就把它降级成：5m signal, 1m execution filter，而不是硬做秒级策略。Crypto_Stat-Arb_HFT_Modelreports/artifacts/quant_digests/2026-04-18_pairs_hft_shell_summary.jsonreports/artifacts/quant_digests/2026-04-18_pairs_hft_shell_events.csv