Cesta spot long-only de grandes criptoactivos con objetivo de volatilidad (4 BINANCE_SPOT grandes activos: BTC/ETH/SOL/BNB, barras diarias, mantiene una cesta con igual ponderación de activos por encima de su tendencia de largo plazo, pero aplica SCALE TOTAL DEPLOYED EXPOSURE en sentido inverso a la volatilidad realizada de la cartera para alcanzar un objetivo de volatilidad constante, baja rotación, 3 parámetros)

Una cesta LONG-ONLY de grandes criptoactivos SPOT (BTC/ETH/SOL/BNB) cuya ventaja no es NOT una señal direccional, sino PORTFOLIO VOLATILITY MANAGEMENT: la prima documentada de cartera gestionada por volatilidad de Moreira-Muir, que nunca se ha probado en esta fábrica. Mecanismo: mantiene una cartera con igual ponderación de los grandes activos por encima de su tendencia de largo plazo, pero ajusta el porcentaje TOTAL desplegado en sentido inverso a la volatilidad realizada reciente de la cesta para que la cartera apunte a una volatilidad constante. Como la volatilidad realizada persiste y los regímenes de alta volatilidad en cripto generan sistemáticamente peores rendimientos ajustados al riesgo (la volatilidad se agrupa y los drawdowns ocurren en estados de alta volatilidad), reducir la exposición cuando la volatilidad es alta y aumentarla cuando es baja mejora el Sharpe y recorta mucho el drawdown frente a comprar y mantener con exposición fija: una ventaja independiente de la dirección del precio. Es estructuralmente distinta de todas las familias descartadas o en desarrollo: NOT una estrategia de reversión (no opera contra los movimientos; las estrategias hermanas de reversión, prima y compresión OI perdieron dinero), NOT un detonante de eventos raros (la exposición es un estado continuo, lo que evita la muerte no_trades), NOT una rotación transversal RANK (sin clasificar rendimientos ni elegir los K mejores; se mantienen los grandes activos con tendencia ALL; falta el mecanismo agotado de L32), NOT carry de financiación (L33), NOT opciones (sin límite por recuento de operaciones), NOT la cesta de reversión tras caídas profundas que acaba de sobreajustarse (IS 8.3 → OOS -2.64; aquí no hay entradas de reversión que ajustar a la curva: las únicas cantidades ajustadas son un objetivo de volatilidad y dos periodos de análisis). Spot long-only (CASH) es estructuralmente inmune a liquidaciones por apalancamiento. Incorpora el mercado BINANCE_SPOT poco representado y el segmento macro de horizonte largo casi vacío; la baja rotación (rebalanceo semanal y banda sin operaciones) hace insignificante el coste de la operación de ida y vuelta ~0.20%.

Aborda los dos hallazgos accionables de Layer-4 con cambios mínimos y conserva la lógica de escala por volatilidad que superó las capas anteriores. (1) Se corrige la sospecha de ejecución/contabilidad señalada por QA en la ruta de salida: un activo que sale de la posición (objetivo 0) ahora se cierra mediante _submit_exit_position (cierre reduce-only), que contabiliza correctamente la reducción y libera CASH antes del ciclo de compras, en vez de una SELL enviada mediante _submit_entry_instrument; los recortes parciales por volatilidad siguen siendo ventas SELL limitadas que solo reducen una posición larga. (2) Se resuelve el problema del borde no medible o apenas ejercitado (solo 6 operaciones porque el filtro SMA(100) mantuvo la cesta en efectivo casi toda la ventana, de modo que las operaciones cerradas fueron todas perdedoras por ruptura de tendencia mientras las ganadoras seguían abiertas): se acorta trend_len 100->50 (la cesta permanece invertida durante mucho más tiempo de la ventana, así que el rebalanceo semanal de volatilidad inversa opera y pone realmente a prueba la capa de gestión de volatilidad de Moreira-Muir) y se estrecha rebalance_band 0.15->0.10 (más ajustes semanales del tamaño según la volatilidad y cruces de elegibilidad superan la banda). En conjunto, esto eleva el número de operaciones hacia el mínimo necesario para medirlas entre cuatro activos y ~50 rebalanceos semanales. La fórmula de inversión de volatilidad inversa, el filtro de tendencia por activo, la valoración _portfolio_value con capital real NAV, el orden de cierres antes de BUYS (SELLS) y el tamaño long-only CASH (bruto <= 0.95x, apalancamiento 1.0) no cambian; las capas 1-3 siguen aprobadas y las importaciones siguen limpias. Reconozco la preocupación de fondo de QA: una estrategia pura de OHLCV filtrada por SMA tiene pocas probabilidades de sobrevivir, y una capa de volatilidad no puede crear una expectativa positiva a partir de una cesta que mantiene posiciones según la tendencia durante una ventana bajista. Eso es inherente a la premisa declarada de la hipótesis (una prima de gestión de volatilidad independiente de la dirección) y no puede resolverse sin abandonarla o añadir un feed, lo que excedería una iteración de cambios mínimos. Estas correcciones hacen que la estrategia se ejecute y mida correctamente, para que el analista pueda evaluar la prima en un backtest fiable y con una muestra suficiente, en vez de basarse en un resultado atípico de 6 operaciones.

