Backtest de trading: put-write semanal de BTC com garantia em dinheiro na Deribit OTM — captura do prémio de risco de volatilidade, filtro IV>RV e tendência

Estratégia sistemática de PUT-WRITING, com uma única perna e totalmente garantida em dinheiro, sobre opções semanais de BTC na Deribit, que procura captar o prémio de risco de volatilidade das criptomoedas (VRP): a volatilidade implícita das opções de BTC excede estruturalmente a volatilidade realizada posteriormente, pelo que quem vende proteção recebe uma vantagem ao longo do tempo. Esta é a estratégia de opções FIRST da fábrica e preenche a maior lacuna da quota (opções 0.1% face à meta de >= 15%), reduzindo simultaneamente a sobrerrepresentação de 80% BINANCE. Em cada ciclo, a estratégia seleciona a expiração semanal mais próxima de BTC na Deribit (5-9 dias de distância) e vende ONE opção put OTM com delta de ~20, totalmente garantida em dinheiro FULLY (sem alavancagem nem risco de chamada de margem — a perda máxima fica limitada ao strike, equivalente a aceitar comprar BTC com desconto). A posição está sujeita a dois filtros estruturais: (1) um filtro de VRP — só vende quando a volatilidade implícita de ATM a 7 dias (a partir do feed de gregas/IV da Deribit) excede por uma margem a volatilidade realizada dos últimos 10 dias (IV/RV > ~1.15), para que a proteção só seja vendida quando estiver cara; (2) um filtro de regime e tendência — só vende quando o preço à vista de BTC está acima da sua SMA de 50 dias, para evitar vender opções put durante uma tendência descendente confirmada ou numa queda acentuada (o principal risco de cauda da venda de puts). Usar um único instrumento por ciclo mantém o backtest no percurso de execução limpo e evita o artefacto de otimização de múltiplas pernas ou feeds de pernas adicionais. O programador renova semanalmente posições em opções put de BTC listadas na Deribit (a estratégia escolhe o preço de exercício e a expiração adequados do catálogo em cada ciclo).

A iteração 3 altera o valor de configuração ONE; a lógica da estratégia é idêntica byte a byte à da iteração 2 (apenas a docstring PERF foi atualizada para registar o diagnóstico). Analisei o timeout real em vez de voltar a adivinhar: o subprocesso sandbox foi iniciado com 22:05:22 e terminado em 22:10:24 (302s); o custo é o trabalho NOT por barra — todo o estado por barra já era O(1) após a iteração 2. O que conta é o número de QUERIES do catálogo. O BacktestRunner faz uma chamada catalog.bars() por tipo de barra e, com 35,765 diretórios de barras em data/catalog, cada chamada custa cerca de FIXED ~8.4s, independentemente do conteúdo (medido nesta máquina: BTC-PERPETUAL 1-DAY, 365 barras -> 8.31s; BTC-10APR26-63000-P, 19 barras -> 8.27s; BTC-17APR26-68000-P, 24 barras -> 8.77s). A cadeia semanal de 365 dias expande-se para 52 pernas (confirmado no registo da execução: 'Deribit chain discovered contracts=52'), pelo que só o carregamento dos dados custou 53 * 8.4s ~= 445s — exatamente por isso a alteração da iteração 2 de 1-HOUR para 1-DAY (24x barras a menos) não mudou nada. Correção: lookback_days 365 -> 150, dando ~21 pernas semanais; assim, o carregamento custa ~22 * 8.4s ~= 185s e a execução completa demora cerca de ~230s, com margem real abaixo do limite de 300s. Antes de submeter, também fiz uma execução de teste do filtro composto FULL com dados reais, numa janela encurtada, seguindo a lição do filtro composto: nos últimos 150 dias, o filtro VRP está aberto em 97/150 dias, o filtro de tendência em 70/150, e BOTH em 51 dias que abrangem 11 de 23 semanas civis — assim, a cadeia escreverá cerca de 8-11 puts, superando confortavelmente o limite de >= 1 operações do Layer-3. Para recuperar parte da amostra perdida com a cadeia mais curta, alarguei entry_window_hours 96 -> 120 (ainda dentro da janela base de entrada..expiração de -24h), para que também se escreva numa semana cujos filtros abram a meio do ciclo. Aspeto a assinalar ao analista: o backtest real abrange agora ~5 meses / ~10 operações, em vez de um ano — é uma amostra reduzida, mas o limite da sandbox obriga a isso, dado o custo de catálogo de ~8.4s por perna; a aritmética está documentada na docstring (o máximo é ~30 consultas), para que a janela possa voltar a ser alargada caso o custo das consultas ao catálogo seja corrigido a montante.

