POLY-BIAS-TWEET

elon-tweet-fade DRY RUN
Server: --/--/-- --:--:--
Cargando…
 
Loading...

Ciclos recientes

Cargando…

DINERO Ganancia realizada por ventana

P&L cerrado (liquidaciones) de la estrategia elon-tweet-fade. 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

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 conteo de tweets de Elon 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

Edge Canary (banda 15-30c)

Loading...
to
Loading...

By Yes Price Bucket

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

By Days to Resolution

days from entry to market close
Loading...

By Volume Bracket

market volume at time of entry
Loading...

By Edge Bracket

estimated edge at entry (yes_price - true_yes)
Loading...

By Order Book Depth

ask-side depth at time of entry
Loading...

By Spread

bid-ask spread at time of entry
Loading...
Loading...
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.

What this bot does

POLY-BIAS-TWEET is a single-strategy Polymarket bot. It bets NO on Elon Musk weekly tweet-count brackets - markets that ask "Will @elonmusk post X-Y tweets this week?" - when the YES side is priced between 15% and 30%.

The edge: in those brackets, the market historically overprices YES by ~5-10 percentage points. A market saying 25% YES actually resolves YES closer to ~14%. Betting NO at the implied 75¢-85¢ captures that gap.

Why only Elon, only width-19 brackets, only $25k+ volume?

Those are the filter combinations where the edge has been empirically validated. Other people, other widths, and lower volume have either no edge or worse calibration. Live mode runs only on the validated band; exploration happens on a separate dry-run bot.

The modal-exclusion filter (a.k.a. the "danger zone")

The strategy loses when a bracket happens to sit right on top of Elon's recent average tweet count. The bot now tracks the actual count from each resolved week (the midpoint of the winning bracket) and computes a rolling 2-week mean μ.

Any candidate bracket overlapping [μ − 20, μ + 20] is skipped. The Overview tab shows the current μ, the danger zone, and the most recent resolved weeks. The bot ships with 15 manually-verified weeks (April 7 – June 5, 2026) so the filter is live from the first cycle, and it refreshes from Polymarket automatically as new weeks resolve.

Early exit by edge erosion (optional)

By default the bot holds every position to resolution - that's how the edge was validated (it's a statistical edge over many bets, not per-bet timing). But you can enable an early exit via the edge_exit_threshold setting (Settings → Riesgo y límites).

Crucially, erosion is judged against an independent estimate of the true probability - not the price. A price move alone doesn't mean the edge eroded: the true odds can move with it. So each cycle the bot reads Elon's live tweet count for the window from Polymarket's own tweetCount (the exact number that resolves the market), projects his remaining posts as a Poisson process at his observed pace, and computes the current probability the bracket actually hits:

edge_now = (1 − P(bracket hits)) − current NO price
erosion = 1 − edge_now ÷ entry edge

  • 0 - disabled. Hold to resolution (default, validated).
  • 0.5 - exit once half the edge is gone.
  • 1.0 - exit once the edge is fully gone (the model now prices the NO fairly).
  • 1.5 - exit once the model actively favors the bracket hitting (edge gone negative).

This way the bot holds when the price wobbles but Elon's pace is still safely below the bracket, and exits only when his actual pace threatens it. Lower numbers cut losses sooner; higher numbers ride further. When it triggers, the bot sells into the current bid (Fill-And-Kill); no bid to sell into → it holds and logs a warning. Realized P&L from an early exit feeds the same daily/weekly limits and kill switch as a settlement. The analysis is logged every cycle even when disabled, so you can watch it before turning it on.

Stop-loss por precio (EN SOMBRA desde el 29-08)

Vende una posición cuando el bid del NO cae price_stop_drop (0.15) por debajo de la entrada y faltan price_stop_days_left_max días o menos (2.0). Hoy está APAGADO (price_stop_enabled=false): registra en sombra cada disparo que habría hecho (would_fire en edge_observations) sin vender.

Por qué en sombra y no armado: el backtest sobre 52 posiciones reales (16 eventos, 10 pérdidas, datos anteriores al 25-08) dice que corta 9 de 10 pérdidas pero vende 9 ganadores, y la ventaja neta sobre holdear es +0.035 por evento con error estándar 0.042: t = 0.82, NO distinguible de cero (intervalo -0.05 a +0.12; ayudó en 8 eventos, empató en 5, perjudicó en 3). Es robusta en dirección (las 16 combinaciones de parámetros le ganan a holdear, y el jackknife nunca la hace desaparecer) pero chica en magnitud. Ojo con una lección de método: el primer análisis reportó +1.76/share porque contaba cada bracket como una apuesta independiente; agrupando por evento (los brackets de una semana son UNA apuesta) el efecto cae ~50 veces. Apostar dinero real a 0.8 sigma no se justifica, y desarmarlo no cuesta evidencia: como el mercado resuelve igual, el contrafactual se calcula igual.

