Tutorial de Bot para Polymarket · Capítulo 18 de 32
Bots de predicción de disputas UMA en Polymarket: detecta propuestas del Optimistic Oracle, predice la probabilidad de disputa, aprovecha la asimetría de precios antes y después de la disputa, y evita las espirales de muerte de mercados disputados.
Qué cubre este capítulo
El Optimistic Oracle (OO) de UMA resuelve los mercados de Polymarket, y las disputas crean anomalías de precio antes y después de activarse. Existen patrones operables en ambos lados de una disputa, pero la estrategia es operativamente compleja y ha quemado más bots de los que ha alimentado. Este capítulo es el playbook honesto.
- Cómo funciona el Optimistic Oracle de UMA
- Detectar una propuesta on-chain
- Predictores de disputa (volumen, ambigüedad, historial)
- Asimetría de precio pre-disputa
- Setups de trading post-disputa
- Cuándo NO operar mercados disputados
- Código: suscribirse a eventos propuestos/disputados de UMA
Cómo funciona el Optimistic Oracle de UMA
El Optimistic Oracle (OO) de UMA es la capa de resolución de disputas para Polymarket. Cada resolución de mercado pasa por OO; la mayoría no se contesta y se liquida automáticamente. Los casos disputados - las disputas - activan un periodo de votación de 24 a 72 horas durante el cual los holders de tokens UMA deciden el resultado.
El ciclo de vida: el resolver de Polymarket propone un precio (0 = ganó NO, 1 = ganó SÍ). Después de una ventana de desafío de 2 horas, si nadie disputa, el precio se finaliza y el contrato CTF distribuye los pagos. Si alguien disputa, el mercado entra en una ventana de votación; los holders de UMA emiten sus votos y gana la mayoría.
Para un bot, los eventos relevantes son ProposePrice (se registró la propuesta, se abre la ventana de desafío) y DisputePrice (se presentó la disputa, comienza el periodo de votación). Suscríbete a estos eventos para seguir el estado de resolución del mercado en tiempo real.
Detectar una propuesta on-chain
El contrato OO de UMA en Polygon emite un evento ProposePrice con los parámetros (requester, identifier, timestamp, ancillaryData, proposer, proposedPrice). Filtra por la dirección conocida del requester de Polymarket para limitarte a propuestas relevantes.
POLY_REQUESTER = "0x..." # Polymarket Adjudicator
filt = oo_contract.events.ProposePrice.create_filter(
fromBlock="latest",
argument_filters={"requester": POLY_REQUESTER}
)
for event in filt.get_new_entries():
market_id = decode_ancillary(event.args.ancillaryData)
proposed = "YES" if event.args.proposedPrice == 1e18 else "NO"
print(f"PROPOSE: market {market_id} → {proposed}")El campo ancillaryData es JSON codificado en hex que describe la pregunta del mercado. Decodificarlo te da el identificador del mercado, que puedes cruzar con tus posiciones abiertas.
Predictores de disputa (volumen, ambigüedad, historial)
Tres señales pre-disputa se correlacionan con disputas reales posteriores.
- Volumen total: los mercados con más de $1M en volumen de por vida son disputados al 4x de la tasa de los mercados pequeños. Más capital en juego = más incentivo para impugnar.
- Redacción ambigua: cualquier mercado con "or similar", "officially confirmed" o condiciones compuestas (fecha Y resultado específico) tiene tasas de disputa elevadas.
- Disputas previas sobre el mismo evento: si una propuesta anterior ya fue disputada y se volvió a proponer, la segunda propuesta es disputada a una tasa 2-3x superior a la normal.
Un bot puede calcular una puntuación de "probabilidad de disputa" a partir de estas variables y evitar tomar posiciones en mercados por encima de un umbral cerca de la resolución.
Asimetría de precio pre-disputa
En las horas previas a una disputa probable, el precio del mercado suele mostrar un movimiento asimétrico: el lado que el proponente nombró como SÍ tiende a bajar (porque los traders temen que una disputa lo voltee), mientras que el otro lado sube.
Si tienes una visión direccional sobre hacia dónde se resolverá la disputa, esta es una ventana operable. El riesgo: si la disputa no ocurre, la asimetría se revierte cuando la ventana de desafío cierra sin incidentes y los precios vuelven de golpe a la dirección propuesta.
Honestamente: la mayoría de las operaciones de asimetría pre-disputa pierden dinero, porque la mayoría de los desafíos se resuelven a favor de la propuesta original. La estrategia solo funciona cuando tienes información específica sobre por qué es probable que esta disputa se sostenga.
Setups de trading post-disputa
Después de presentarse una disputa, el mercado cotiza durante 24 a 72 horas en un "limbo" - se sabe que está disputado, pero el resultado queda sujeto a votación. Existen dos setups.
Convergencia hacia el consenso de UMA: si la resolución de la disputa se señala temprano (por ejemplo, un votante prominente de UMA toma públicamente un bando), el precio se mueve hacia ese resultado. Un bot que siga señales de Discord / Twitter de UMA + la acción del precio puede capturar esto entre 30% y 60% de las veces.
Volatility farming: los periodos de limbo tienen spreads amplios. Un market maker paciente puede capturar el spread a lo largo de múltiples traders que entran y salen durante la ventana de votación. El riesgo de inventario es alto; dimensiona el tamaño en consecuencia.
Ambos requieren comodidad con la posibilidad real de que la resolución vaya en contra de tu posición. Trata el inventario durante el periodo de disputa como máximo a la mitad del tamaño normal.
Cuándo NO operar mercados disputados
Tres situaciones en las que el trade de disputa es incorrecto por defecto.
- No tienes una visión específica de UMA. Si tu única ventaja es "la propuesta original me parece correcta", no tienes ventaja sobre el proponente original - y quien presentó la disputa piensa lo contrario. El resultado de la votación es un volado que no puedes predecir.
- La disputa es por una redacción ambigua. Los votantes de UMA suelen inclinarse por una lectura estricta de la pregunta. Si el mercado decía "antes del 31 de enero" y el evento ocurrió el 1 de febrero, UMA resolverá NO sin importar la intuición de la población trader.
- Ya tienes inventario desde antes de la disputa. Agregar a una posición existente para "promediar a la baja" durante el limbo es el patrón clásico de destrucción de capital. Mantén o sal, nunca agregues.
Código: suscribirse a eventos propuestos/disputados de UMA
Referencia: suscripción WebSocket a eventos de UMA OO, filtrada por el requester de Polymarket.
from web3 import Web3
w3 = Web3(Web3.WebsocketProvider(POLYGON_WSS))
oo = w3.eth.contract(address=UMA_OO_ADDR, abi=UMA_OO_ABI)
POLY = "0x...".lower()
dispute_filter = oo.events.DisputePrice.create_filter(fromBlock="latest")
propose_filter = oo.events.ProposePrice.create_filter(fromBlock="latest")
while True:
for event in dispute_filter.get_new_entries():
if event.args.requester.lower() == POLY:
on_dispute(event)
for event in propose_filter.get_new_entries():
if event.args.requester.lower() == POLY:
on_propose(event)
time.sleep(2)
def on_dispute(event):
market_q = decode_ancillary_to_question(event.args.ancillaryData)
send_telegram(f"DISPUTE: {market_q}")
# If we hold a position in this market, alert + consider exit
if market_q in our_positions:
flag_position_for_review(market_q)El patrón: suscribirse, decodificar, alertar. Actuar algorítmicamente sobre disputas es de alto riesgo; normalmente el trabajo del bot es exponer el evento a un revisor humano.
