POLY-BOX-MOVIES

box-office-openings DRY RUN
Server: --/--/-- --:--:--
Cargando…
 
Cargando…
 
Loading...

Ciclos recientes

Cargando…

DINERO Ganancia realizada por ventana

P&L cerrado (liquidaciones) de la estrategia box-office-openings. Las posiciones abiertas aportan P&L no realizado, que se muestra aparte. Cualquier liquidación ajena a la estrategia se reporta por separado y no contamina estas cifras.

Cargando…

ROI Retorno compuesto (asume reinversión)

El retorno total del período se convierte en tasa diaria y se extrapola a mensual y anual asumiendo reinversión. Con pocas semanas de historia el anualizado es una extrapolación indicativa, no una promesa.

Curva de capital

P&L realizado acumulado, una marca por liquidación.
Cargando…

P&L por semana

Suma de liquidaciones por semana ISO (lunes a domingo).
Cargando…

Estadísticas de la estrategia

Cargando…

DATOS Exportar datasets

Descargas crudas para análisis offline.

to

ÓRDENES REALES Intentos enviados a Polymarket

Cada orden que de verdad salió al mercado, con la respuesta cruda del exchange. Los intentos simulados (dry run, o una regla en paper) NO aparecen acá: no salieron, así que no dicen nada sobre si la ejecución funciona. Sin llenado no es un error: la orden llegó y no había liquidez a nuestro tope.

Cargando…

REGISTRO Señales generadas

Cada señal que la estrategia produjo — esto se registra siempre, en vivo y en papel. NO son apuestas dry-run. Las que de verdad se ejecutaron aparecen abajo en "Posiciones reales". Si una señal dice Skipped, el motivo explica por qué no se convirtió en orden real (ej. kill switch, spread, cap por evento).

Loading...

Settlement History (Bot)

Loading...

ACCOUNT Live Polymarket Positions

These are real positions from your Polymarket account, not managed by the bot.

Loading...

SCANNER Mercados que ve el bot

Los mercados de box office que el escáner encuentra ahora mismo, con su precio YES y volumen. No se cargan solos: tocá Actualizar.

Tocá Actualizar para cargar los mercados

Salud de las reglas ?

Implícito vs realizado por regla, clusterizado por evento. El true_yes declarado es una hipótesis; acá se la confronta con los datos. Promover a live es SIEMPRE decisión manual.

Cargando reglas...

Cross-filter: ganancia y ROI del fade simulado

Fade simulado — no son trades ejecutados. Esta grilla corre sobre el universo de snapshots observados (una fila por bracket por ciclo, haya apostado el bot o no) unido al bracket ganador de cada evento, y simula fadear el favorito en CADA bracket que matchea los filtros, al precio del snapshot, con stake fijo. El P&L de lo realmente operado vive en Resumen y Resultados; acá se responde "¿qué habría pasado si fadeaba todo lo que matchea estos filtros?".
hasta
×

Tildá los valores de cada eje para incluirlos; destildando todos en un eje se bloquea todo (grilla vacía). La grilla 2D combina los dos ejes elegidos arriba; las tablas de abajo son los marginales (cada eje por separado).

Cargando…

Grilla

Cargando…

Curva de calibración del mercado

Fiabilidad del mercado por decil de precio sobre TODOS los brackets de cada evento resuelto, no sólo los que matchean una regla. No prueba que una regla tenga edge: dice si el mercado está valuando distinto que antes. Unidad = un (evento, bracket), con el precio medio de sus snapshots dentro de la ventana de horas a resolución.

a
Cargando…

Calibración de trades ejecutados

Sobre los trades (hipotéticos en dry-run) que pasaron todos los filtros del bot, un conjunto angosto. El cross-filter de arriba usa el universo completo de snapshots.

to
Loading...

By Yes Price Bucket

Hit rate = observed P(Yes resolves). Divergence = actual - expected. Status = confidence in calibration table accuracy.
Loading...
Loading...

Patas del motor

Cada pata es una regla validada. Apagada deja de generar señales pero la sigue midiendo (la evidencia es sobre el mercado, apueste o no el bot). Papel simula sin gastar. En vivo gasta dinero real, y solo se habilita si el semáforo de Salud da READY.
Cargando…
Cargando…

Nueva nota

Bitácora libre del bot. La fecha se guarda sola. Los cambios que guardás en Ajustes se registran solos también. Tocá Editar en cualquier nota para ampliarla.

Qué hace este bot (en una frase)

Apuesta en los mercados de Polymarket sobre cuánto recauda una película en su fin de semana de estreno (serie box-office-openings), usando dos reglas que ya fueron validadas con datos históricos. Por ahora corre en DRY RUN: simula todo, no mueve plata real.

