Backtesting Deribit BTC semanal

Hipótesis

Estrategia sistemática de venta de PUT-WRITING de una sola pata, totalmente garantizada con efectivo, sobre opciones semanales de BTC en Deribit, que captura la prima de riesgo de volatilidad cripto (VRP): la volatilidad implícita de las opciones de BTC supera estructuralmente la volatilidad realizada posterior, por lo que el vendedor de protección recibe una ventaja con el tiempo. Esta es la estrategia de opciones FIRST de la fábrica y cubre la mayor brecha de cuota (opciones 0.1% frente al objetivo de >= 15%),……Ver másVer menos

Estrategia sistemática de venta de PUT-WRITING de una sola pata, totalmente garantizada con efectivo, sobre opciones semanales de BTC en Deribit, que captura la prima de riesgo de volatilidad cripto (VRP): la volatilidad implícita de las opciones de BTC supera estructuralmente la volatilidad realizada posterior, por lo que el vendedor de protección recibe una ventaja con el tiempo. Esta es la estrategia de opciones FIRST de la fábrica y cubre la mayor brecha de cuota (opciones 0.1% frente al objetivo de >= 15%), a la vez que reduce la sobrerrepresentación de 80% BINANCE. En cada ciclo, la estrategia selecciona el vencimiento semanal más cercano de Deribit BTC (5-9 días más tarde) y vende una put OTM de ~20 delta ONE, totalmente garantizada con efectivo FULLY (sin apalancamiento ni riesgo de ajuste de margen; la pérdida máxima está limitada por el precio de ejercicio, equivalente a aceptar comprar BTC con descuento). La posición depende de dos filtros estructurales: (1) un filtro VRP: solo vende cuando la volatilidad implícita de 7 días ATM (de los datos de greeks/IV de Deribit) supera por un margen la volatilidad realizada de los últimos 10 días (IV/RV > ~1.15), para vender protección solo cuando está bien valorada; (2) un filtro de régimen y tendencia: solo vende cuando el precio spot de BTC está por encima de su SMA de 50 días, para evitar vender puts durante una tendencia bajista confirmada o una caída abrupta (el principal riesgo de cola de la venta de puts). Usar un solo instrumento por ciclo mantiene el backtest en la ruta de ejecución limpia y evita el artefacto de optimización por varias patas o fuentes adicionales. El desarrollador renueva semanalmente entre instrumentos put BTC cotizados en Deribit (cada ciclo, la estrategia selecciona del catálogo el precio de ejercicio y vencimiento adecuados).

La iteración 3 cambia el valor de configuración ONE; la lógica de la estrategia es idéntica byte por byte a la de la iteración 2 (solo se actualiza el docstring de PERF para registrar el diagnóstico). Perfilé el timeout real en vez de volver a adivinar: el subproceso del sandbox inició 22:05:22 y fue terminado en 22:10:24 (302s), y el coste es el trabajo por barra de NOT; todo el estado por barra ya era O(1) después de la iteración 2. El factor es el número de QUERIES del catálogo. BacktestRunner hace una llamada……Ver másVer menos

La iteración 3 cambia el valor de configuración ONE; la lógica de la estrategia es idéntica byte por byte a la de la iteración 2 (solo se actualiza el docstring de PERF para registrar el diagnóstico). Perfilé el timeout real en vez de volver a adivinar: el subproceso del sandbox inició 22:05:22 y fue terminado en 22:10:24 (302s), y el coste es el trabajo por barra de NOT; todo el estado por barra ya era O(1) después de la iteración 2. El factor es el número de QUERIES del catálogo. BacktestRunner hace una llamada a catalog.bars() por tipo de barra y, con 35,765 directorios de barras en data/catalog, cada llamada cuesta aproximadamente FIXED ~8.4s, independientemente de la carga (medido en este equipo: BTC-PERPETUAL 1-DAY, 365 barras -> 8.31s; BTC-10APR26-63000-P, 19 barras -> 8.27s; BTC-17APR26-68000-P, 24 barras -> 8.77s). La cadena semanal de 365 días se amplía a 52 tramos (confirmado en el registro de ejecución: 'Deribit chain discovered contracts=52'), así que solo la carga de datos costaba 53 * 8.4s ~= 445s; por eso el cambio de 1-HOUR a 1-DAY de la iteración 2 (24x barras menos) no cambió nada. Solución: lookback_days 365 -> 150, lo que da ~21 tramos semanales; la carga cuesta ~22 * 8.4s ~= 185s y la ejecución completa dura alrededor de ~230s, con margen suficiente bajo el límite de 300s. También ejecuté en seco la condición compuesta FULL con datos reales durante el periodo abreviado antes de enviarlo (según lo aprendido sobre la condición compuesta): en los últimos 150 días, la condición VRP está abierta 97/150 días, la condición de tendencia 70/150, y BOTH durante 51 días que abarcan 11 de 23 semanas naturales; así que la cadena venderá aproximadamente 8-11 puts, superando holgadamente la condición de >= 1 operaciones de Layer-3. Para recuperar parte de la muestra perdida por la cadena más corta, amplié entry_window_hours 96 -> 120 (sigue dentro del periodo base entry..expiry-24h), así también se vende durante una semana si las condiciones se abren a mitad del ciclo. Punto a señalar para el analista: el backtest real ahora cubre ~5 meses / ~10 operaciones en vez de un año; es una muestra escasa, pero el límite del sandbox lo impone el coste de catálogo de ~8.4s por tramo, y el cálculo está documentado en el docstring (~30 consultas es el máximo), así que se puede volver a ampliar el periodo si se corrige el coste de consulta del catálogo aguas arriba.

