源文件:research/quant_digests/2026-04-11_1826_deribit-rnd-vote-btc-direction-alpha.md
README.md + app.py)+ 2022/2023 BTC options 论文元数据 grounding + Deribit BTC options public live probeskew / tails / peak / band 这几层上朝同一方向倾斜,短周期 BTC perp 更值得沿该方向做;本质不是“IV 高低”,而是“期权分布形状已经把偏向哪边写出来了”。base alpha = 近到期期权隐含分布形状对 BTC 短周期方向有信息。
翻成人话: 不是单纯看 ATM IV 升了还是降了, 而是看 整个近到期 strike surface 拼出来的概率分布,到底更偏向上侧、下侧、肥尾、还是 mode 已经整体偏移。
如果这些 shape signal 朝同一边站队, 那它就不是 shared gate,也不是纯解释层; 它本身就是一条可以单独拿来交易 BTC 1m/3m/5m/15m perp 的 external-data directional raw alpha。
---
因为当前素材池里已经有不少:
但 “公开 BTC options surface → 短周期方向” 这条线还没有被单独展开成一条 clean raw alpha。
而且这次挑的不是“期权市场解释一切”这种大词, 而是一份 2026 repo 已经写成可运行信号机的旁支:
> 用 Deribit 公开期权链直接重建 risk-neutral PDF,然后把 PDF 的形状翻成 LONG / SHORT / NO TRADE。
这比再写一篇纯 filter / overlay 更能扩充 raw alpha 素材池。
---
主材料是 mario-badea (2026), iv-signal-scanner。 它最值得拿走的,不是 GUI,而是 app.py 里这条非常明确的骨架:
mark_iv;repo 用的是:
也就是说,它不是“用几个 strike 的 eyeballing”,而是试图把 整条 surface 的形状 压成可计算的分布。
compute_signals() 里有 4 个独立投票层:
p_up - p_dn 足够大则给 LONG,反之给 SHORT。±3% band;最终规则非常朴素:
> 只有当活跃投票全都指向同一边,才输出 final LONG / SHORT;否则 NO TRADE。
这点对 desk 很重要,因为它天然自带一个“没一致就别做”的 admission 机制。
---
Alexander, Deng, Feng, Wan (2022), _Net buying pressure and the information in bitcoin option trades_。
OpenAlex abstract 给出的核心点很值钱:
翻成人话: BTC options 不是一层被动贴现壳;链上的方向预期、尾部对冲需求、order imbalance 会真实写进曲面里。
Woebbeking (2021), _Cryptocurrency volatility markets_。
Crossref abstract 明确说:
翻成人话: 期权面不是只对“未来波动大小”有信息,对尾部风险结构本身也有信息。 这正好给 repo 的 tails / band / shape 读法做地基。
Winkel, Härdle (2023), _Pricing Kernels and Risk Premia implied in Bitcoin Options_。
这篇进一步说明:
对我们 desk 的翻译不是“去研究宏大风险偏好”,而是:
> front expiry 的分布形状,往往比远月更像短周期交易者的实时偏向。
所以第一轮最该测的是 nearest-expiry directional vote,不是把所有期限一锅炖。
---
我按 repo 的核心逻辑,直接对 Deribit BTC options 当前 11 个活跃 expiry 做了一次 live probe(见 artifact)。结果不算花,但很有用:
LONG = 6SHORT = 2NO TRADE = 325SEP26、25DEC26 则转成 SHORT。26JUN26、26MAR27 出现 投票冲突,所以 repo 规则会老实输出 NO TRADE。当前快照里,前 5 个最近 expiry 大致是这样:
12APR26(1d):p_up - p_dn ≈ +7.48%,final = LONG13APR26(2d):p_up - p_dn ≈ +3.25%,final = LONG14APR26(3d):p_up - p_dn ≈ +4.02%,final = LONG15APR26(4d):skew=LONG,tails=LONG,final = LONG17APR26(6d):skew=LONG,peak=LONG,final = LONG24APR26(13d):tails=LONG,peak=LONG,虽 skew 不再强,但 final 仍是 LONG25SEP26(167d):skew=SHORT、peak=SHORT、band=SHORT,final = SHORT25DEC26(258d):主要由 peak 下移给出 SHORT26JUN26(76d):skew/peak/band 偏 LONG,但 tails 偏 SHORT,最终 NO TRADE这对 desk 的启发很直接:
> front expiry 更像短周期交易信号;中远期更像 risk-premium / macro-vol 视角。
所以别把所有期限混成一个总分。
---
因为这条线可以单独闭环:
它不是“给别的 alpha 打补丁”才成立。
当然,它也可以顺手给别的东西做 overlay:
但那是二次用途。
第一性分类,仍然应该是 raw alpha。
---
若最近到期 BTC options surface 重建出的 RND 在 skew / tails / peak / band 上一致偏多或偏空,则未来 BTC perp 5m/15m 更容易沿该方向漂移。
每 1m 抓一次最近到期(先试 1d~7d)的期权链:
final_signal ∈ {LONG, SHORT, NO TRADE};LONG/SHORT;NO TRADE 直接空仓。先别搞复杂:
BTCUSDT perpfinal_signal 连续两帧一致才进1 / 3 / 5 根 5m bar15m × 1 / 2 / 4 根|p_up - p_dn| 或 active-vote count 分层至少显式跑三档:
4 bps round-trip(maker-ish)8 bps round-trip(保守 taker)12 bps round-trip(更严口径)真正该先回答的问题不是“回测曲线美不美”,而是:
> front-expiry RND vote 到底有没有稳定的 5m/15m sign edge。
---
Verdict:值得进研究池,而且优先级不低。
原因不是 repo 自带了一个漂亮 GUI, 而是它同时满足:
1m 采样 + BTC perp 5m/15m 就能开测但也要老实说两点:
所以这轮最对的推进方式不是“立刻信它”,而是:
> 先把它做成 front-expiry 方向信号,再看 BTC perp 上 5m/15m 成本后能不能活。
---
1m 拉最近到期 BTC options 链skew/tails/peak/band/finalBTCUSDT perp 1m/5m/15mfinal=LONG 后看未来 5m/15m/30m/60m sign hit-rate 与 mean bpsfinal=SHORT 同理NO TRADE 作为基准组2-frame confirmtime-stopsign-flip exit4/8/12bps 三档成本如果这四步里,5m 成本后还能留下明显正期望, 这张卡就该升到 replication queue; 如果只在极少数时段有效,那也至少能留下一个高信息量的 options-sidecar admission layer。
---
https://github.com/mario-badea/iv-signal-scannerhttps://github.com/mario-badea/iv-signal-scannerhttps://raw.githubusercontent.com/mario-badea/iv-signal-scanner/main/README.mdhttps://raw.githubusercontent.com/mario-badea/iv-signal-scanner/main/app.py10.1016/j.finmar.2022.100764https://doi.org/10.1016/j.finmar.2022.10076410.1007/s42521-021-00037-3https://doi.org/10.1007/s42521-021-00037-310.3390/risks11050085https://doi.org/10.3390/risks11050085/root/clawd/jerry/momentum/reports/artifacts/literature/deribit_rnd_signal_probe_2026-04-11.csv