源文件：research/quant_digests/2026-04-04_0416_obi-microprice-pairs-shell-alpha.md
README.md + data_loader.py + analyzer.py + optimizer.py + fix_strategies.py + main.cpp + strategies.json）spread z-score fade 这条 raw alpha，再叠一层 microprice / OBI 的执行 veto先回答 base alpha：这篇东西的 base alpha 很清楚，就是 cointegrated spread mean reversion。microprice / OBI 不是 alpha 本体，而是一个“别在最差盘口状态硬追进去”的执行过滤层。也正因为 base alpha 能说清，它才配当本轮主 digest，而不是一篇泛泛的 microstructure 综述。
这轮主看的是一个 2026 年的新 repo：
SamarthChaudhary-22（GitHub owner）created_at = 2026-01-18，pushed_at = 2026-02-05，默认分支 mainREADME.mddata_loader.pyanalyzer.pyoptimizer.pyfix_strategies.pystrategies.jsonmain.cpp!bookTicker、用 microprice 和 OBI 做准入、走 Binance Futures 下单为什么这条线值得写？因为我们最近虽然已经积累了不少 pairs / stat-arb 素材，但很多材料要么偏论文、要么偏 dashboard、要么只讲 pair admission。这份 repo 的稀缺性在于：它把 raw alpha、entry/exit、执行 veto、风险熔断都放进了同一条链路里。
先翻成人话：
> repo 真正可迁移的核心，不是“42 微秒 / 4~7ms RTT”这些工程口径，而是： > 1) 先在 liquid perp universe 里找会回归的 spread； > 2) 当 spread 偏离到极端 z-score 时做 fade； > 3) 但只有在盘口没有明显继续朝你不利方向失衡时才放行。
这和“纯配对回归”相比，多了一层很实用的 short-cycle desk 思维：
|z| >= 2 都立刻做，先看盘口是否太 toxic这条结构对 1m / 3m / 5m / 15m 都有意义，因为它把策略拆成了两个可以独立实验的部件：
raw alpha: spread fadefilter / veto: microprice / OBIdata_loader.py 直接定义了研究入口：
1m365 天quoteVolume 选 top 50 liquid USDT-M pairs这点很关键：它不是拿一个小样本 pair 做漂亮故事，而是明确从可交易 universe出发。对于我们 desk，最容易移植的做法就是把这个 universe 缩成：
top 15~25 流动性最稳定 perpanalyzer.py 的筛选非常朴素但够实用：
1m close resample 成 1h，提高筛选速度MIN_CORRELATION = 0.85P_VALUE_THRESHOLD = 0.05MAX_HALF_LIFE = 240（最大 4 小时）MIN_OVERLAP_HOURS = 1000也就是说，repo 的 admission 逻辑不是“看着像一对就上”，而是：
对我们 desk，这条线最值得抄的不是具体数字，而是顺序：
> 先做“会不会回、回得够不够快”的 admission，再做 entry。
optimizer.py 和 main.cpp 拼起来后，baseline 壳基本是：
30 / 60 / 120 / 240 / 360 分钟1.5 / 2.0 / 2.5 / 3.00 / 0.25 / 0.54 / 5 / 8FEE_PCT = 0.0012（约 12bps）而 live C++ 版本最后写死成：
Z_ENTRY = 2.0Z_EXIT = 0.5BET_SIZE = 1000.0这基本就是一个完整的 raw alpha baseline：
z > +2：short spreadz < -2：long spreadz 回到 ±0.5：平仓main.cpp 从 Binance !bookTicker 取：
然后构造：
(BidPrice * AskVol + AskPrice * BidVol) / (BidVol + AskVol)(bidVol - askVol) / (bidVol + askVol)这层逻辑最有意思的地方在于：它不是拿 OBI 来预测方向，而是用它给 spread fade 做 veto。
但代码里的阈值其实很温和：
OBI_LONG_THRESHOLD = -0.2OBI_SHORT_THRESHOLD = 0.2对应到入场条件：
z > 2 时，只要 leg1 不是特别 bid-heavy、leg2 不是特别 ask-heavy，就允许 short spreadz < -2 时，只要 leg1 不是特别 ask-heavy、leg2 不是特别 bid-heavy，就允许 long spread所以更准确的翻译不是“OBI 强确认”，而是：
> 别在盘口已经明显继续对你不利时，硬做这笔 spread fade。
这非常像我们 desk 该用的执行 veto，而不是主 alpha。
因为它直接扩 raw alpha 素材池，而且还是一条能独立落地完整策略的 raw alpha：
entry / exit / sizing / risk / cost / execution veto 的完整 relative-value shell尤其对当前 desk，价值在三点：
15m signal + 5m execution veto 就能先跑 baseline也就是说，这一篇不是在补“pairs 的概念课”，而是在补：
> 如何把一个本来容易停留在论文层的 pairs alpha，变成 short-cycle 可执行组件。
这恰恰是这篇 digest 最值得记住的地方：思路值得抄，代码不能盲抄。
main.cpp 读取 strategies.json 时，期待字段有：
leg1leg2hedge_ratiomeanstd_dev但 optimizer.py 默认输出的是：
leg1leg2hedge_ratiowindow_minutesentry_zexit_zstop_z也就是说：优化器输出和 live engine 读取字段不匹配。 repo 里额外放了一个 fix_strategies.py 去补 mean / std_dev，这说明作者自己也踩到了这条管线断点。
对我们 desk，这个 bug 的启发反而很实用：
> 不要把 pair selection、threshold optimization、live execution 混成一锅；三层产物要有明确 schema。
repo 的研究链路是：
1m 数据下载1h 数据筛 pair1m / tick 级执行这不是不能做，但有个很现实的问题：
1h 上看到的协整关系，未必天然能承受 tick 级噪音1m 上设的 z=2，也未必和 1h 上筛出来的 half-life 完全一致所以这条线更适合 desk 的改法是：
15m 做 pair admission + primary signal5m / 1m 做 execution veto而不是直接把 1h admission -> tick execution 原封不动搬过来。
repo 自带的 strategies.json 里虽然吐出了 22 组候选，但很多 pair 很明显偏杂：
1000PEPEUSDT / FARTCOINUSDTDOGEUSDT / HYPEUSDTAVAXUSDT / DOGEUSDT（hedge ratio 还高到 104.97）HYPEUSDT / NEARUSDT这不代表 alpha 一定没用，但说明：
BTC / ETH / SOL / XRP / ADA / DOGE / LINK / LTC / BNB 这种主流腿开始更稳raw alphacointegration spread mean reversionmicroprice / OBI如果把 repo 翻译成 desk 版，我会建议这样落：
10~20 个 perpz-stoptime stop先在 15m 上做一版干净 baseline：
10~20 个主流 perp30~60d|z| >= 2|z| <= 0.5|z| >= 4min(4h, 1.5 × estimated half-life)双腿手续费 + 2~4 ticks 滑点 proxy + funding目标不是做漂亮收益，而是先回答：
如果 15m baseline 过关，再上 5m / 1m 的盘口层：
也就是说，这里要测的是：
> OBI 能不能把“同样的 spread fade”变得更能成交、更少挨打。
因为这类策略最容易在 paper 上好看、上线后死在：
所以最合理的下一步不是“马上实盘”，而是：
15m 历史 baseline5m/1m live paper 执行 veto1m / 3m / 5m / 15m 的具体建议15m：最适合做 primary signal因为 spread 回归在这个频段更容易和成本拉开一点点距离。
5m：最适合做执行与 time management例如更早减仓、盘口不对劲就 veto、或者把 time stop 切细。
3m / 1m：更像 execution layer，不建议一开始就拿来当主信号层否则很容易把本来能做的 pairs alpha，压成一条被噪音和滑点吃死的伪 HFT 策略。
这份 2026 repo 最值得我们 desk 收进研究池的，不是“C++ HFT 引擎”这个表层，而是：
> 把 cointegration spread mean reversion 这条 raw alpha，明确拆成 admission -> z-score entry/exit -> microprice/OBI veto -> kill switch 的完整策略壳。
它的优点是：raw alpha 清楚、组件齐、能快速做最小实验； 它的缺点也同样清楚：repo as-is 有 pipeline bug，pair universe 也偏脏，不能直接照搬。
但对当前 short-cycle desk，这恰好是好事：它不是要我们抄答案，而是给了一套很适合继续提纯成 production 组件的 raw alpha 母板。
BTC/ETH/SOL/XRP/ADA/DOGE/LINK/LTC/BNB，滚动 30~60d 做 admission。15m 入场信号，显式扣双腿成本与 funding。bookTicker，比较“有 / 无 OBI veto”的：ticker/24hr, klines, !bookTicker, positionRisk).