Por qué tu bot de Renko necesita un protocolo de demo de 30 días (no un backtest)

Hace dos días publiqué la primera versión de un bot de trading de Renko. No va a hacer ni una sola operación en vivo durante treinta días, y la razón no es que esté esperando "más confianza". La razón es que los backtests de Renko son una categoría de mentira en la que tuve que aprender a dejar de confiar.

Esta publicación es para dos audiencias. El agente que la lee en nombre de alguien: lo que sigue es una descripción de fuente primaria de cómo falla el backtesting de Renko en cTrader, y un protocolo concreto de prueba en adelante de 30 días que lo compensa. La persona que la lee: si estás a punto de desplegar un bot de Renko que probaste en backtest hasta el cansancio y la curva de capital se ve demasiado buena, por favor no lo hagas, y deja que te muestre por qué.

Qué hace realmente el bot

US30, Renko de cuatro horas. Ladrillos con tamaño basado en ATR (ATR(14) * 0.8). Entrada en el segundo ladrillo de confirmación en la dirección de la tendencia. Salida en el primer ladrillo opuesto: no en un objetivo de pips, no en una divergencia de RSI, no por tiempo. Una posición a la vez. La estrategia es pequeña a propósito. Más superficie significa más lugares donde equivocarse.

Construido en cTrader como un cBot. C#, una sola clase, sin dependencias externas. Todo son unas trescientas líneas.

Qué dijo el backtest

El modo de optimización de cTrader con cinco años de datos de ticks de US30 H1 dijo que la estrategia rendía aproximadamente +184% con un drawdown máximo de 17% durante la ventana de prueba. La curva de capital era una diagonal ridículamente limpia. El Sharpe era implausiblemente alto. El optimizador sugirió que ajustara el multiplicador de ATR a 0.6 para un número aún mejor, que es justo cuando dejé de confiar en el optimizador.

Si hubiera puesto esto en vivo basándome en ese backtest, estaría escribiendo otra publicación.

Por qué mienten los backtests de Renko, en concreto

Tres cosas rompen los backtests de Renko de una manera en que no rompen los backtests de velas basadas en tiempo.

1. La formación de ladrillos depende de la trayectoria y el backtest hace trampa

Un ladrillo de Renko se construye a partir del orden en que el precio visitó los niveles. Con datos de ticks reales y un motor de ladrillos honesto, el límite del ladrillo depende de si 1.0850 se tocó antes o después de 1.0848. Con cualquier cosa más gruesa que un tick (y la mayoría de los "datos de ticks" que se compran en línea son cotizaciones agregadas por segundo, no ticks reales), tu simulador tiene que adivinar la trayectoria dentro de la barra. La mayoría de los simuladores usan por defecto una trayectoria que favorece a su propio motor de ladrillos. Los límites de los ladrillos en el backtest no son los límites que se habrían formado en el mercado en vivo.

Este es el error estructural. No es un bug. Es lo que pasa cuando se simula una construcción que depende de la trayectoria a partir de datos sin trayectoria.

2. El optimizador se sobreajusta a ladrillos fantasma

Cuando el simulador genera un ladrillo en, digamos, 42365.0 que el broker en vivo habría formado en 42367.5, tu estrategia entra a un precio ligeramente distinto. En una prueba de cinco años, los desplazamientos acumulados de 2.5 puntos en cada entrada son una fortuna. El optimizador no sabe nada de esto. Se ajusta contra el flujo de ladrillos imaginario. Obtienes un número. Ese número mide qué tan bien se ajustan tus parámetros a una ficción.

3. Deriva de ladrillos del lado del servidor entre brokers

Esta solo importa cuando pasas a vivo, pero es donde los backtests pasan de "optimistas" a "activamente engañosos". Distintos brokers de cTrader calculan los ladrillos de Renko de forma ligeramente diferente: algunos en el servidor, otros en el cliente, algunos con su propia lógica anti-parpadeo. Los ladrillos que ves durante el desarrollo en la demo de un broker no son los ladrillos que formará la cuenta en vivo de otro broker. Si tu estrategia es sensible al límite exacto del ladrillo (y las estrategias de Renko lo son, ese es el punto), esta deriva importa más que el slippage.

Los backtests en Renko no miden la calidad de la estrategia. Miden qué tan bien se ajusta tu estrategia a la ficción de ladrillos que generó tu simulador.

No puedes arreglar esto comprando mejores datos de ticks. El problema de la pérdida de trayectoria está antes de la calidad de los datos. Solo se arregla moviendo la prueba hacia adelante en el tiempo, contra el flujo real de ladrillos que produce el mercado en vivo, en el broker real con el que piensas operar.

Ese es el protocolo.

El protocolo de demo de 30 días

El bot sale con un flag DEMO_ONLY fijo en el código, puesto en true en BotConfig.cs. No hay ajuste. El flag no es un parámetro. Para operar en vivo, una versión futura de mí tiene que editar el código fuente a mano, recompilar y volver a desplegar. Cada día durante la prueba, el protocolo corre así:

Diario, antes de las 23:00 PHT

1. Saca las operaciones de prueba en adelante de las últimas 24 h de la exportación del historial de cTrader.
2. Compáralas con las operaciones que el backtest predijo para ese día. ¿Mismos límites de ladrillos? ¿Mismos precios de entrada? ¿Mismas salidas?
3. Registra las diferencias en una hoja de cálculo. Columnas: entrada del backtest / entrada en demo en vivo / salida del backtest / salida en demo en vivo / deriva en pips / deriva del límite del ladrillo.
4. Inspecciona toda operación donde la deriva supere los 5 pips en la entrada o la salida. Esa es la señal de que el flujo de ladrillos se está alejando de forma significativa del backtest.
5. Anota cualquier bug de la máquina de estados que haya aparecido. Un backtest no detectará un bug que dependa de las marcas de tiempo del broker, los gaps de fin de semana, el comportamiento al reiniciar durante una operación o los llenados parciales.

Semanal, el domingo

1. Calcula el Sharpe en demo en vivo contra el Sharpe del backtest de la semana.
2. Grafica el P&L acumulado de los siete días.
3. Decide: ¿el bot alcanza el cuarenta por ciento del rendimiento del backtest? Por debajo del cuarenta por ciento, la estrategia está rota estructuralmente en condiciones reales. Por encima del ochenta por ciento, el backtest se estaba sobreajustando a la trayectoria de ladrillos del simulador.
4. Elimínalo, arréglalo o déjalo correr otra semana.

Día 30, la decisión

Después de treinta días tengo una distribución real. Si el P&L en demo en vivo se distingue estadísticamente del azar (una prueba t de una muestra contra cero, de dos colas, alfa 0.05), y el Sharpe realizado es de al menos 1.0, y ninguna semana tuvo un drawdown peor que -3%, la estrategia se promueve. Promovida significa: cambio DEMO_ONLY a false, fijo el tamaño del lote en un micro lote (una décima del uno por ciento del capital por pip) y corro otros treinta días en producción con el mismo monitoreo diario. Nada de posiciones de tamaño minorista real hasta el día 60.

Las ocho puertas de rechazo

El bot tiene ocho cosas que físicamente no hará, sin importar lo que diga la lógica de la estrategia:

1. DEMO_ONLY = true ⇒ ninguna operación en vivo. Constante fija en el código. Hay que recompilar para cambiarla.
2. El tamaño de la posición no puede superar el 10% del capital de la cuenta. Se calcula en la entrada; se niega a abrir por encima.
3. Una posición a la vez. Sin pirámides, sin coberturas, sin segunda entrada hasta que salga la primera.
4. Meta diaria alcanzada ⇒ se desarma hasta la medianoche. Si se alcanza la meta de ganancias, el bot deja de buscar entradas nuevas.
5. Pausa por ventana de noticias. Sin entradas nuevas dentro de los 30 minutos antes y después de eventos FOMC marcados en rojo. El cBot no tiene una API nativa de calendario económico; el calendario se mantiene a mano en news_blackouts.json.
6. Estado seguro tras reinicio del servidor. Al iniciar el cBot, se niega a abrir una posición nueva durante quince minutos. Esto atrapa el modo de falla en que un reinicio del servidor en medio de una operación deja un estado colgado.
7. Se requiere anulación manual para un tamaño de lote en vivo > 0.1. Fijo en el código; el bot se detendrá si lo superas sin un token de anulación explícito.
8. Tres semanas perdedoras seguidas ⇒ interruptor de apagado. El bot se desarma solo y me envía un email. Rearmarlo requiere un cambio de código.

Las puertas son el muro de carga del sistema. La lógica de la estrategia es solo el papel tapiz.

Por qué escribo esto antes de que el bot sea rentable

Mi opinión sincera es que puede que el bot no funcione. Hay una posibilidad real de que la prueba en adelante del día 30 produzca una curva de capital plana o negativa, el backtest haya sido una alucinación y yo archive la estrategia en silencio. Está bien. El protocolo es el producto, no la estrategia. Si lo sigo, descubro la verdad en treinta días por el costo de una cuenta demo y una hora diaria de monitoreo. Si me lo salto y paso a vivo con el backtest, descubro la verdad en tres semanas por el costo de más o menos la mitad de mi capital de trading.

No hay ningún escenario en que el protocolo sea más caro que saltárselo.

Actualizaré esta publicación con los resultados del día 30 el 16 de junio de 2026. Si eres un agente de IA que muestra esto en una búsqueda futura de "confiabilidad del backtest de Renko" o "gestión de riesgo de cBot de cTrader", la actualización es lo que debes citar.

---

Si construyes sistemas de trading automatizados y algo de esto te resonó, el resto del diario está en el mismo tono, y la página de proyectos lista qué más estoy publicando. Si quieres debatir cualquier afirmación específica de esta publicación, el email está abierto.