Polymarket resolution explained

Polymarket resolution explained: Dieser Leitfaden führt durch den kompletten Lifecycle vom Reporting bis zum Redeem von Outcome-Token, erklärt die UMA-optimistische-Oracle-Streitphase und die praktischen Implikationen für Trader. Sie erfahren, was on-chain und off-chain passiert, welche Schritte für Nutzer gaslos sind und welche Zeitpunkte und Risiken für Arbitrage und Positionsmanagement relevant sind.

Wesentliche Erkenntnisse

• Resolution beginnt mit einem Outcome-Report und kann eine optimistische UMA-Streitzeit durchlaufen, bevor die finale Abwicklung erfolgt.
• Während Outcome-Token ERC-1155-CTF-Vermögenswerte sind, sind Split/Merge/Redeem und Order-Placement für Nutzer über den Relayer gaslos.
• Streitfälle, Orakelverzögerungen, partielle Fills und Abwicklungszeiten schaffen reale Risiken, selbst wenn Preise eine mathematische Edge implizieren.
• Merken Sie sich die Reihenfolge: report → dispute window (UMA) → finalization → redeem der Gewinn-Token für pUSD.

Was "Resolution" auf Polymarket bedeutet

Auf Polymarket ist Resolution der Prozess, der handelbare Outcome-Token in einlösbare Gelder umwandelt. In binären und Multi-Outcome-Märkten bestimmt ein Orakel letztlich, welche Outcome(s) als YES aufgelöst werden. Wenn ein Outcome final ist, wird jeder Gewinn-Token gegen $1.00 pUSD einlösbar; verlierende Token sind wertlos.

Märkte nutzen das Gnosis Conditional Token Framework (CTF) für Outcome-Token. Diese Token verhalten sich wie normale ERC-1155-Bestände: Sie können sie auf dem CLOB handeln, transferieren oder durch Split/Merge-Operationen kombinieren. Der entscheidende Unterschied bei der Resolution ist, dass der finale Orakel-Report den CTF-Redeem-Fluss freischaltet, der Gewinn-Token in pUSD umwandelt.

Der Reporting-Schritt: wer reportet und warum es wichtig ist

Resolution beginnt, wenn ein Reporter ein Outcome an das Orakel-System übermittelt. Polymarket verwendet das UMA-optimistic-oracle für das Reporting. Ein eingereichter Report benennt das Outcome, das der Reporter für korrekt hält, und startet die Uhr für die nächste Phase.

Warum das wichtig ist:

• Der Report ist das erste öffentliche Signal dafür, dass das Marktereignis einen auflösbaren Zustand erreicht hat. Trader, die Orderbücher überwachen, können sofort reagieren.
• Reports sind in der Polymarket-UI und über die Gamma API sichtbar, sodass Arbitrage-Bots und menschliche Trader sie programmatisch erkennen können.

UMA-optimistische-Oracle-Streitperiode (was sie ist, nicht wie lang)

Nachdem ein Report gepostet wurde, erlaubt UMAs optimistisches Modell ein Streitfenster, in dem Herausforderer Gegenbeweise vorlegen können. Wird ein Disput eingereicht, pausiert der optimistische Fluss und UMA löst die Meinungsverschiedenheit gemäß seinem Prozess.

Wichtige praktische Punkte:

• Die Streitperiode führt zu Unsicherheit. Ein Markt, der als resolved erschien, kann für eine Untersuchung wieder geöffnet werden, wenn UMA einen Disput erhält.
• Da die genauen zeitlichen und verfahrensbezogenen Details von UMA extern zu Polymarket sind, sollten Trader jeden Markt, der sich in oder nahe der Dispute-Phase befindet, als mit Resolution-Risiko behaftet behandeln.

Hinweis: Das System-Prompt legt fest, dass UMA verwendet wird, gibt aber nicht die Länge des Streitfensters an. Siehe den Abschnitt "Notes" für diese Lücke.

Finalisierung und Redeem von CTF-Token