verifying_stuck_3_timeouts

Implementación

Estrategia semanal de venta de puts con efectivo como garantía sobre opciones OTM de BTC (una sola pata, ~6% OTM, ~7 DTE), con rollover semanal y cierre 24 h antes del vencimiento. Solo vende la put cuando se cumplen ambos filtros estructurales: un filtro VRP (volatilidad implícita de DVOL >= volatilidad realizada de los últimos 10 días 1.15x) y un filtro de tendencia (el precio spot por encima de su SMA de 50 días). El tamaño se calcula respecto al efectivo y al patrimonio (0.85 del patrimonio dividido por el precio spot, redondeado hacia abajo a 0.1 contrato), con apalancamiento 1.0, por lo que la pérdida máxima está limitada por el precio de ejercicio. El perpetuo de Deribit es el instrumento principal únicamente porque marca el reloj del rollover semanal; nunca se negocia el activo subyacente.

Resultados de verificación

Verificación fallida (Layer 4 — revisión de QA) [clase=not_measurable]: - [edge_concern] Las métricas impecables del sandbox (win_rate 1.0, PF 0.0, max_drawdown 0.0, avg_loss 0.0, Sharpe 5.30, +91% avg_trade_return_pct) son una BENIGN-WINDOW ARTIFACT: todo el riesgo de vender puts con efectivo como garantía está en la cola de desplomes, y este periodo de ~5 meses no incluyó ninguno, así que todas las puts ganaron. Cualquier venta de puts parece gratis hasta que llega un drawdown. avg_trade_return_pct 91.4% se……Ver másVer menos

Verificación fallida (Layer 4 — revisión de QA) [clase=not_measurable]: - [edge_concern] Las métricas impecables del sandbox (win_rate 1.0, PF 0.0, max_drawdown 0.0, avg_loss 0.0, Sharpe 5.30, +91% avg_trade_return_pct) son una BENIGN-WINDOW ARTIFACT: todo el riesgo de vender puts con efectivo como garantía está en la cola de desplomes, y este periodo de ~5 meses no incluyó ninguno, así que todas las puts ganaron. Cualquier venta de puts parece gratis hasta que llega un drawdown. avg_trade_return_pct 91.4% se calcula respecto a la prima (no al nominal del precio de ejercicio, ni es comparable con los mínimos de spot/futuros), y total_commission 0.0 en 16 operaciones de opciones de Deribit sugiere que no se aplican las comisiones de opciones; ambos factores hacen aún más halagador un resultado que no aporta información. - No se puede medir con la configuración actual. rolling_options.lookback_days está fijado en 150 (la solución del desarrollador al timeout de ~8.4s por consulta de catálogo y tramo), lo que limita la cadena negociable a ~5 meses y produce solo 16 ventas semanales. Ese límite está integrado en la configuración, por lo que todo el backtest queda limitado de la misma manera (~16 operaciones, por debajo del mínimo de opciones de ~30, L26). 16 ventas sin eventos de cola no permiten evaluar una venta de puts VRP, cuya ventaja/riesgo está definida por los drawdowns de desplomes: el periodo debe abarcar años para incluir eventos reales de cola izquierda. Existen DVOL y datos de la cadena de Deribit; el bloqueo es el coste de consulta de catálogo por tramo aguas arriba. Déjalo en espera hasta corregir ese coste, para ejecutar una cadena de varios años (>= 2yr, ~50-100 ventas sujetas a condiciones a lo largo de varios drawdowns) dentro del presupuesto; no te limites a alargar lookback_days (eso vuelve a provocar el timeout). - total_commission 0.0 en 16 operaciones de opciones de Deribit: Deribit cobra comisiones de opciones (mínimo de 0.03% subyacente o 12.5% de prima, más la liquidación). Si el motor no aplica comisiones de opciones, el PnL de capturar la prima está sobreestimado. Es una preocupación sobre la aplicación de comisiones del motor para el analista o ingeniero de backtesting, no un fallo del código de la estrategia.

