Deribit BTC 每周现金担保 OTM 卖出看跌——波动率风险溢价收割，IV>RV 门控，趋势过滤

假设

这是一种单腿、全额抵押（现金担保）的系统化 PUT-WRITING 策略，交易于 Deribit BTC 每周期权，用于收割加密货币波动率风险溢价（VRP）：BTC 期权的隐含波动率在结构上系统性地高于随后实现的波动率，因此保险的卖方能够长期获得一份优势收益。这是本工厂的 FIRST 期权策略，填补了最大的配额缺口（期权 0.1% 相对于 >=15% 的目标），同时缓解了 80% BINANCE 占比过高的问题。每个周期该策略都会选取最近的 Deribit BTC 每周到期日（5-9 天后到期），卖出 ONE 一份约 20 delta 的 OTM 看跌期权，FULLY 以现金全额抵押（无杠杆，无追加保证金风险——最大亏损受行权价约束，即等价于同意以折扣价买入 BTC）。该仓位受两个结构性过滤器门控：（1）VRP 门控——仅当 7 天 ATM 隐含波动率（来自 Deribit 希腊值/IV 数据源）超过过去 10 天已实现波动率一定幅度时才卖出（IV/RV > 约 1.15），即只在保险定价较为丰厚时才卖出；（2）行情状态/趋势门控——仅当 BTC 现货价格高于其 50 天 SMA 时才卖出，以避免在确认下跌趋势/接飞刀行情中卖出看跌期权（这是卖出看跌期权策略最主要的尾部风险）。每个周期只交易单一标的，使回测保持在干净的引擎路径上，避免了多腿/额外腿数据源带来的优化伪影。开发者每周在已上市的 Deribit BTC 看跌合约之间进行展期（策略每个周期都会从目录中挑选合适的行权价/到期日）。

verifying_stuck_3_timeouts

实现

在 Deribit BTC 期权上进行每周现金担保（cash-secured）的 OTM 卖出看跌交易（单腿，约 6% OTM，约 7 DTE），每周展期，并在到期前 24 小时平仓。仅当两个结构性门控同时开启时才卖出看跌期权：一个是 VRP 门控（Deribit DVOL 隐含波动率 >= 过去 10 天已实现波动率的 1.15x 倍），另一个是趋势门控（现货价格高于其 50 天 SMA）。仓位规模按现金担保/相对权益计算（权益的 0.85 除以现货价格，下限为 0.1 份合约），杠杆 1.0，因此最大亏损受行权价约束。Deribit 永续合约仅作为每周展期时钟使用的主要标的；标的资产本身从不被交易。

验证结果

验证失败（第4层——QA评审）[分类=not_measurable]： - [edge_concern] 沙箱中近乎完美的各项指标（win_rate 1.0，PF 0.0，max_drawdown 0.0，avg_loss 0.0，夏普比率 5.30，+91% avg_trade_return_pct）是一种 BENIGN-WINDOW ARTIFACT——现金担保卖出看跌期权的全部风险都在于崩盘尾部，而这约 5 个月的窗口中一次都没有采样到，因此每一笔看跌期权都是盈利的。任何卖出看跌策略在回撤真正发生之前看起来都是无风险的。avg_trade_return_pct 91.4% 是相对权利金计算的（而非行权价名义本金计算，无法与现货/期货的下限相比较），而在 16 笔 Deribit 期权交易中 total_commission 0.0 表明期权手续费可能并未被应用——这两点都进一步美化了这个本不具备参考价值的结果。 - 按当前配置无法测量。rolling_options.lookback_days 被固定为 150（这是开发者为解决约每腿 8.4秒 的目录查询超时问题所做的修复），将可交易的期权链限制在约 5 个月内，只产生 16 笔每周卖出交易。这个上限被固化在配置中，因此完整回测同样受到相同的限制（约 16 笔交易，低于约 30 笔期权交易下限，L26）。16 这种不含尾部风险的卖出交易样本无法评估一个优势/风险由崩盘回撤定义的 VRP 卖出看跌策略——窗口必须跨越数年才能采样到真实的左尾事件。DVOL + Deribit 期权链数据是存在的；真正的障碍在于上游每条腿的目录查询开销。应将其搁置，直到该开销问题得到修复，使跨越数年的期权链（>= 2 年，跨越多次回撤约 50-100 笔门控通过的卖出交易）能够在预算内运行；不要仅仅通过延长 lookback_days（这会重新引入超时问题）来解决。 - 在 16 笔 Deribit 期权交易中 total_commission 0.0——Deribit 会收取期权手续费（最低为标的的 0.03%，或权利金的 12.5%，外加结算费用）。如果引擎没有应用期权佣金，那么权利金收割策略的盈亏将被高估。这是需要分析师/回测工程师关注的引擎手续费应用问题，而非策略代码本身的缺陷。

