Polymarket Bot Tutorial · Hoofdstuk 18 van 32
UMA dispute prediction bots op Polymarket: detecteer Optimistic Oracle proposals, voorspel dispute-waarschijnlijkheid, exploiteer pre-en-post-dispute prijs-asymmetrie en vermijd disputed-market death spirals.
Wat dit hoofdstuk behandelt
UMA's Optimistic Oracle resolved Polymarket-markten en disputes creëren prijs-anomalieën voor en nadat ze afgaan. Tradeable patronen bestaan aan beide kanten van een dispute, maar de strategie is operationeel complex en heeft meer bots verbrand dan gevoed. Dit hoofdstuk is het eerlijke playbook.
Dit is hoofdstuk 18 van onze 32-delige serie over het bouwen van een Polymarket trading bot. We behandelen het onderwerp in detail in de secties hieronder. De body content voor elke sectie wordt geschreven en hoofdstuk-per-hoofdstuk uitgerold; FAQ-antwoorden en referenties zijn al compleet en weerspiegelen production-ervaring van het draaien van onze eigen trader.
- Hoe UMA Optimistic Oracle werkt
- Een proposal on-chain detecteren
- Dispute-predictors (volume, ambiguïteit, historie)
- Pre-dispute prijs-asymmetrie
- Post-dispute trade setups
- Wanneer NIET disputed-markten te traden
- Code: abonneer op UMA proposed/disputed events
Hoe UMA Optimistic Oracle werkt
UMA's Optimistic Oracle (OO) is de dispute-resolution laag voor Polymarket. Elke markt-resolution gaat door OO; de meeste zijn niet betwist en settlen automatisch. De betwiste — disputes — triggeren een 24-72 uur voting-periode waarin UMA token-holders over de outcome beslissen.
De levenscyclus: Polymarkets resolver stelt een prijs voor (0 = NO won, 1 = YES won). Na een 2-uur challenge-venster, als niemand disputeert, wordt de prijs gefinaliseerd en het CTF-contract distribueert payouts. Als iemand disputeert, gaat de markt in een voting-venster; UMA-holders stemmen, de meerderheid wint.
Voor een bot zijn de relevante events ProposePrice (proposal ingediend, challenge-venster opent) en DisputePrice (dispute ingediend, voting-periode begint). Abonneer hierop om markt-resolution state in real time te tracken.
Een proposal on-chain detecteren
Het UMA OO contract op Polygon emit een ProposePrice event met de parameters (requester, identifier, timestamp, ancillaryData, proposer, proposedPrice). Filter op Polymarkets bekende requester-adres om tot relevante proposals te beperken.
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}")Het ancillaryData veld is hex-encoded JSON die de markt-vraag beschrijft. Het decoderen geeft je de markt-identifier die je kunt cross-referencen tegen je open posities.
Dispute-predictors (volume, ambiguïteit, historie)
Drie pre-dispute signalen correleren met latere werkelijke disputes.
- Totaal volume: markten met > 1M $ lifetime volume worden 4x zo vaak betwist als kleine markten. Meer kapitaal op het spel = meer incentive om uit te dagen.
- Ambigue wording: elke markt met "of vergelijkbaar", "officieel bevestigd" of compound condities (datum AND specifieke outcome) heeft verhoogde dispute-rates.
- Eerdere disputes op hetzelfde event: als een eerdere proposal al was betwist en her-voorgesteld, wordt de tweede proposal 2-3x normale rate betwist.
Een bot kan een "dispute probability" score berekenen uit deze features en posities vermijden in markten boven een threshold dicht bij resolution.
Pre-dispute prijs-asymmetrie
In de uren voor een waarschijnlijke dispute toont de marktprijs vaak asymmetrische beweging: de zijde die de proposer noemde als YES dreef omlaag (omdat traders vrezen dat een dispute het zal flippen), de andere zijde dreef omhoog.
Als je een directionele view hebt op hoe de dispute zal resolven, is dit een tradeable venster. Het risico: als de dispute niet gebeurt, keert de asymmetrie om wanneer het challenge-venster eventueel sluit en prijzen snap't terug naar de voorgestelde richting.
Eerlijk: de meeste pre-dispute asymmetrie-trades zijn verliezende trades omdat de meeste uitdagingen resolven in het voordeel van de originele proposal. De strategie werkt alleen wanneer je specifieke informatie hebt over waarom deze dispute waarschijnlijk wordt aangehouden.
Post-dispute trade setups
Nadat een dispute is ingediend, trade de markt voor 24-72 uur in "limbo" — bekend als disputed, outcome wordt gestemd. Twee setups bestaan.
Convergentie naar UMA consensus: als de dispute-resolution vroeg gesignaleerd is (bijv. een prominente UMA-stemmer neemt publiekelijk een kant), beweegt de prijs naar die resolution. Een bot die UMA Discord / Twitter signalen + prijs-actie kijkt kan dit 30-60% van de tijd vangen.
Volatility farming: limbo-periodes hebben brede spreads. Een geduldige market maker kan de spread tax over meerdere traders verdienen die in en uit roteren tijdens het voting-venster. Inventory-risico is hoog; dimensioneer overeenkomstig.
Beide vereisen comfort met de oprechte mogelijkheid van resolution tegen je positie. Behandel dispute-periode inventory als hooguit halve size.
Wanneer NIET disputed-markten te traden
Drie situaties waarin de dispute-trade by default fout is.
- Je hebt geen UMA-specifieke view. Als je enige edge is "de originele proposal lijkt me correct", heb je geen edge over de originele proposer — en de dispute-filer denkt het tegenovergestelde. De voting-outcome is een lancier van een munt die je niet kunt voorspellen.
- De dispute is op een ambigue wording. UMA-stemmers nemen meestal de kant van strict-lezing-van-de-vraag. Als de markt zei "voor 31 januari" en het event gebeurde 1 februari, resolved UMA NO ongeacht de intuïtie van de trader-populatie.
- Je houdt inventory van voor de dispute. Toevoegen aan een bestaande positie om door limbo "te middelen" is het klassieke kapitaal-vernietigings patroon. Houd of exit, voeg nooit toe.
Code: abonneer op UMA proposed/disputed events
Referentie: WebSocket-subscription op UMA OO events, gefilterd op Polymarket requester.
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)Het patroon: abonneer, decodeer, alert. Algorithmisch handelen op disputes is hoog-risico; de job van de bot is meestal het event aan een menselijke reviewer te surfacen.