Lo que YA SABEMOS que no funciona

Resultados negativos, documentados para que nadie los vuelva a proponer sin datos nuevos:

  • Salida por erosión de modelo (edge_exit_threshold): rindió −1.04/share peor que holdear. Vende ganadores en ráfagas de posteo que después revierten. Queda en observación permanente, no se arma.
  • Salida por modelo diario (mediana diaria + factores por día de semana): mejor que la erosión pero igual por debajo de holdear.
  • Filtro modal con medias diarias (ventanas de 14, 7 y 4 días): PEOR que el semanal actual. Cuanto mejor centra la media, más bloquea de la banda tradeable. En el período jun-jul, no filtrar le ganó a todas las variantes.
  • Adaptarse durante un cambio de régimen (fadear solo el lado lejos de la proyección diaria): −0.510 /share. La proyección se equivoca justo durante las transiciones: dos brackets marcados "seguros" a 2.8 y 5.5 anchos de distancia terminaron pegando. Además la brújula no existe cuando entramos: solo el 31% de las entradas tienen proyección disponible.
  • Aprovechar el régimen (comprar YES al bracket destino): perdió las 2 veces que se pudo evaluar.

Lo que SÍ tiene respaldo

  • Frenar durante alertas de régimen: la evidencia que se citaba acá (+0.112 en calma vs −0.021 en alerta) quedó RETIRADA el 02-09: la alerta estaba calibrada en la mediana de la variación normal de Elon (encendida el 63% de los días), así que esa partición era casi azarosa. Umbrales recalibrados al p90 (ritmo 45%, gap 50: activa ~3% de los días). El freno 0.2 queda para esos casos excepcionales, sin respaldo estadístico aún.
  • Entrar temprano en la ventana (min_days_to_resolution subido de 3 a 5 el 24-08): nuestros 56 trades reales muestran el gradiente (>5.5 días restantes −0.004/share, 4-5.5 días −0.023, 3-4 días −0.076) y POLY-SCOUT lo confirma con datos independientes: el sobrepago es máximo al listar y muere cerca de la resolución.
  • Escanear por serie (series_slug), nunca por tags amplios.

La lección más cara: armado no es funcionando

El stop estuvo armado dos semanas y nunca logró vender: disparó 21 veces sobre la misma posición (16-18 ago, bid de 0.61 bajando a 0.26) y ninguna orden se ejecutó. Esas observaciones no guardaron el motivo del rechazo (ese campo se agregó el 29-08), y de ahí salieron dos diagnósticos equivocados, uno tras otro.

Primer diagnóstico (29-08), falso: la orden salía exactamente al bid leído y un movimiento de un centavo la dejaba sin cruzar. Se agregó un colchón (sell_slippage, 2 centavos). Inofensivo, pero no era la causa. Segundo diagnóstico (02-09), también falso: "el wallet nunca dio permiso a los exchanges para mover sus tokens". La consulta on-chain miró los contratos viejos de Polymarket (CTF Exchange y NegRisk CTF Exchange v1). Este wallet es de la generación pUSD y el cliente firma contra los exchanges v2 (0xE111… y 0xe222…), que están aprobados desde siempre. Lo demostró el owner el 09-09 vendiendo desde la web: la venta pasó por el exchange v2 y no generó ninguna aprobación nueva en la cadena.

Causa real (09-09): el bot redondeaba la cantidad de shares "al más cercano" (12.1951 en el wallet se convertía en 12.20 en la orden) y Polymarket rechaza cualquier orden por encima del saldo. Arreglado: la cantidad se trunca hacia abajo y se limita al saldo que reporta el propio CLOB antes de mandar la orden; si el saldo no se puede leer, la venta aborta con el motivo. Probado con dinero real el 09-09 a las 22:51 UTC: 24.69 shares vendidas a 0.80 desde el bot por el nuevo endpoint de venta manual (POST /api/trades/sell), orden llenada al instante. La ruta de salida existe. El stop de precio sigue en sombra a propósito: su ventaja medida (+0.035 por evento, t=0.82) no distingue de cero, y eso se revisa en la evaluación de septiembre. Lección doble: probar la ruta de ejecución con dinero antes de confiar en una protección, y guardar SIEMPRE el motivo de cada fallo (sin él, dos agentes distintos "confirmaron" causas que no eran).