迭代历史

验证失败（第3层——沙箱回测）：冒烟测试超出了 300秒 的实际运行时间限制。这几乎总是意味着存在随历史长度线性增长的逐bar计算——例如每次都重新扫描完整的资金费率/补充数据序列，或者在每个bar内的 calculate_signal()/on_bar() 中重建列表并调用 min()/sorted()。应在 __init__ 中预先计算好排序后的时间戳数组 ONCE 并使用 bisect，或使用以时间戳为键的缓存查找，使逐bar开销为 O(log n) 而非 O(n)。

验证失败（第4层——QA评审）： - STRUCTURALLY UNMEASURABLE TRADE COUNT（L26——期权到期节奏 x 门控）。沙箱在 data_days=12 的条件下产生了 12 笔交易，呈现出典型的不可测量退化特征：win_rate 1.0，夏普比率 31.2，profit_factor 0.0，max_drawdown 0.0，avg_trade_return_pct 91.6%（对于现金担保卖出看跌来说，这是一个不可能出现的单笔交易数字——期权名义本金/收益的计算并不可信）。这些都不是真实的表现信号。根据 L26（窗口/到期 x 门控通过率）：lookback_days 被从 365 缩减到 150 以适应 300秒 的上限，而复合 VRP+趋势门控在 23 周中仅开启约 11 -> 约 8-11 笔看跌期权卖出。约 10 笔交易远低于约 30 笔的下限要求，无法将 VRP 的优势与噪声区分开来。 - INFRASTRUCTURE HARD-CAP 使得在 ANY 参数化下样本不可测量。根据开发者自己的文档字符串，每次 catalog.bars() 查询固定耗费约 8.4秒，在 300秒 超时限制下，运行被限制在约 30 次查询（约 250秒）以内，因此回测覆盖 AT MOST 约 30 个每周合约腿（约 7 个月）——门控筛选后约为 15 笔交易。lookback_days=150 是为了在超时限制下勉强存活而被迫设定的。任何阈值调整都无法摆脱约 30 条腿的目录查询上限。 - PUT-WRITE TAIL-RISK MASKING。对于卖出看跌期权而言，约 10 笔交易的 win_rate 1.0 样本是MOST最具误导性的结果：这意味着该窗口内没有出现崩盘周，而崩盘周正是现金担保看跌期权实现其肥尾左侧亏损的时刻。这个看起来令人满意的沙箱结果（全胜、零回撤、夏普比率 31）不过是温和周里的theta衰减收益，掩盖了唯一真正重要的风险。 - 代码本身是 CORRECT 的，忠实地实现了该假设：卖出看跌的方向性（P -> SELL），现金担保、以行权价为界的仓位规模，VRP 门控（atm_iv >= rv*vrp_ratio），趋势门控（现货 > SMA），因果性的 DVOL 查找（searchsorted right-1，无前视偏差），合约腿在欧式结算前 24 小时平仓，当 IV 缺失时有据可查的无门控直通处理（未静默替换标的）。期权正确性检查（#12）通过。特此说明，以免开发者去追查一个并不存在的代码缺陷。