Historial de iteraciones

Verificación fallida (Layer 3 — backtest del sandbox): la prueba rápida superó el límite de tiempo de 300s. Casi siempre esto significa que el trabajo por barra escala con el historial; por ejemplo, volver a recorrer toda la serie de financiación o de datos suplementarios, o reconstruir una lista y llamar a min()/sorted() dentro de calculate_signal()/on_bar() en cada barra. Precalcula los arrays ordenados de marcas de tiempo ONCE en __init__ y usa bisect, o almacena en caché las consultas por marca de tiempo, para que el coste por barra sea O(log n), no O(n).

Verificación fallida (revisión de la capa 4 — QA): - STRUCTURALLY UNMEASURABLE TRADE COUNT (L26 — cadencia de vencimiento de opciones x filtro). El entorno aislado produjo 12 operaciones en data_days=12 con la clásica señal degenerada e imposible de medir: win_rate 1.0, Sharpe 31.2, profit_factor 0.0, max_drawdown 0.0, avg_trade_return_pct 91.6% (una cifra imposible por operación para una estrategia de venta de puts con colateral en efectivo: el cálculo del nominal/rendimiento de opciones no es fiable). No son……Ver másVer menos

Verificación fallida (revisión de la capa 4 — QA): - STRUCTURALLY UNMEASURABLE TRADE COUNT (L26 — cadencia de vencimiento de opciones x filtro). El entorno aislado produjo 12 operaciones en data_days=12 con la clásica señal degenerada e imposible de medir: win_rate 1.0, Sharpe 31.2, profit_factor 0.0, max_drawdown 0.0, avg_trade_return_pct 91.6% (una cifra imposible por operación para una estrategia de venta de puts con colateral en efectivo: el cálculo del nominal/rendimiento de opciones no es fiable). No son señales de rendimiento reales. Según L26 (ventana/vencimiento x filtro superado): lookback_days se redujo de 365 a 150 para ajustarse al límite de 300s, y el filtro combinado VRP+tendencia solo se activa en ~11 de 23 semanas -> ~8-11 puts. ~10 operaciones está muy por debajo del mínimo de ~30 operaciones y no permite distinguir una ventaja de VRP del ruido. - INFRASTRUCTURE HARD-CAP hace que la muestra no sea medible con la parametrización ANY. Según el propio docstring del desarrollador, cada consulta catalog.bars() cuesta ~8.4s fijos y la ejecución está limitada a ~30 consultas (~250s) bajo el tiempo límite de 300s; por tanto, el backtest abarca AT MOST ~30 posiciones semanales (~7 meses) -> ~15 operaciones tras aplicar el filtro. Se forzó lookback_days=150 para que la ejecución sobreviviera al tiempo límite. Ningún ajuste del umbral supera el límite de ~30 posiciones impuesto por las consultas al catálogo. - PUT-WRITE TAIL-RISK MASKING. Una muestra win_rate 1.0 de ~10 operaciones es el resultado engañoso más MOST para una put vendida: significa que en la ventana no hubo ninguna semana de desplome, justo cuando una put con colateral en efectivo materializa su gran pérdida de cola izquierda. El resultado halagüeño del entorno aislado (todas las operaciones fueron ganadoras, drawdown cero, Sharpe 31) refleja la depreciación theta en semanas benignas y oculta el único riesgo que importa. - El código es CORRECT e implementa fielmente la hipótesis: orientación de venta de puts (P -> SELL), tamaño limitado por el strike y respaldado por efectivo, filtro VRP (atm_iv >= rv*vrp_ratio), filtro de tendencia (spot > SMA), consulta causal de DVOL (searchsorted right-1, sin anticipación), posiciones cerradas 24h antes de la liquidación europea, paso alternativo documentado sin filtro cuando falta IV (sin cambio silencioso de ventaja). La comprobación de corrección de opciones (#12) se supera. Se señala para que el desarrollador no persiga un error fantasma en el código.