Tamaño de las apuestas: Kelly con la ventaja medida (desde el 15-09)

Cuánto se apuesta lo decide la fórmula de Kelly, que necesita un dato: con qué probabilidad gana esta apuesta. Hasta el 15-09 ese dato venía de la tabla de calibración, que afirma que un YES de 15-20c pega solo el 5% de las veces. El canario del edge, que mide TODOS los brackets de la banda que el bot escanea, dice ~16%; y los trades reales del bot anteriores al corte del holdout, 20%. Con el dato de la tabla, Kelly pedía 3 o 4 veces más dinero del que corresponde: por eso salían apuestas de $28-30 donde el cálculo honesto da ~$16.

Ahora la probabilidad es una medición y no una creencia: precio del NO + ventaja medida, tomando la ventana más conservadora del canario entre 8 y 16 semanas (así, si la ventaja se está cayendo, las apuestas se achican en el acto y una racha corta de suerte no las infla). La tabla sigue decidiendo qué trades pasan los filtros; ya no decide cuánta plata va en cada uno, así que la selección de trades y la colecta de datos no cambian.

  • Fracción de Kelly: con la probabilidad real corresponde ~0.25, no 0.1. El 0.1 viejo compensaba a mano la tabla inflada. Con ventaja medida de 3 puntos, un NO a 0.81 y equity de $406, Kelly da ~$16.
  • Freno automático: si la ventaja medida llega a cero o se da vuelta, Kelly da cero y el bot deja de apostar solo. No es una falla: es exactamente para lo que existe el canario.
  • Sin dato no se apuesta: si el reporte del canario falta o tiene más de 6 horas, el ciclo no apuesta y deja un ERROR en el Registro. Nunca vuelve a la tabla en silencio.
  • Auditable: cada entrada guarda la ventaja y la probabilidad que usó Kelly, y el tamaño apostado (kelly_edge_used, kelly_p_used, bet_size_usd).
  • Los topes siguen: la apuesta máxima es la pérdida máxima de una semana mala, porque en un evento, como mucho, uno de los brackets hermanos pierde.

Detector de cambio de régimen

La estrategia pierde cuando el conteo aterriza en un bracket que parecía improbable. Este detector intentaba anticiparlo midiendo cambios de ritmo: el gap entre la media semanal (lenta) y la proyección diaria de 14 días, y la pendiente del ritmo (14 días vs los 14 anteriores). Lección del 02-09: con los umbrales originales (20% / 25) estaba encendido el 63% de los días, porque Elon oscila ±19% entre quincenas la mitad de su vida (su ritmo semanal de julio-agosto: 159, 211, 157, 269, 221, 187, 158, 310, 170). No hay "régimen viejo" y "nuevo": hay ruido constante, y el detector lo marcaba como alerta. Recalibrado a los umbrales del 10% más brusco de su historia (regime_alert_pace_change 0.45, regime_alert_gap 50), dispara ~3% de los días.

Cuando dispara: warning en el Registro, aviso por Telegram (si está configurado) y un banner rojo REGIME SHIFT en la pestaña Salud. Además existe un freno opcional: regime_caution_factor multiplica el tamaño de las bets nuevas mientras la alerta esté activa (1.0 = solo alerta, default; 0.5 = bets a la mitad; 0 = pausa entradas). El freno está sin armar hasta juntar evidencia de que paga.

Sistemas en sombra (colecta para la evaluación de septiembre)

Varias ideas corren en paralelo SIN afectar el trading, grabando lo que habrían hecho, para juzgarlas con datos en la evaluación de fines de septiembre 2026:

  • Erosión de edge - en observación desde julio (el backtest la refutó: vendía ganadores).
  • Modelo diario de salida - la erosión recalculada con la mediana diaria del archivo de posts (robusta a ráfagas) + factores por día de semana: campos *_daily en edge_observations.
  • Filtro modal diario - in_danger_zone_daily en los snapshots, junto al semanal, para comparar ambas versiones (y contra no filtrar: en jun-jul no filtrar fue lo mejor).
  • Price-stop en sombra - cuando está apagado, registra sus would_fire.