El backtest no es fiable: la contabilidad del capital está corrupta. total_return +8,697% (87x) es imposible para una cesta spot long-only sin apalancamiento (<= 1x), y los rendimientos diarios de +241% (2021-05-20), +158% (2019-07-04), +88.7% y +84.3% son físicamente imposibles para una cartera long-only de <= 0.95x; avg_win $426k / largest_loss -$2.9M en una cuenta de $100k (oscilaciones del capital de 26-29x) más una rotación de 635 (frente al rebalanceo semanal de baja rotación declarado) muestran que el dimensionamiento y el rebalanceo despliegan demasiado capital y lo capitalizan incorrectamente. La contradicción interna lo confirma: rentabilidad destacada de +8,697%, pero Sharpe de -0.087, avg_trade_return_pct -0.785% (negativo), information_ratio -0.21, PSR 0.375; por tanto, el artefacto no muestra una ventaja real (asimetría -4.5, curtosis 67.7, max_dd CI alta ~100%). Señalo el síntoma sin afirmar cuál es el error exacto, pues no lo he rastreado. Esta ya es la iteración 2: el desarrollador rehízo la contabilidad de salidas tras una alerta de «contabilidad sospechosa» QA, y el resultado ahora tiene aún más defectos; optimizar la serie corrupta solo ajustaría la curva a artefactos. La familia subyacente también está agotada: el modelo hermano VolatilityManagedLongMajorsBasketDaily se abandonó en esta sesión con IR -0.60 y ~0 de alfa frente a su cesta (gestionar la volatilidad de una cesta long de grandes criptoactivos añade valor activo negativo); aquí, beta 0.51 / benchmark_correlation 0.70 y alfa negativo tras la capa adicional apuntan en la misma dirección. Optimizar vol_target/trend_len/vol_lookback no puede corregir un defecto de dimensionamiento o contabilidad ni crear una ventaja que la estructura de la familia no tiene. Abandonar.

Verificación fallida (capa 4 — revisión QA): - El entorno aislado muestra la señal de defecto de código que la fábrica diagnostica repetidamente como fallo de ventaja: win_rate = 0.0 AND profit_factor = 0.0 (las 6 operaciones cerradas perdieron; beneficio bruto exactamente cero), Sharpe -1.94, total_return -33.3% == max_drawdown. La polaridad direccional y de escala parece correcta al inspeccionarla (despliegue inverso a la volatilidad = min(vol_target/basket_vol, bruto); filtro de tendencia cierre>SMA; reducción long-only limitada a lo mantenido), así que el posible fallo restante está en la ruta EXECUTION/ACCOUNTING. Hay dos sospechas: (1) las reducciones envían ventas mediante _submit_entry_instrument(OrderSide.SELL) en vez de _submit_exit_position; verifica que esto reduzca la posición long en CASH y que no se rechace ni registre mal; (2) el bucle BUY vuelve a calcular _held_qty tras enviar las ventas, pero las ejecuciones no son síncronas dentro de on_bar, así que las compras se dimensionan usando capital que las ventas pendientes aún no han liberado. PF exactamente 0.0 con todas las operaciones en pérdidas debe diagnosticarse como un error, no remitirse como comisiones o falta de ventaja. - No medible: 6 operaciones en 363 días son un orden de magnitud menos que el mínimo de ~100 operaciones, así que win_rate/PF/Sharpe no aportan señal. Un rebalanceo semanal de 4 activos debería producir ~200 eventos de rebalanceo, pero generó 6 operaciones: la estrategia permaneció casi todo el periodo en efectivo (el filtro SMA(100) rara vez se cumplió), lo que explica la correlación con el índice de referencia de 0.11 pese a la exposición en posiciones de 76% y significa que apenas se probó la ventaja de gestionar la volatilidad. - Mecanismo puro OHLCV (filtro de tendencia SMA + ajuste por volatilidad realizada, sin ventaja direccional). OHLCV puro tiene una supervivencia de 0% en 213 ejecuciones previas, y los filtros de tendencia SMA son una clase que se abandona repetidamente. La capa de volatilidad es independiente de la dirección y no puede crear una expectativa positiva si la cesta que mantiene posiciones por tendencia carece de ella; además, el resultado contradice la afirmación de la hipótesis de que reduce el drawdown (33% drawdown).