A verificação falhou (Camada 4 — análise QA) [classe=not_measurable]: - [edge_concern] As métricas impecáveis da sandbox (win_rate 1.0, PF 0.0, max_drawdown 0.0, avg_loss 0.0, Sharpe 5.30, +91% avg_trade_return_pct) são uma BENIGN-WINDOW ARTIFACT — todo o risco da venda de puts garantida por numerário está na cauda de quedas bruscas, e esta janela de ~5 meses não incluiu nenhuma, pelo que todas as puts foram vencedoras. Qualquer posição de venda de puts parece gratuita até ocorrer um drawdown. avg_trade_return_pct 91.4% é relativo ao prémio (não ao valor nocional do strike, nem comparável aos mínimos à vista/futuros), e total_commission 0.0 em 16 operações de opções da Deribit sugere que as comissões das opções não são aplicadas — ambos tornam ainda mais favorável um resultado sem valor informativo. - Não é possível medir com esta configuração. rolling_options.lookback_days está fixado em 150 (correção do programador para o timeout de ~8.4s por perna nas consultas ao catálogo), limitando a cadeia transacionável a ~5 meses e produzindo apenas 16 posições semanais de venda de puts. Esse limite está incorporado na configuração, pelo que o backtest completo tem o mesmo limite (~16 operações, abaixo do mínimo de ~30 opções, L26). 16 posições de venda sem eventos extremos não permitem avaliar uma posição de venda de puts VRP, cuja vantagem/risco é definido pelos drawdowns durante quedas bruscas — a janela tem de abranger anos para incluir eventos reais de cauda esquerda. DVOL + os dados da cadeia da Deribit existem; o bloqueio é o custo por perna das consultas ao catálogo a montante. Manter em espera até esse custo ser corrigido, para que uma cadeia de vários anos (>= 2 anos, ~50-100 posições filtradas ao longo de vários drawdowns) possa ser executada dentro do orçamento; não aumentar simplesmente lookback_days (isso volta a causar o timeout). - total_commission 0.0 em 16 operações de opções da Deribit — a Deribit cobra comissões de opções (mín. 0.03% do ativo subjacente ou 12.5% do prémio, mais liquidação). Se o motor não aplicar comissões às opções, o PnL da captura do prémio fica sobrestimado. Questão da aplicação de comissões pelo motor para o analista/engenheiro de backtesting, não uma falha no código da estratégia.

A verificação falhou (Layer 4 — análise QA): - STRUCTURALLY UNMEASURABLE TRADE COUNT (L26 — cadência de expiração das opções x filtros). A sandbox produziu 12 operações ao longo de data_days=12, com a assinatura clássica de degeneração impossível de medir: win_rate 1.0, Sharpe 31.2, profit_factor 0.0, max_drawdown 0.0, avg_trade_return_pct 91.6% (um valor impossível por operação para uma venda de puts garantida por numerário — o cálculo do valor nocional/retorno das opções não é fiável). Estes não são sinais de desempenho reais. Segundo L26 (janela/expiração x filtros aprovados): lookback_days foi reduzido de 365 para 150 para respeitar o limite de 300s, e o filtro composto VRP+tendência abre em apenas ~11 de 23 semanas -> ~8-11 puts. ~10 operações fica muito abaixo do mínimo de ~30 operações e não permite distinguir uma vantagem VRP do ruído. - INFRASTRUCTURE HARD-CAP torna a amostra impossível de medir com a parametrização ANY. Segundo a própria docstring do programador, cada consulta catalog.bars() custa cerca de 8.4s fixos e a execução está limitada a ~30 consultas (~250s) pelo timeout de 300s; assim, o backtest abrange AT MOST ~30 pernas semanais (~7 meses) -> ~15 operações após os filtros. lookback_days=150 foi imposto para evitar o timeout. Nenhum ajuste de limiar ultrapassa o limite de ~30 pernas de consulta ao catálogo. - PUT-WRITE TAIL-RISK MASKING. Uma amostra de ~10 operações win_rate 1.0 é o resultado mais MOST enganador para uma put vendida: significa que a janela não incluiu nenhuma semana de queda brusca, precisamente quando uma put garantida por numerário sofre a sua perda extrema na cauda esquerda. Os resultados favoráveis da sandbox (todas as operações vencedoras, drawdown zero, Sharpe 31) refletem a erosão temporal do prémio em semanas benignas e ocultam o único risco relevante. - O código está CORRECT e implementa fielmente a hipótese: orientação de venda de puts (P -> SELL), dimensionamento garantido por numerário e limitado pelo preço de exercício, filtro VRP (atm_iv >= rv*vrp_ratio), filtro de tendência (preço à vista > SMA), consulta causal DVOL (searchsorted right-1, sem antecipação de dados), pernas fechadas 24h antes da liquidação europeia e passagem documentada sem filtro quando IV está em falta (sem troca silenciosa da vantagem). A correção das opções (#12) foi aprovada. Registado para que o programador não procure um erro de código inexistente.