Wallet compartida entre bots

La wallet de Polymarket es compartida con otros bots (48ELON, BOX-MOVIES, etc.). Este bot solo contabiliza sus propios trades: una posición sin entry record propio se ignora en settlements, P&L, estadísticas y en el equity para Kelly. Si la wallet gana o pierde por otro bot, es responsabilidad del otro bot. La pestaña Operaciones muestra las posiciones reales de la cuenta (incluidas las ajenas); las métricas del bot, no.

Dry run vs live

The mode badge in the header shows DRY RUN or LIVE. In dry run, the bot evaluates every market and records hypothetical trades to the Trades tab - no real orders are placed and no real money moves. In live mode, NO orders are submitted to your wallet.

The default settings are a live profile for a $150 bankroll: bets between $5 (the Polymarket minimum that still allows exiting a position) and $20, sized by 1/5-Kelly on your total account value (free USDC + market value of open positions - so bets don't shrink asymptotically as cash gets locked into positions; each order is still capped by the free cash actually available). Three circuit breakers protect the capital: a $30 daily loss limit, a $60 weekly loss limit, and a kill switch that halts all trading at 15% cumulative drawdown (−$22.50). Because brackets in the same weekly event are mutually exclusive, at most one NO bet per event can lose.

Live mode needs POLYMARKET_PRIVATE_KEY and POLYMARKET_FUNDER_ADDRESS as env vars on the host, plus USDC on Polygon. If the wallet balance cannot be fetched, the cycle aborts with an error - the bot never sizes real bets from a fictional balance. Flip DRY_RUN via the Settings tab or as an env var.

The Auto-cycles toggle

The header has an Auto cycles checkbox and a Run Cycle Now button. By default the scheduler starts paused on every boot - nothing runs until you enable auto-cycles or trigger a cycle manually. A cycle takes a few minutes; the Trades and Performance tabs update as each one completes.

What each tab shows

  • Resumen - estado operativo: capital para sizing, posiciones abiertas, contadores de riesgo (kill switch), el filtro modal y los ciclos recientes. Sin cifras de P&L (eso vive en Resultados).
  • Resultados - la vista económica: ganancia realizada por ventana (24h / 7d / 30d / total), ROI compuesto diario/mensual/anualizado (asume reinversión), curva de capital, P&L por semana, estadísticas por operación (expectancy, drawdown, Sharpe) y los exports de datasets. El anualizado es una extrapolación indicativa con pocas semanas de historia.
  • Operaciones - el registro de señales generadas (siempre, en vivo y en papel), el historial de liquidaciones del bot, las posiciones reales de tu cuenta de Polymarket y el scanner de mercados que ve el bot.
  • Salud - el canario del edge: mide semana a semana el sesgo real de la banda 15-30c. Si la línea cae hacia 0, el negocio se está acabando y el bot avisa solo. Indispensable.
  • Calibración - ¿la estimación de edge del bot calza con la realidad? "Hit rate" es cuántas veces gana YES por bucket de precio. "Divergence" es observado menos esperado. Con 50+ operaciones resueltas es la vista principal de "¿el edge sigue siendo real?".
  • Registro - el log del bot en vivo. Filtrable por nivel.
  • Ajustes - cada perilla editable, agrupada en paneles. Un badge amarillo modificado ↺ marca cualquier valor distinto de su default. Los cambios guardados se registran solos en Notas.

Why a trade gets skipped

Each cycle the bot reports a one-line "Rejections" summary in the logs. The categories you'll see:

  • not_count_bracket - not a tweet/post count market.
  • not_elon - count market but not about Elon.
  • wrong_bracket_width - Elon market but the bracket is not width-19.
  • modal_exclusion - width-19 Elon bracket, but it sits in the danger zone.
  • filter_rejected - passed the type filters but failed volume / days / price / edge / spread.
  • low_liquidity - order book too thin.

Things to know about the dashboard data

  • Every API endpoint requires the BOT_API_KEY. The dashboard asks for it once and stores it in your browser (localStorage). You can also open the dashboard as /?api_key=YOUR_KEY - it saves the key and strips it from the URL.
  • The settings file is data/setting_overrides.json - values you change via the UI persist there across restarts.
  • Tweet-count history lives at data/tweet_count_history.json. The bot refreshes it from Polymarket at most once per 24h.
  • Settings showing the yellow modificado ↺ badge have a non-default override stored; env vars on the host also count as "default" when restoring.