Polymarket Bot Tutorial · Kapitel 18 von 32
UMA Dispute-Prediction-Bots auf Polymarket: Optimistic Oracle-Proposals erkennen, Dispute-Wahrscheinlichkeit vorhersagen, Preis-Asymmetrien vor und nach dem Dispute ausnutzen und Death Spirals bei disputed markets vermeiden.
Was dieses Kapitel abdeckt
UMAs Optimistic Oracle (OO) ist die Dispute-Resolution-Schicht für Polymarket, und Disputes erzeugen vor und nach ihrer Auslösung Preis-Anomalien. Tradeable Patterns gibt es auf beiden Seiten eines Disputes, aber die Strategie ist operativ komplex und hat mehr Bots verbrannt, als sie ernährt hat. Dieses Kapitel ist das ehrliche Playbook.
- Wie UMA Optimistic Oracle funktioniert
- Eine Proposal on-chain erkennen
- Dispute-Predictors (Volume, Ambiguity, History)
- Pre-Dispute-Preis-Asymmetrie
- Post-Dispute-Trade-Setups
- Wann man disputed markets NICHT traden sollte
- Code: auf UMA proposed/disputed events subscriben
Wie UMA Optimistic Oracle funktioniert
UMAs Optimistic Oracle (OO) ist die Dispute-Resolution-Schicht für Polymarket. Jede Market-Resolution läuft über OO; die meisten sind unangefochten und werden automatisch abgewickelt. Die umstrittenen Fälle - Disputes - lösen eine 24- bis 72-stündige Voting-Phase aus, in der UMA-Token-Holder das Ergebnis entscheiden.
Der Ablauf: Der Resolver von Polymarket schlägt einen Preis vor (0 = NO hat gewonnen, 1 = YES hat gewonnen). Nach einem 2-stündigen Challenge-Window wird der Preis, wenn niemand Dispute einlegt, finalisiert und der CTF-Contract verteilt die Auszahlungen. Legt jemand Dispute ein, geht der Markt in ein Voting-Window; UMA-Holder geben Votes ab, die Mehrheit gewinnt.
Für einen Bot sind die relevanten Events ProposePrice (Proposal eingereicht, Challenge-Window geöffnet) und DisputePrice (Dispute eingereicht, Voting-Phase beginnt). Subscribe auf diese Events, um den Market-Resolution-Status in Echtzeit zu verfolgen.
Eine Proposal on-chain erkennen
Der UMA-OO-Contract auf Polygon emittiert ein ProposePrice-Event mit den Parametern (requester, identifier, timestamp, ancillaryData, proposer, proposedPrice). Filtere nach der bekannten Requester-Adresse von Polymarket, um die relevanten Proposals einzugrenzen.
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}")Das Feld ancillaryData ist hex-encodiertes JSON, das die Marktfrage beschreibt. Wenn du es decodierst, erhältst du die Markt-ID, die du mit deinen offenen Positionen abgleichen kannst.
Dispute-Predictors (Volume, Ambiguity, History)
Drei Signale vor einem Dispute korrelieren mit späteren tatsächlichen Disputes.
- Total Volume: Märkte mit > $1M Lifetime-Volume werden 4x so häufig disputed wie kleine Märkte. Mehr Kapital auf dem Spiel = mehr Anreiz, anzufechten.
- Ambiguous wording: Jeder Markt mit "or similar", "officially confirmed" oder zusammengesetzten Bedingungen (Datum AND spezifisches Ergebnis) hat erhöhte Dispute-Raten.
- Vergangene Disputes beim selben Event: Wenn ein früheres Proposal bereits disputed und erneut vorgeschlagen wurde, wird die zweite Proposal 2-3x häufiger disputed als normal.
Ein Bot kann aus diesen Merkmalen einen "Dispute Probability"-Score berechnen und Positionen in Märkten oberhalb eines Schwellenwerts kurz vor der Resolution vermeiden.
Pre-Dispute-Preis-Asymmetrie
In den Stunden vor einem wahrscheinlichen Dispute zeigt der Marktpreis oft eine asymmetrische Bewegung: Die Seite, die der Proposer als YES genannt hat, driftet nach unten (weil Trader befürchten, dass ein Dispute das Ergebnis kippt), die andere Seite driftet nach oben.
Wenn du eine Richtungsmeinung dazu hast, in welche Richtung der Dispute aufgelöst wird, ist das ein handelbares Zeitfenster. Das Risiko: Wenn der Dispute nicht eintritt, kehrt sich die Asymmetrie um, sobald das Challenge-Window ohne Ereignis endet und die Preise in die vorgeschlagene Richtung zurückspringen.
Ehrlich: Die meisten Pre-Dispute-Asymmetrie-Trades sind Verlusttrades, weil die meisten Challenges zugunsten des ursprünglichen Proposals enden. Die Strategie funktioniert nur, wenn du spezifische Informationen darüber hast, warum dieser Dispute wahrscheinlich bestätigt wird.
Post-Dispute-Trade-Setups
Nachdem ein Dispute eingereicht wurde, handelt der Markt 24-72 Stunden in einer Art "Limbo" - bekannt als disputed, das Ergebnis wird per Vote entschieden. Es gibt zwei Setups.
Convergence to UMA consensus: Wenn die Dispute-Resolution früh signalisiert wird (z. B. wenn ein prominenter UMA-Voter öffentlich eine Seite wählt), bewegt sich der Preis in Richtung dieses Ergebnisses. Ein Bot, der UMA-Discord-/Twitter-Signale + Price Action beobachtet, kann dies 30-60% der Zeit erwischen.
Volatility farming: In Limbo-Phasen sind die Spreads breit. Ein geduldiger Market Maker kann die Spread-Tax über mehrere Trader hinweg verdienen, die während des Voting-Windows rein- und rausrotieren. Das Inventory-Risiko ist hoch; Größe entsprechend wählen.
Beide erfordern die Bereitschaft, dass die Resolution real gegen deine Position ausfällt. Behandle Inventory im Dispute-Period höchstens als halbe Größe.
Wann man disputed markets NICHT traden sollte
Drei Situationen, in denen der Dispute-Trade standardmäßig falsch ist.
- Du hast keine UMA-spezifische Meinung. Wenn dein einziger Edge lautet: "Die ursprüngliche Proposal sieht für mich richtig aus", dann hast du keinen Edge gegenüber dem ursprünglichen Proposer - und der Dispute-Filer sieht es genau andersherum. Das Voting-Ergebnis ist ein Coin Flip, den du nicht vorhersagen kannst.
- Der Dispute bezieht sich auf eine zweifelhafte Formulierung. UMA-Voter tendieren generell zu einer strikten Lesart der Frage. Wenn der Markt sagte "bis zum 31. Januar" und das Event fand am 1. Februar statt, wird UMA NO auflösen, unabhängig von der Intuition der Trader-Population.
- Du hältst Inventory aus der Zeit vor dem Dispute. Zu einer bestehenden Position in der Limbo-Phase dazuzukaufen, um "durchzuaveragen", ist das klassische Muster der Kapitalvernichtung. Halten oder exitten, niemals adden.
Code: auf UMA proposed/disputed events subscriben
Referenz: WebSocket-Subscription auf UMA-OO-Events, gefiltert nach dem 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)Das Muster: subscriben, decodieren, alarmieren. Disputes algorithmisch zu handeln ist hochriskant; die Aufgabe des Bots ist normalerweise, das Event für einen menschlichen Reviewer sichtbar zu machen.
