Build / QuantBot / Cripto
Cómo construí mi bot de trading cripto: de idea a ejecución real sin vender humo
Respuesta rápida
QuantBot no nació para prometer rentabilidad mágica, sino para operar con disciplina: escaneo periódico de mercado, datos OHLCV, sentimiento histórico, predicción por símbolo, filtros de riesgo y ejecución auditable. La diferencia entre un juguete y un sistema serio aparece en la observabilidad, la resiliencia y la capacidad de decir HOLD cuando no toca entrar.
Última actualización: abril 2026
Este artículo no es una invitación a fantasear con dinero fácil. Es una explicación técnica y honesta de cómo pasé de una idea de trading algorítmico a un sistema modular que escanea mercado cada 13 minutos, enriquece contexto con sentimiento histórico, decide con umbrales estrictos y registra cada intento con trazabilidad real. El repositorio abierto está en QuantBot en GitHub.
QuantBotTradingRiesgoArquitectura
¿Cuál era el objetivo real del proyecto y por qué no quise venderlo como un bot que “gana siempre”?
El objetivo real de QuantBot era construir un sistema serio, no una promesa vacía. Desde el principio la idea fue diseñar una arquitectura que analizara mercado, leyera noticias, tomara decisiones con reglas claras y pudiera operar con seguridad suficiente para no romperse en cuanto aparecieran condiciones reales de exchange, latencia o datos sucios.
Eso cambia mucho la forma de construir. Cuando alguien empieza pensando en “ganar siempre”, suele obsesionarse con el indicador milagroso o con un backtest bonito. Cuando empiezas pensando en producción, la conversación se mueve a módulos, observabilidad, auditoría, control de riesgo y mantenimiento continuo. Ahí deja de importar tanto la fantasía del acierto permanente y empieza a importar la supervivencia del sistema.
Ese enfoque encaja bastante con Archon. Aunque QuantBot no sea el servicio principal de la web, sí demuestra la misma filosofía de construcción: separar responsabilidades, registrar cada decisión y asumir que un sistema serio también debe saber cuándo no actuar. En trading eso protege capital. En empresa, protege margen y estabilidad operativa.
¿Qué arquitectura modular sí funciona cuando quieres iterar rápido sin romperlo todo?
La arquitectura que mejor me funcionó fue una arquitectura modular con límites muy claros: ingesta de datos de mercado, pipeline de noticias y sentimiento, generación de features, predicción por símbolo y ejecución con control de riesgo. Separar estas piezas fue clave para poder tocar una parte sin contaminar inmediatamente el resto.
El bot recorre su universo de símbolos cada 13 minutos. En cada ciclo descarga OHLCV, normaliza datos, enriquece con indicadores como RSI y ATR, agrega sentimiento y noticias recientes y lanza una predicción de tipo BUY, SELL u HOLD junto a un score de confianza. Después de eso no ejecuta automáticamente por fe ciega: primero pasa por filtros de spread, exposición, mínimos del exchange, slippage y sizing por riesgo.
La lección más útil aquí es que el modelo no es el centro absoluto del sistema. Lo que da estabilidad es el pipeline completo. Si una parte falla, necesitas saber exactamente qué módulo falló, qué dato faltó y qué camino tomó la decisión. Sin ese mapa, el bot se convierte en una caja negra y deja de ser mantenible en cuanto el entorno se complica.
Frecuencia
13 min
El bot vuelve a escanear mercado y universo de símbolos en ciclos periódicos para no quedarse ciego ante cambios recientes.
Ventana histórica
96 h
El pipeline de noticias y sentimiento toma contexto reciente de hasta 96 horas en vez de reaccionar a un único titular.
Umbral
0.88
Solo se plantea operar cuando la confianza supera un nivel alto, lo que reduce entradas impulsivas y deja muchos ciclos en HOLD.
¿Por qué mezclar mercado, indicadores y noticias da señales menos ciegas que trabajar solo con precio?
Una de las mejoras más importantes del proyecto fue dejar de depender de un único sentimiento instantáneo y construir una pipeline histórica de noticias. El bot no mira solo la foto de un minuto, sino una ventana de contexto reciente para entender si el ruido actual confirma o contradice lo que viene ocurriendo alrededor del símbolo y del mercado general.
A nivel técnico, la mezcla es bastante concreta: datos de precio y volumen, señales técnicas como RSI y ATR, derivados simples que ayudan a medir tensión del movimiento y una capa de sentimiento que intenta capturar contexto narrativo. No hace que el sistema sea infalible, pero sí reduce decisiones ciegas tomadas desde precio puro, que suele ser una lectura demasiado pobre para mercado cripto en alta volatilidad.
También aprendí algo importante: más datos no siempre significan mejor señal. Lo que ayuda es que los datos estén bien delimitados y que cada familia de features tenga una función clara. Si apilas inputs sin criterio, el modelo parece más sofisticado, pero en realidad se vuelve más difícil de explicar, auditar y mejorar.
¿Cómo se traduce una predicción a una orden sin convertir el sistema en una demo frágil?
El modelo devuelve una clase y un nivel de confianza, pero la decisión real no ocurre ahí. Después viene una regla simple y estricta: si no hay suficiente confianza, no se opera. Si la hay, todavía falta pasar por una capa de filtros que preguntan si el spread es aceptable, si el tamaño cumple mínimos de exchange, si el riesgo por símbolo está dentro de límite y si la cartera total no se está sobreexponiendo.
Ese paso parece obvio, pero separa un sistema de producción de una demo que “lanza señales”. Muchísimos proyectos funcionan hasta el momento en que tienen que tocar exchange real. Ahí aparecen mínimos de notional, estados parciales de orden, límites de rate, latencias variables, timeouts, fills parciales y errores de sincronización. El bot serio no es el que mejor predice en abstracto. Es el que sobrevive a esa fricción sin comportarse como un caos.
Por eso la ejecución de QuantBot registra tanto órdenes como rechazos. Cada decisión tiene motivo, identificador auditable y contexto suficiente para revisar después qué ocurrió. Incluso decir “no” a una operación deja huella. Y eso importa mucho porque sin historial de rechazos, muchos errores de diseño se vuelven invisibles.
Ledger
Toda orden, fill o rechazo se registra para reconciliación interna y revisión posterior.
Backoff
Los reintentos inteligentes con jitter ayudan a sobrevivir a rate limits y fallos de red sin romper el flujo.
ClientOrderId
Cada intento deja un identificador rastreable para auditar decisiones, fallos parciales y estados ambiguos.
¿Dónde se gana o se pierde de verdad: en el modelo o en la ejecución?
Si tuviera que quedarme con una sola lección, diría que la ejecución pesa más que el modelo en muchísimos momentos reales. Un modelo correcto con una ejecución floja pierde valor enseguida. Un modelo imperfecto con buen control operativo y disciplina de riesgo puede sobrevivir bastante mejor de lo que muchos esperan.
En QuantBot la capa de ejecución incluye validación previa de amount y notional, control de comisiones, métricas de latencia, observación de slippage y lógica de reintento. Eso no hace el sistema glamuroso, pero sí operable. Es la parte que evita que una buena idea se rompa por detalles aparentemente pequeños. Y esos detalles son justo los que en producción hacen más daño.
También incorporé una decisión que me parecía importante: el bot no vende balances antiguos que no haya abierto él mismo a menos que se configure explícitamente para gestionar toda la cartera desde el arranque. Ese detalle evita liquidaciones sorpresa y deja claro qué capital está realmente bajo la responsabilidad del sistema y cuál no.
¿Cómo diseñé la capa de riesgo para priorizar supervivencia antes que actividad?
La capa de riesgo se diseñó con una idea sencilla: evitar drawdowns estúpidos vale más que forzar operaciones. Por eso cada trade pasa por checks de exposición total, límites por símbolo, guardrails de spread y slippage, sizing por riesgo y restricciones de drawdown máximo. Si algo no encaja, el bot no discute: registra el motivo y se queda quieto.
Ese comportamiento tiene una lectura muy importante para cualquier sistema algorítmico: no operar también es una decisión válida. De hecho, con un umbral alto como 0.88, muchos ciclos acaban en HOLD. Y eso está bien. Un bot serio no existe para entretener con actividad constante, sino para protegerse de malas entradas y reservar capital para escenarios donde la combinación de contexto, señal y riesgo ofrece una ventaja más clara.
En trading live esto se nota mucho. El error típico del bot inmaduro es sentir que debe hacer algo en cada ciclo para justificar su existencia. QuantBot intenta lo contrario: justificar primero que merece actuar. Ese pequeño cambio de filosofía protege más capital del que parece y además simplifica mucho la lectura posterior del rendimiento.
¿Qué aprendí operándolo en background y por qué el mantenimiento también forma parte del sistema?
Para dejarlo estable en el día a día, lo opero en background con logs persistentes y comandos de control simples. Eso parece poco heroico, pero es exactamente lo que convierte un proyecto en algo usable. No basta con que el script funcione cuando lo ejecutas delante. Tiene que poder arrancar, parar, registrar, alertar y dejar un rastro legible cuando algo se tuerce a las tres de la mañana.
Ahí aparecieron dos lecciones operativas muy útiles. La primera: un warning no siempre es un fallo crítico. Algunos avisos de SSL o de entorno local parecen dramáticos y no afectan a la lógica central. La segunda: si el capital inicial con el que calculas PnL no coincide con el capital real que vive el bot, las métricas pueden volverse engañosas. Ese tipo de detalles no son glamourosos, pero separan un dashboard bonito de una lectura operativa fiable.
También comprobé que la robustez no se diseña solo en una pizarra. Se gana enfrentando fallos reales. Durante pruebas live aparecieron errores intermitentes de sincronización con Binance y cambios en endpoints legacy de user stream. En vez de verlo como un desastre, lo usé para reforzar resiliencia: mejor fallback, menos dependencia de un único canal y reintentos más inteligentes.
Operación continua
Logs persistentes, control simple y lectura clara del estado permiten mantener el sistema vivo sin improvisación.
Warnings
No todo aviso es un fallo crítico; aprender a clasificar ruido operativo evita perder tiempo en fantasmas.
PNL real
Si el capital base no coincide con el capital real, la interpretación de rendimiento se vuelve engañosa.
¿Qué errores reales aparecieron y por qué fueron más útiles que dañinos?
Los fallos más útiles fueron precisamente los que obligaron a reforzar la arquitectura. Problemas de sincronización con Binance, cambios en endpoints legacy del user stream y estados intermedios de orden sirvieron para detectar dependencias demasiado optimistas y endurecer la capa de ejecución. Cada incidente reveló una asunción falsa o demasiado frágil.
Eso me confirmó algo que también vale para automatización empresarial: la robustez no se presume, se demuestra reaccionando bien cuando el mundo real contradice el diseño ideal. Un sistema maduro no es el que no falla nunca. Es el que falla de forma legible, contenida y corregible. Si el error deja rastro claro, puedes mejorar. Si no lo deja, solo puedes repetirlo con más confianza.
Por eso la trazabilidad fue tan importante. Sin logs, sin clientOrderId, sin ledger de órdenes y sin motivos de rechazo, el proyecto habría sido mucho más bonito en superficie y mucho peor para aprender de verdad. La mejora continua no sale de intuición heroica, sino de revisar con calma qué ocurrió y por qué.
¿Qué aprendí construyéndolo y por qué estas lecciones sirven también fuera del trading?
La mayor lección no fue qué indicador usar. Fue esta: la arquitectura importa más que una táctica puntual, la ejecución y el riesgo pesan más que el backtest bonito, la trazabilidad es obligatoria si quieres mejorar y un sistema serio debe saber cuándo no operar. Esa idea vale en cripto, en ecommerce y en cualquier stack donde una automatización toque dinero, clientes o decisiones sensibles.
Si tuviera que resumir QuantBot en una línea, diría que pasé de un script que lanza señales a un sistema que puede operar con disciplina. Y eso, al final, es lo que más me interesa construir también en Archon: sistemas que no parezcan listos solo en la demo, sino que resistan el contacto con la realidad.
Quien quiera revisar el proyecto puede entrar directamente al repositorio abierto en GitHub: palcocerhurtado-tech/quantbot. Ahí está la prueba más útil de todo esto: no una promesa, sino un build real con módulos, scripts y decisiones visibles.
Arquitectura
Separar responsabilidades permitió iterar más rápido y corregir sin romper el pipeline completo.
Disciplina
HOLD no es ausencia de decisión; muchas veces es la decisión que más capital protege.
Trazabilidad
Sin rastro auditable no hay mejora continua, ni en trading, ni en empresa, ni en agentes de IA.