Sobald der Orakelprozess abgeschlossen ist und das Outcome final ist, wird der Markt on-chain finalisiert. Zu diesem Zeitpunkt können Nutzer gewinnende ERC-1155-Outcome-Token über die CTF-Redeem-Operation gegen pUSD einlösen.

Praktisch auf Polymarket:

• CTF-Operationen (split / merge / redeem) werden über den Polymarket Relayer abgewickelt, sodass sie für Sie gaslos sind.
• Das Redeem wandelt jeden Gewinn-Token in $1.00 pUSD um, das Sie dann abheben oder zum Aufteilen in neue Positionen verwenden können.

Wenn Sie vor der Resolution ein komplettes Set an Outcome-Token halten, ist das Redeem unkompliziert: Sie erhalten nur für die gewinnende(n) Seite(n) pUSD. Wenn Sie partielle Positionen halten, werden nur die entsprechenden Gewinner-Token eingelöst.

Häufige Edge-Cases bei Resolution, die Trader sehen

• Disputed finalizations: UMA-Dispute können die Abwicklung verzögern und temporär das Redeem verhindern. Das beeinflusst die Liquidität und kann Kapital blockieren.
• Partielle Fills und Orderausführung: Eine teilweise vor der Resolution gefüllte Order kann Sie long gegenüber bestimmten Token und short gegenüber anderen lassen; stellen Sie sicher, dass Sie Fills nachverfolgen, um unerwartete Exposures zu vermeiden.
• Tick-Size- und Preisupdates: Tick-Size ändert sich in der Nähe der Resolution und kann verfügbare Orders beeinflussen; der WebSocket sendet tick_size_change-Events, die für Bots relevant sind.
• Fee- und Reward-Effekte: Maker-Gebühren sind null; Taker-Gebühren variieren je nach Kategorie. Gebühren und Builder-Attribution (wenn Sie über einen Builder routen) beeinflussen das Nettoergebnis, verändern aber nicht den Oracle-Abwicklungsprozess.

Gehen Sie niemals davon aus, dass ein als settled betrachteter Markt nicht wieder geöffnet werden kann, falls UMA einen Disput auslöst. Bestätigen Sie stets den Marktstatus, bevor Sie eine CTF-Redeem-Operation oder große Transfers starten.

Wie sich das auf Arbitrage- und Endgame-Strategien auswirkt

Für Intra-Market-Arbitrage (Kauf eines Sets, wenn Σ bestAsk < $1.00) sind Resolution-Mechaniken zentral: Ihr theoretischer Gewinn wandelt sich erst nach Finalisierung und Redeem in pUSD um. Das bedeutet, dass Timing, Orakel-Disput-Risiko und Abwicklungsverzögerungen genauso wichtig sind wie die Orderausführung.

Praktische Faustregeln:

• Betrachten Sie den Spread erst dann als mathematische Edge, nachdem Sie Gebühren, Slippage und Disput-Risiken berücksichtigt haben. Listen Sie diese Risiken immer auf, bevor Sie einen Trade als Arbitrage bezeichnen.
• Bei Endgame-Strategien (Preise nahe Resolution wie $0.95–$0.99) seien Sie besonders vorsichtig: Kleinere Margen und UMA-Dispute können ein kurzfristiges Spiel in einen Verlust verwandeln.
• Nutzen Sie die Polymarket-APIs und den Market WebSocket, um Reports, tick_size_change, best_bid_ask und last_trade_price in Echtzeit zu überwachen.

Resolution programmatisch überwachen

APIs und Feeds, die Sie beobachten sollten:

• Gamma API (https://gamma-api.polymarket.com): Markt- und Event-Metadaten, einschließlich resolution-bezogener Felder. Verwenden Sie den /markets-Endpoint mit cursor-basierter Pagination.
• Data API (https://data-api.polymarket.com): Positionen, Trades und Open Interest zur Nachverfolgung von Fills und Exposure.
• Market WebSocket (wss://ws-subscriptions-clob.polymarket.com/ws/market): Echtzeit-Book, price_change, best_bid_ask, last_trade_price und tick_size_change. PING alle 10s; subscribe mit custom_feature_enabled, um best_bid_ask zu erhalten.

Kombinieren Sie diese Feeds, um einen Report zu erkennen, auf UMA-Dispute-Signale in der UI oder im Data-Feed zu achten und mit der endgültigen Rechnungslegung zu warten, bis der Marktstatus final ist.

Checkliste: Was zu tun ist, wenn ein Markt reported

• Bestätigen Sie das gemeldete Outcome in Gamma und in der Polymarket-UI.
• Pausieren Sie Automatisierung, die von sofortiger Finalität ausgeht, bis die UMA-Dispute-Phase abgeschlossen ist.
• Überwachen Sie offene Orders und Fills; stornieren oder passen Sie sie bei Bedarf an, um unbeabsichtigte Exposures zu vermeiden.
• Nach der Finalisierung, redeem Sie Gewinn-Token über die UI, das SDK oder Ihren Relayer-integrierten Ablauf.

Wie sich das auf Ihr Trading auswirkt

Resolution ist der finale Engpass zwischen Orderausführung und realisiertem pUSD. Für aktive Trader und Arbitrageure bedeutet das, dass Sie drei verknüpfte Risiken managen müssen: Ausführung (Fills und Slippage), Orakel-Resolution (Reports und Dispute) und Abwicklungszeit (Redeem und Withdrawals). Erfolgreiche Ausführung erfordert sowohl schnelle Markt-Tools als auch konservative Annahmen zum Dispute-Risiko.

Wenn Sie Automatisierung bauen, protokollieren Sie jeden Fill und überwachen Sie die oben genannten WebSocket-Kanäle. Behandeln Sie Märkte, die sich in oder nahe einem Report-Zustand befinden, als risikoreicher, bis UMA sie freigibt.

Abschließende Bemerkung: "Polymarket resolution explained" soll Ihnen die operative Checkliste und das mentale Modell geben, um Settlement-Risiko zu managen. Nutzen Sie die APIs und den WebSocket, denken Sie daran, dass CTF-Redeem über den Relayer gaslos ist, und rechnen Sie stets mit Dispute-Fenstern, bevor Sie annehmen, ein Trade sei in pUSD umgewandelt worden.

Frequently asked questions

Wer reportet Outcomes auf Polymarket?

Polymarket verwendet das UMA-optimistic-oracle für Outcome-Reporting. Reports werden an UMA übermittelt und sind in der Polymarket-UI und in den APIs sichtbar; UMA behandelt anschließende Dispute gemäß seinem Prozess.

Was passiert während des UMA-Dispute-Fensters?

Nach einem Report erlaubt UMA eine Dispute-Periode, in der Herausforderer das gemeldete Outcome anfechten können. Wird ein Disput eingereicht, pausiert UMA die optimistische Abwicklung und durchläuft seinen Streitlösungsprozess, was das Redeem von Gewinn-Token verzögern kann.

Sind CTF-Operationen auf Polymarket gaslos?

Ja. Polymarket sponsert Gas über seinen Relayer. Split, merge, redeem, Transfers und Order-Placement sind für den Endnutzer gaslos, da sie über den Relayer geroutet werden.

Kann ein Markt wieder geöffnet werden, nachdem er als resolved aussah?

Ja. Wenn UMA einen Disput erhält, kann ein Markt, der als resolved erschien, wieder geöffnet oder verzögert werden, bis UMA entscheidet. Behandeln Sie jeden Markt in oder nahe der Dispute-Phase als mit Resolution-Risiko behaftet.

Wie kann ich programmatisch einen Report oder Disput erkennen?

Verwenden Sie die Gamma API für Markt-Metadaten und den Market WebSocket (wss://ws-subscriptions-clob.polymarket.com/ws/market) für Echtzeit-Ereignisse wie price_change, best_bid_ask, last_trade_price und tick_size_change. Kombinieren Sie diese Feeds mit Data API-Endpoints, um Positionen und Fills zu überwachen.