Cómo son estos mercados

Por cada película, Polymarket abre un "evento" con 5 o 6 opciones tipo escalera: "menos de $200M", "entre $200M y $220M", ... "más de $280M". Exactamente UNA gana (la que contiene la recaudación real). Por eso, si sumás los precios YES de todas las opciones, debería dar aproximadamente 1.00 (100%). El mercado resuelve con las cifras finales de The Numbers (the-numbers.com), fin de semana de 3 días. La serie también trae eventos de 2do/3er fin de semana; el bot los trata igual.

Las dos reglas de trading

Las dos vienen de POLY-SCOUT (mi proyecto que escanea el histórico de Polymarket buscando sesgos), medidas en el momento T-24h (entre 18 y 30 horas antes de que resuelva el mercado):

  • Regla NO (los "casi imposibles" están caros): los brackets que cotizan entre 5¢ y 15¢ a T-24h casi nunca terminan ganando. En 42 eventos históricos, ninguno ganó. Pero el mercado los cobra ~9¢ como si tuvieran 9% de chance. El bot compra NO: paga ~91¢ y cobra $1 casi siempre. Gana poquito por vez, muy seguido.
  • Regla YES (el favorito claro está barato): el bracket favorito que cotiza entre 85¢ y 99¢ a T-24h termina ganando prácticamente siempre (41 de 41 eventos históricos). El mercado lo cobra ~93¢ cuando "vale" más. El bot compra YES a ~93¢ y cobra $1. OJO con esta pata: es asimétrica — ganás ~7¢ o perdés ~93¢. Una buena racha no prueba nada; solo el conteo largo (40+ resoluciones) dice si funciona.

Importante: el bot NO asume que "0 de 42" significa probabilidad cero (sería arrogante con 42 casos y haría que Kelly aposte todo). Usa números "encogidos" hacia el medio: 3.5% para la pata NO y 96.5% para la YES. El edge que ves en pantalla ya está calculado con esos números conservadores.

Cómo se calcula el edge (con números)

Cada bracket tiene un precio de mercado del "Sí" (ej: 9¢ = el mercado le da 9% de chance). Cada regla trae su propia probabilidad estimada (true_yes: 3.5% para la NO, 96.5% para la YES). El edge es la diferencia, en la dirección que apuesta la regla:

  • Regla NO: edge = precio − true_yes. Bracket a 9¢ → 0.09 − 0.035 = +5.5 puntos. El mercado lo cobra 9% pero creemos 3.5%; apostar NO (a que NO gana) captura esa diferencia.
  • Regla YES: edge = true_yes − precio. Favorito a 93¢ → 0.965 − 0.93 = +3.5 puntos.

Solo dispara si el edge supera su umbral (2 puntos). Ese true_yes no está clavado: la pestaña Salud lo recalcula con los datos propios y sugiere uno actualizado (yo decido si lo adopto). Con el edge y la probabilidad de ganar, Kelly fraccional calcula el tamaño de la apuesta; cada regla puede además pedir su propio Kelly y su propio tope (así la pata YES asimétrica se dimensiona más chica que la NO).

Los filtros antes de apostar (los "gates")

Para que el bot entre a un mercado, TODO esto tiene que cumplirse:

  • Es de la familia: la pregunta es de "Weekend Box Office" y el bracket se pudo leer en dólares.
  • Libro sano: la suma S de los precios YES del evento está entre 0.85 y 1.50. Si S > 1.5 el libro está roto y no se toca NINGÚN bracket de ese evento.
  • Matchea una regla: precio en la banda de la regla, entre 18 y 30 horas de la resolución, y con edge suficiente tras usar el true_yes conservador.
  • Liquidez real: precios y profundidad salen del libro de órdenes real de Polymarket (lo que de verdad se puede comprar), nunca de un precio teórico.

Después Kelly fraccional decide el tamaño y los límites de riesgo (pérdida diaria/semanal, kill switch por drawdown) pueden frenar todo.

La pestaña Salud: el corazón del sistema

