Tutorial de Bot de Polymarket · Capítulo 29 de 32
Construye un motor de paper trading para Polymarket antes de salir en vivo: simula órdenes contra precios reales, registra P&L, aplica la regla de 30 trades (>=55% de win rate, +PnL) antes de desplegar capital real, y el esqueleto de código.
Qué cubre este capítulo
El paper trading es el paso no negociable entre la idea de estrategia y el deployment en vivo. Este capítulo presenta el motor simple de paper que ha puesto el gate a todos los bots en vivo que hemos lanzado - menos de 200 líneas de Python, registra cada trade en un diario JSONL y aplica las mismas fees/slippage que la ruta en vivo.
- Por qué paper antes de live (siempre)
- La regla de 30 trades (WR verificado >=55% + PnL positivo)
- Cómo construir un motor simple de paper
- Cómo llevar el diario de paper junto con el diario live
- Cuándo paper diverge de live (y por qué)
- Pasar a live: primer depósito pequeño
- Código: motor mínimo de paper
Por qué paper antes de live (siempre)
La regla de 30 trades en paper es la única disciplina que separa al 7.6% de traders rentables de Polymarket del 84.1% que pierde. La mayoría de los builders la omite y paga la matrícula. La razón honesta por la que funciona: el paper trading revela el win rate real de una estrategia con suficientes muestras para distinguir señal de suerte.
Omitir paper cuesta más de lo que ahorra. Una estrategia que parece rentable en backtest, pero que en realidad es un volado, quemará entre $200 y $500 de capital en vivo antes de producir un tamaño de muestra de 30 trades de datos reales. Hacer paper de esos mismos 30 trades cuesta $0.
El motor de paper no necesita ser sofisticado. Necesita ser honesto - mismas fees, mismo slippage, misma latencia de ejecución que la ruta live. Mientras más simple, mejor, porque todo lo opcional se termina recortando y el bot sale a producción antes de tiempo.
La regla de 30 trades (WR verificado +55% + PnL positivo)
La regla es binaria: 30 trades cerrados en paper, criterios de éxito definidos de antemano (normalmente WR ≥ 55% en una estrategia con EV positivo), o no hay deployment en vivo.
30 es el tamaño mínimo de muestra donde el intervalo de confianza del 95% sobre el win rate real es lo suficientemente estrecho como para distinguir señal de ruido. Por debajo de 30, una tasa observada de 60% podría corresponder a una tasa real de 45-75%. Con 30 o más, el intervalo se reduce a ~50-70% - todavía amplio, pero suficiente para descartar que "la estrategia es un volado".
Los criterios de éxito deben definirse ANTES de que empiece la corrida en paper. Definirlos después produce racionalización post hoc (vas a encontrar la forma de interpretar cualquier conjunto de 30 trades como "suficientemente bueno").
Cómo construir un motor simple de paper
El motor de paper es, esencialmente, el código de trading en vivo con la función de colocación de órdenes reemplazada por una ejecución simulada. La simulación:
- Lee el order book en vivo: la misma llamada que haría el bot live.
- Simula la ejecución: si compras con FOK y el precio es ≥ best ask, ejecuta la orden al promedio ponderado por volumen de los asks consumidos; registra la ejecución en el diario de paper.
- Aplica fees: descuenta las mismas fees que pagaría la ruta live.
- Rastrea inventario: mantiene un paper-balance paralelo y un diccionario de paper-positions.
Todo el motor cabe en 100-200 líneas de Python. La disciplina clave: cada supuesto que hace la ruta live (tasa de ejecución, latencia, fee) debe reproducirse en paper, incluso si es ligeramente peor que la realidad - paper debe ser el piso, no el techo.
Cómo llevar el diario de paper junto con el diario live
La corrida de paper trading produce un diario JSONL indistinguible en estructura del diario live que el bot escribirá más adelante. Los mismos campos: timestamp, action, market_slug, side, size, price, expected_fill_price, simulated_pnl_at_exit.
Dos razones para usar el mismo formato. Primero, las herramientas de análisis que leen trades live (reportes de PnL, calculadoras de win rate) funcionan sobre paper sin modificaciones. Segundo, comparar paper contra live después detecta divergencias que indican bugs.
Consejo de producción: haz que el motor de paper escriba en per_trade_paper.jsonl en el mismo directorio que el per_trade.jsonl live. Un solo comando compara ambos: diff -y <(jq -r .market_slug per_trade.jsonl) <(jq -r .market_slug per_trade_paper.jsonl).
Cuándo paper diverge de live (y por qué)
Las divergencias entre paper y live son inevitables. Tres comunes:
- Slippage: paper ejecuta al snapshot del ask; live recorre el book y puede ejecutar 1-2c peor en mercados ilíquidos. Solución: simula slippage en paper agregando una penalización por trade equivalente a la mitad del spread.
- Latencia de ejecución: paper ejecuta al instante; live tarda 200-500ms, durante los cuales el precio puede moverse. Solución: simular esperando y volviendo a leer el book antes de "ejecutar" en paper.
- Adverse selection: paper asume que obtienes el mejor ask; live compite con otros bots que quizá ya levantaron ese ask. Solución: más difícil de simular; sé honesto contigo mismo y acepta que paper sobreestima.
Cuando paper dice +5%/mes y live corre en -2%/mes, la diferencia suele ser una de estas. Audítalas una por una en vez de asumir que la estrategia en sí estaba mal.
Pasar a live: primer depósito pequeño
Paper aprueba 30 trades. Plan de deployment en vivo:
- Deposita $25-50 como capital de smoke test. Trátalo como matrícula; si lo pierdes, la lección valió la pena.
- Ejecuta el bot en modo live durante 5-10 trades con posiciones al tamaño mínimo (5 shares).
- Verifica que cada ejecución coincida con las expectativas de paper dentro de 2c. Investiga cualquier diferencia mayor antes de seguir.
- Si 5-10 trades live coinciden con paper, deposita $200-500 y opera posiciones de tamaño normal.
- Si no coinciden, detén, debugea, corrige y reinicia desde el paso 1.
La diferencia más común entre live y paper en el primer deployment es una fee faltante o una mala estimación de slippage. Corregir eso es sencillo; la disciplina está en detectar la diferencia antes de escalar capital.
Código: motor mínimo de paper
Referencia: motor simple de paper que lee el libro live + simula ejecución FOK.
import json, time
PAPER_BAL = 10_000.0 # USD starting
positions = {} # token_id -> shares
def paper_fok_buy(token_id, max_price, size):
book = fetch_book(token_id)
# Walk asks, fill what we can within max_price
filled = 0; cost = 0
for level in book.asks:
px = float(level["price"])
if px > max_price: break
avail = float(level["size"])
take = min(avail, size - filled)
filled += take
cost += take * px
if filled >= size: break
if filled < size:
return {"status":"rejected","filled":0} # FOK semantics
global PAPER_BAL
PAPER_BAL -= cost
positions[token_id] = positions.get(token_id, 0) + filled
log_paper({"ts": int(time.time()), "action":"buy",
"token": token_id, "size": filled, "price": cost/filled})
return {"status":"matched","filled":filled,"cost":cost}Adiciones para producción: función de venta de paper (espejo de buy), simulación GTC de paper (publica en el book a cierto precio, simula ejecución cuando el mid alcanza ese precio), conciliación entre el diario de paper y el diario live "que habría sido".
