Polymarket Bot Tutorial · Capitolo 18 di 32
Bot di previsione delle dispute UMA su Polymarket: rilevare proposte dell'Optimistic Oracle, prevedere la probabilità di dispute, sfruttare l'asimmetria di prezzo pre e post dispute ed evitare le spirali di morte dei mercati disputati.
Cosa copre questo capitolo
L'Optimistic Oracle di UMA risolve i mercati Polymarket e le dispute creano anomalie di prezzo prima e dopo che si scatenano. Esistono pattern tradabili su entrambi i lati di una dispute, ma la strategia è operativamente complessa e ha bruciato più bot di quanti ne abbia nutriti. Questo capitolo è il playbook onesto.
Questo è il capitolo 18 della nostra serie in 32 parti sulla costruzione di un trading bot per Polymarket. Trattiamo l'argomento in profondità nelle sezioni qui sotto. Il corpo di ogni sezione viene scritto e rilasciato capitolo dopo capitolo; le risposte FAQ e i riferimenti sono già completi e riflettono l'esperienza di produzione del nostro trader interno.
- Come funziona l'Optimistic Oracle UMA
- Rilevare una proposta on-chain
- Predittori di dispute (volume, ambiguità, storia)
- Asimmetria di prezzo pre-dispute
- Setup di trade post-dispute
- Quando NON tradare mercati disputati
- Codice: sottoscriviti agli eventi UMA proposed/disputed
Come funziona l'Optimistic Oracle UMA
L'Optimistic Oracle (OO) di UMA è il layer di risoluzione delle dispute per Polymarket. Ogni resolution di mercato passa attraverso OO; la maggior parte non è contestata e si regola automaticamente. Quelle contestate — le dispute — scatenano un periodo di voto di 24-72 ore durante il quale i possessori di token UMA decidono l'outcome.
Il ciclo di vita: il resolver di Polymarket propone un prezzo (0 = NO ha vinto, 1 = YES ha vinto). Dopo una finestra di sfida di 2 ore, se nessuno disputa, il prezzo è finalizzato e il contratto CTF distribuisce i payout. Se qualcuno disputa, il mercato entra in una finestra di voto; i possessori UMA votano, la maggioranza vince.
Per un bot, gli eventi rilevanti sono ProposePrice (proposta inserita, finestra di sfida si apre) e DisputePrice (dispute depositata, periodo di voto inizia). Sottoscriviti a questi per tracciare lo stato di resolution del mercato in tempo reale.
Rilevare una proposta on-chain
Il contratto UMA OO su Polygon emette un evento ProposePrice con i parametri (requester, identifier, timestamp, ancillaryData, proposer, proposedPrice). Filtra per l'address noto del requester Polymarket per limitarti alle proposte rilevanti.
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}")Il campo ancillaryData è JSON hex-encoded che descrive la domanda del mercato. Decodificarlo ti dà l'identificatore di mercato che puoi cross-referenziare contro le tue posizioni aperte.
Predittori di dispute (volume, ambiguità, storia)
Tre segnali pre-dispute correlano con dispute effettive successive.
- Volume totale: i mercati con > 1M $ di volume lifetime sono disputati a 4x il tasso dei mercati piccoli. Più capitale in gioco = più incentivo a sfidare.
- Wording ambiguo: ogni mercato con "o simile", "ufficialmente confermato" o condizioni composte (data E outcome specifico) ha tassi di dispute elevati.
- Dispute passate sullo stesso evento: se una proposta precedente è già stata disputata e ri-proposta, la seconda proposta è disputata a 2-3x il tasso normale.
Un bot può calcolare uno score di "probabilità di dispute" da queste feature ed evitare di prendere posizioni in mercati sopra una soglia vicini alla resolution.
Asimmetria di prezzo pre-dispute
Nelle ore prima di una probabile dispute, il prezzo del mercato mostra spesso un movimento asimmetrico: il lato che il proposer ha nominato come YES deriva in basso (perché i trader temono che una dispute lo capovolgerà), l'altro lato deriva in alto.
Se hai una vista direzionale su come la dispute si risolverà, questa è una finestra tradabile. Il rischio: se la dispute non accade, l'asimmetria si inverte quando la finestra di sfida si chiude senza eventi e i prezzi scattano indietro verso la direzione proposta.
Onesto: la maggior parte dei trade di asimmetria pre-dispute sono trade perdenti perché la maggior parte delle sfide si risolve a favore della proposta originale. La strategia funziona solo quando hai informazioni specifiche sul perché questa dispute è probabile che venga sostenuta.
Setup di trade post-dispute
Dopo che una dispute è depositata, il mercato tratta per 24-72 ore in "limbo" — noto come disputato, outcome da votare. Esistono due setup.
Convergenza al consenso UMA: se la resolution della dispute è segnalata presto (es. un votante UMA prominente prende pubblicamente una parte), il prezzo si muove verso quella resolution. Un bot che guarda segnali Discord/Twitter UMA + azione di prezzo può catturare questo il 30-60% delle volte.
Volatility farming: i periodi di limbo hanno spread ampi. Un market maker paziente può guadagnare la tassa di spread tra più trader che ruotano dentro e fuori durante la finestra di voto. Il rischio di inventario è alto; dimensiona di conseguenza.
Entrambi richiedono confort con la possibilità genuina di resolution contro la tua posizione. Tratta l'inventario nel periodo di dispute come metà size al massimo.
Quando NON tradare mercati disputati
Tre situazioni in cui il trade di dispute è sbagliato di default.
- Non hai una vista UMA-specifica. Se il tuo unico edge è "la proposta originale mi sembra corretta", non hai edge sul proposer originale — e il filer della dispute pensa l'opposto. L'outcome del voto è un lancio di moneta che non puoi prevedere.
- La dispute è su wording ambiguo. I votanti UMA generalmente prendono il lato della lettura stretta della domanda. Se il mercato diceva "entro il 31 gennaio" e l'evento è successo il 1 febbraio, UMA risolverà NO indipendentemente dall'intuizione della popolazione di trader.
- Tieni inventario da prima della dispute. Aggiungere a una posizione esistente per "fare media" attraverso il limbo è il classico pattern di distruzione di capitale. Tieni o esci, mai aggiungere.
Codice: sottoscriviti agli eventi UMA proposed/disputed
Riferimento: sottoscrizione WebSocket agli eventi UMA OO, filtrata per requester 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)Il pattern: sottoscrivi, decodifica, alert. Agire sulle dispute algoritmicamente è ad alto rischio; il lavoro del bot è di solito far emergere l'evento a un human reviewer.