El problema de todo bot con "edge histórico" es que el edge se puede morir y seguís apostando igual. Salud existe para eso. Por cada regla muestra:

  • El semáforo: DATOS INSUFICIENTES (menos de 10 resoluciones, no se puede decir nada) → CALIBRANDO BIEN o DIVERGIENDO → LISTA PARA PROMOVER (40+ resoluciones y lo observado calza con lo declarado). Si dice DIVERGIENDO en rojo, la hipótesis de la regla NO está funcionando: frenar y revisar.
  • La celda observacional: el bot mira TODOS los brackets resueltos que cumplían las condiciones de la regla (haya apostado o no) y compara el precio que tenían contra cuántas veces ganaron de verdad. "Implícito 9%, realizado 3%" = el edge existe. Se cuenta UNA vez por bracket por evento para no inflar la muestra.
  • Paper: las apuestas simuladas que ESTA regla generó y su P&L.
  • El estimador evolutivo: mezcla la evidencia original de POLY-SCOUT con lo que el bot va viendo, y sugiere un true_yes actualizado (fórmula: (aciertos + 1.5) ÷ (n + 3)). Si el sugerido difiere del declarado, aparece el botón Adoptar sugerido. Nada se aplica solo: yo decido con un click, y queda anotado en la regla cuándo y de dónde salió.

El canario de tendencia: ¿el edge se está muriendo?

El semáforo de arriba responde "¿el edge existe?". Esta otra parte responde la pregunta que de verdad importa para seguir apostando: "¿se está achicando?". Un edge así se comprime cuando llegan jugadores profesionales, y el promedio de 9 meses puede verse lindo mientras los últimos 2 meses ya no tienen nada.

El truco está en partir el edge en dos piezas, porque mueren de formas distintas:

  • La pieza del PRECIO (a cuánto cotiza el mercado la banda). Muere despacio, por compresión: si los longshots pasan a cotizar 6¢ en vez de 9¢, el edge se achica aunque nunca gane ninguno.
  • La pieza de la REALIZACIÓN (con qué frecuencia pasa lo que apostamos). Muere de golpe: si un longshot de 5-15¢ empieza a ganar, la hipótesis se cayó.

Y acá viene lo bueno: en esta familia la realización hoy es "siempre igual" (0 de 42 longshots ganaron; 41 de 41 favoritos ganaron). Cuando esa pieza no se mueve, todo el edge vive en el precio. Y el precio es un número continuo que se puede mirar sin esperar a que resuelva nada: ya está en cada snapshot. Por eso el canario tiene dos velocidades:

  • Rápida (aviso temprano): vigila los precios de la banda. Da señal en semanas, no meses.
  • Lenta (confirmación): vigila la tasa de aciertos a medida que resuelven eventos.

Estados: SIN EROSIÓN / VIGILAR (bajó pero puede ser ruido) / EROSIÓN DETECTADA (bajó y la estadística lo confirma) / AÚN SIN VEREDICTO. Dos cosas que hace bien y conviene entender:

  • Agrupa por evento: los brackets de una misma película no son independientes (gana uno solo), así que cada evento cuenta como una sola observación. Contar bracket por bracket inflaría la confianza.
  • Te dice qué NO puede ver (el "MDE"): con pocos datos avisa "solo detectaríamos caídas mayores a X pp", en vez de decir "todo bien" cuando en realidad no tiene con qué mirar.

Está enchufado a la seguridad: para promover una regla a real ahora hacen falta las dos cosas — nivel READY y tendencia sin erosión. Un edge con 40+ casos pero cayendo es una trampa: sería entrar justo cuando el negocio se termina. El canario solo puede bloquear, nunca habilitar.

Estado del histórico (medido, no supuesto): sobre los 9 meses de POLY-SCOUT, ninguna de las dos patas se erosiona. Pendiente de la NO: +0.26pp por trimestre; de la YES: +0.24pp. Los dos intervalos de confianza incluyen el cero ⇒ planas, sin deterioro.

Cómo cambio las reglas

Ajustes → Motor de reglas: las reglas son un JSON editable. Puedo cambiar bandas de precio, ventana horaria, umbral de edge, el Kelly o el tope por regla, apagar una (state: "off") o agregar una nueva descubierta en Calibración/Lab. Si guardo algo mal escrito, el backend lo rechaza entero y me muestra el motivo exacto — no puede quedar una regla rota a medias. El editor NO puede pasar una regla a live a mano (da error): pasar a real es solo con el botón Promover de la pestaña Salud, y solo si el semáforo está en READY.

Regla de graduación y la "doble llave"

Nunca se gradúa por racha de ganancias. Una regla se puede promover cuando su semáforo llega a LISTA PARA PROMOVER: (1) 40+ casos resueltos, y (2) la calibración calza (lo que el precio implicaba vs lo que realmente pasó, contado por evento). El P&L corto engaña, sobre todo en la pata YES asimétrica.

La plata real tiene dos llaves, y hacen falta las dos:

  • Llave 1 — la regla en live: la promuevo con el botón Promover (solo habilitado en READY). Puedo bajarla a paper cuando quiera con Degradar.
  • Llave 2 — DRY RUN apagado (Ajustes → Operación). Es el interruptor maestro.

Una regla en paper NUNCA gasta plata real, aunque apague DRY RUN. Y con DRY RUN encendido, ninguna regla gasta aunque esté en live. Recién opera en real una regla live con DRY RUN apagado.

¿Cuánto tarda en darme evidencia confiable?

Idea clave: acá "calibrado" y "saber si es rentable" son el mismo hito. No lo juzgo por la ganancia del dry-run (engaña); lo juzgo por la calibración clusterizada por evento. Cuando una regla llega a READY, esa ES la evidencia de que es rentable; si llega a DIVERGIENDO, es evidencia de que no.

El contador arranca de cero ahora: los eventos históricos que ya resolvieron no cuentan para el semáforo, porque el bot no tenía snapshots de cuando estaban vivos (necesita el precio en la ventana T-24h + el resultado). Cada estreno que pasa por su ventana suma casos:

  • Regla NO (5-15c): ~1-3 casos por evento (suele haber varios brackets baratos) → llega a 40 en aproximadamente 1-2 meses. Es la pata más robusta y la primera en dar evidencia.
  • Regla YES (85-99c): ~1 caso por evento, y solo si hay un favorito claro en esa banda → más lenta, aproximadamente 3-6 meses.

Son estimaciones gruesas (dependen de cuántas películas tengan brackets en cada banda). El estimador evolutivo, en cambio, ya arranca con la evidencia de POLY-SCOUT como base y se va ajustando desde el primer caso propio.

Importante — eso es el plazo para PROMOVER, no para enterarme de que algo va mal. El canario de tendencia (más abajo) vigila los precios de la banda sin esperar resoluciones, así que si el mercado empieza a comprimir el edge lo veo en semanas. Y el backtest histórico ya me dio la evidencia retrospectiva hoy. Lo que tarda meses es la certificación para arriesgar plata real, que es lento a propósito.

Qué mirar en cada pestaña

  • Resumen: ¿está vivo? ¿corren los ciclos? ¿capital y riesgo OK?
  • Resultados: la plata (simulada en dry run): P&L por ventana, ROI, curva de capital, exports CSV.
  • Operaciones: cada señal generada, liquidaciones, y el scanner (qué mercados ve el bot ahora mismo).
  • Salud: ¿las reglas siguen funcionando? (ver arriba). La pestaña más importante.
  • Calibración: el laboratorio. El cross-filter corta TODOS los snapshots observados por precio × horas × volumen × S × spread para buscar celdas con edge nuevas. Acá nacen las reglas futuras.
  • Registro: el log en vivo, filtrable.
  • Notas: bitácora; los cambios de ajustes se anotan solos.
  • Ajustes: todas las perillas + el editor de reglas. El badge amarillo modificado ↺ marca valores distintos del default.

Por qué se saltea un trade (el "Rejections" del log)

  • not_box_office_bracket: la pregunta no es un bracket de box office legible.
  • not_box_office: no es de la familia.
  • event_structure: la suma S del evento está fuera de [0.85, 1.50], o el evento llegó incompleto (menos de 5 brackets), o sin event id.
  • filter_rejected: pasó la identidad pero ninguna regla matcheó con edge suficiente (lo más común: el mercado no está en la ventana T-24h todavía).
  • low_liquidity: libro de órdenes demasiado flaco.

Datos y operación (para acordarme)

  • Todo el API pide la BOT_API_KEY. El dashboard la pide una vez y la guarda en el navegador. También sirve abrir /?api_key=LA_KEY.
  • El scheduler arranca pausado en cada reinicio: hay que prender "Auto cycles" en el header (o tocar "Run Cycle Now"). Escanea cada 1 hora.
  • Los datos viven en /data del contenedor (volumen persistente): market_snapshots.jsonl (todo lo observado, una fila por bracket por ciclo), winner_history.json (qué bracket ganó cada evento, se refresca solo 1 vez al día desde Polymarket), hypothetical_trades.json (las apuestas simuladas), entry_records.json, setting_overrides.json (lo que cambio desde la UI, sobrevive reinicios).
  • Deploy: Dokploy en el VPS, rama POLY-BOX-MOVIES del repo compota334/POLY-BIAS-BOT. Redeploy no borra /data.
  • Para pasar a LIVE algún día: env vars POLYMARKET_PRIVATE_KEY + POLYMARKET_FUNDER_ADDRESS, USDC en Polygon, DRY_RUN=false, y SOLO con el semáforo en verde.
  • Historia y decisiones técnicas: docs/box-office-openings-spec.md y los handoffs en docs/handoff/ del repo.