Prediction-Market-Arbitrage: Zwischen Polymarket und Mirror-Märkten hedgen

Wenn du bereits einen Polymarket-Bot betreibst, brauchst du möglicherweise kein neues Prognosemodell. Eine zweite Liquiditätsoberfläche kann reichen, damit deine bestehende Pricing-, Execution- und Risk-Infrastruktur mehr leistet.

Prediction-Market-Arbitrage klingt auf einer Tabelle einfach: dasselbe Ereignis auf zwei Venues finden, die günstigere Seite kaufen, die teurere verkaufen und die Differenz behalten.

In der Produktion ist die schwierige Frage nicht, ob zwei Überschriften ähnlich aussehen. Du musst beweisen, dass beide Instrumente denselben Payoff haben, die Outcome-Token korrekt zuordnen, beide Legs zu realen Preisen ausführen und die Zeit bis zur Abrechnung überstehen.

Das ist bei einem Mirror-Markt besonders wichtig. Ein Polymarket-Mirror kann eine externe Referenz und einen möglichen Hedge für Kuest-Flow liefern. Er ist aber keine Garantie dafür, dass jede Preisdifferenz risikofreie Arbitrage ist.

Dieser Leitfaden richtet sich an crypto-native Market Maker, quantitative Trader und Desks mit Erfahrung in Cross-Venue-Execution.

Was ist Prediction-Market-Arbitrage?

Prediction-Market-Arbitrage versucht, eine Preisdifferenz zwischen wirtschaftlich äquivalenten Kontrakten auszunutzen oder eine Position zu bauen, deren kombinierter Payoff bekannt ist, während die Einstiegskosten darunter liegen.

Arbitrage mit komplementären Outcomes

In einem binären Markt sind YES und NO komplementäre Ergebnisse. Wenn YES auf einem Venue und NO auf einem anderen Venue für zusammen weniger als 1 US-Dollar ausführbar gekauft werden können und beide Kontrakte exakt gleich auflösen, beträgt der Brutto-Abrechnungswert 1 US-Dollar.

Brutto-Edge = 1 $ - (YES-Einstiegspreis + NO-Einstiegspreis)

Gebühren, Gas, Slippage, Teilfüllungen, gebundenes Kapital und Settlement-Kosten reduzieren den tatsächlichen Edge.

Cross-Venue-Hedge für Inventar

Ein Market Maker versucht nicht immer, einen garantierten Payoff zu sperren. Er kann auf Kuest quoten und Polymarket nutzen, um Inventar auszugleichen, das durch Kundenflow entsteht.

Wenn ein Kunde 1.000 YES-Kontrakte von deinem Kuest-Ask kauft, kann dein System zum Beispiel gleichwertiges YES-Inventar auf Polymarket kaufen. Das ist ein Inventar-Hedge und nicht automatisch risikofreie Arbitrage: Das externe Buch kann nur teilweise füllen, teurer werden oder verschwinden.

Der Unterschied beeinflusst Bot, Kapitalmodell und Risikobericht. Der PredictEngine-Leitfaden betont deshalb ausführbare Preise statt Midpoints. Die Preduck-Dokumentation erklärt zusätzlich, wie Cross-Venue-Märkte verglichen werden sollten.

Warum Polymarket-Trader Mirror-Market-Arbitrage suchen

Polymarket ist wegen seiner CLOB-Daten, aktiven Trader, Orderbücher und etablierten Bot-Infrastruktur eine natürliche Referenz für Prediction-Market-Maker.

Ein weiterer Markt kann aber neue Nachfrage, neue Operator-Audiences und finanzierte Liquiditätsmandate bringen. Ein Desk kann Teile seiner Polygon-, USDC-, CLOB-, Pricing- und Inventory-Infrastruktur wiederverwenden und neben Trading-P&L eine Kampagnenvergütung verdienen.

Kuest verbindet gebrandete Operator-Frontends mit gemeinsamer Marktdiscovery, Order Matching, Wallet-Services und Lifecycle-Daten. Märkte mit denselben Outcome-Token-IDs verwenden dieselben Kuest-Orderbücher. Deshalb ist eine unterschiedliche Darstellung auf zwei Operator-Seiten nicht automatisch eine Arbitrage-Chance.

Eine Preisdifferenz zwischen zwei Kuest-Frontends ist nicht automatisch ein unabhängiger Venue-Spread.

Interessanter ist meist die Beziehung zwischen Kuest-Netzwerkflow und einer externen Referenz wie Polymarket oder zwischen einem Operator-Markt und einem separat validierten Kontrakt.

Wie Kuest Mirror-Märkte funktionieren

„Mirror“ beschreibt die Beziehung zu einer ausgewählten externen Quelle. Das Frontend bettet nicht einfach das Orderbuch eines anderen Venues ein.

Ein Operator kann Polymarket-Mirrors, eigene Märkte und ausdrücklich gewählte Quellen kombinieren. Der Operator besitzt Brand, Domain, Nutzererlebnis und Betrieb. Kuest stellt CLOB, Marktdaten, Matching, relayed Wallet-Aktionen und Polygon-Settlement bereit.

Für einen Market Maker gilt:

1. Die Quelle definiert die Referenzspezifikation. Prüfe Frage, Outcomes, Zeit, Resolution-Quelle und Sonderfälle.
2. Kuest erzeugt eine kompatible Darstellung. Der Mirror besitzt eigene Kuest-Metadaten und Book-Kontext.
3. Das Outcome-Mapping muss explizit sein. Der Bot muss YES und NO auf beiden Seiten kennen.
4. Flow bleibt dem Ursprungsoperator zugeordnet. Site, Bot und SDK können in dessen Economics eingehen.
5. Settlement braucht eigene Prüfungen. Ein Preisverhältnis ist nur so stark wie der Lifecycle.

Die Kuest-Architektur beschreibt diese Verantwortungsteilung. Das Open-Source-Repository dokumentiert Polygon, USDC, APIs und SDKs.

Die Polymarket-Hedge-Strategie: dasselbe Outcome über Venues handeln

Eine Polymarket-Hedge-Strategie beginnt mit der Position deines Kuest-Buchs und nicht mit der Annahme, dass jedes YES überall dasselbe bedeutet.

Einen gefüllten Quote mit demselben Outcome hedgen

Du verkaufst 1.000 YES auf Kuest zu 0,54 $. Wenn das Polymarket-Ask für dasselbe, exakt gemappte YES bei 0,55 $ liegt, kannst du bis zur verfügbaren Tiefe Inventar zurückkaufen.

Dein Ergebnis ist die Differenz zwischen Verkauf und Hedge abzüglich Kuest-Gebühren, Polymarket-Gebühren, Gas, Slippage und adverse selection. Wenn der Hedge nur 600 Kontrakte füllt, bleiben 400 Kontrakte Risiko.

Ein vollständiges Paar konstruieren

Wenn YES auf Kuest bei 0,53 $ und NO auf Polymarket bei 0,43 $ gekauft werden können, kostet das Paar 0,96 $ und zahlt bei identischer Auflösung 1 $. Der Brutto-Edge beträgt 0,04 $ pro Paar, bevor Kosten abgezogen werden.

Das gilt nur bei identischen Resolution-Regeln. Ein ähnlicher Titel genügt nicht.

Ein Schritt-für-Schritt-Beispiel für Prediction-Market-Arbitrage

1. Kontrakt prüfen: Bedingung, Outcome-Reihenfolge, Frist und Resolver zwischen Kuest und Polymarket vergleichen.
2. Ausführbare Bücher lesen: Best Bid, Best Ask und Größe beider Venues laden. Die Polymarket-Orderbook-API liefert Preis, Größe, Zeitstempel, Mindestgröße und Tick Size.
3. Hedge-Route wählen: Nur die verfügbare Menge hedgen, die nächste Preisstufe akzeptieren, eine komplementäre Route prüfen oder Kuest-Quotes reduzieren.
4. Nettoergebnis berechnen:

Nettoergebnis = Kuest-Erlös - Hedge-Kosten - Gebühren - Gas - Slippage
                - Kapital- und Inventarkosten

5. Jeden Status abgleichen: Accepted, Partial Fill, Cancel, Reject und Resting müssen in beiden Büchern verbucht werden.
6. Bis zum Settlement überwachen: Resolution, Disputes, Redemption und mögliche Abweichungen bleiben relevant.

Mirror-Märkte finden und Outcome-Token zuordnen

Matching nach Titel ist der gefährlichste Shortcut. Assymetrix zeigt, wie unterschiedliche Trader, Gebühren, Liquidität und Resolution-Regeln aus ähnlichen Überschriften verschiedene Instrumente machen.

Speichere für jeden Mirror mindestens:

{
  "source": "polymarket",
  "sourceConditionId": "0x...",
  "sourceYesTokenId": "...",
  "sourceNoTokenId": "...",
  "kuestConditionId": "0x...",
  "kuestYesTokenId": "...",
  "kuestNoTokenId": "...",
  "resolutionSource": "...",
  "closeTime": "...",
  "mappingStatus": "verified"
}

Die Kuest-Market-Details enthalten Mirror-Condition-IDs, Mirror-Token-IDs, Outcomes, Gebühren, Resolution-Quelle und Book-Preise. Ein Bot sollte bei unklarem Mapping, anderer Frist, fehlender Resolution-Quelle, pausiertem Markt oder zu geringer kompletter Hedge-Größe no trade zurückgeben.

Wie Shared Liquidity die Arbitrage verändert

Wenn kompatible Märkte dieselben Kuest-Outcome-Token-IDs verwenden, nutzen sie gemeinsame Orderbücher. Eine Order von einer Operator-Seite kann Flow von einer anderen Seite bedienen. Das erhöht Kapitaleffizienz und reduziert den Cold Start.

Es bedeutet aber auch, dass zwei Seiten desselben Kuest-Buchs keine unabhängigen Arbitrage-Legs sind. Der echte Edge kann aus externer Preisreferenz, Operator-Flow, Fee- oder Incentive-Economics, Inventory-Imbalance oder einer finanzierten Kampagne stammen.

Mehr über das Netzwerk steht im Kuest-Protokoll; konkrete Liquiditätsmandate findest du auf der Market-Maker-Seite.

Market-Maker-Inventar: Collateral, YES/NO und Settlement

Ein binärer Market Maker verwaltet typischerweise USDC-Collateral, YES-Inventar, NO-Inventar und externe Venue-Positionen. Das richtige Hedge-Leg hängt vom gesamten Balance Sheet ab, nicht nur vom letzten Trade.

Ein YES/NO-Paar derselben Bedingung besitzt zusammen einen Settlement-Wert von 1 $. Je nach Venue kann das Paar aus Collateral gemintet oder zurück in Collateral gemerged werden. Halte dabei physische Aktionen und Accounting getrennt: SELL YES bleibt im Orderlog SELL YES, auch wenn Settlement intern einen Merge nutzt.

Wie viel Edge bleibt nach Gebühren, Gas und Slippage?

Ein Midpoint-Spread ist kein ausführbarer Edge. Nutze Preis und Größe, die tatsächlich genommen werden können. Polymarket dokumentiert Spreads und CLOB-Market-Informationen.

Netto-Edge = Brutto-Payoff oder Spread
           - Gebühren aller Legs - Gas - Slippage
           - Failed-Fill-Kosten - Kapitalbindung
           - Hedge-Kosten - operativer Overhead

Die Kuest-Kampagnenvergütung ist eine eigene Revenue-Linie. Sie bezahlt eine definierte Liquiditätsleistung und sollte getrennt von Trading-P&L, Incentives, Bond-Kosten und Inventarverlusten modelliert werden.

Die wichtigsten Risiken bei Polymarket-Mirror-Arbitrage

Basisrisiko

Ein einzelner Satz in den Regeln kann den Payoff verändern. Prüfe Datenquelle, Zeitstempel, Frist, Resolver und Sonderfälle.

Execution-, Liquiditäts- und Latenzrisiko

Das günstige Leg kann verschwinden, bevor der Hedge ankommt. Top-of-Book-Größe reicht möglicherweise nicht für deine Position.

Adverse Selection

Ein Trader kann neue Information schneller verarbeitet haben als dein Bot. Ein Hedge reduziert dann nicht automatisch den Verlust.

Resolution-, Venue- und Betriebsrisiko

API-Ausfälle, Rate Limits, Wallet-Fehler, Rejected Orders, Stale Websockets, Disputes und verzögerte Auflösung gehören in Kill Switches und Reconciliation.

Rechtliches Risiko

Prediction Markets, Derivate und Market Making können je nach Land unterschiedlich reguliert werden. Hole eigene rechtliche, Compliance- und Steuerberatung ein.

Wie Kuest-Kampagnen Liquidität vergüten

Eine Kampagne kann Markt- oder Serien-Scope, Service-Zeitraum, Tiefe pro Seite, maximalen Spread, Coverage, Reward, Bond und externe Hedge-Verfügbarkeit definieren.

Der Escrow-Ablauf ist:

1. Sponsor hinterlegt Reward und erforderliche Protocol-Beträge.
2. Ein zugelassener Market Maker prüft die Terms und akzeptiert.
3. Falls nötig, wird ein Bond hinterlegt.
4. Der Maker stellt die vereinbarte Liquidität bereit.
5. Nach Service und Review kann eine Dispute-Periode greifen.
6. Nach Finalisierung wird die Maker-Allokation über pendingWithdrawals auszahlbar.

Escrow schützt das kommerzielle Mandat. Es garantiert weder Hedge-Fills noch Trading-Gewinn. Lies die Kuest-Dokumentation zur Market-Erstellung und Resolution, damit dein Modell Lifecycle und Attribution korrekt versteht.

Prediction-Market-Arbitrage-Bots und API-Infrastruktur

Ein professioneller Bot ist eine State Machine:

discover -> mapping prüfen -> Tiefe lesen -> Netto-Edge berechnen
         -> Collateral reservieren -> erstes Leg platzieren
         -> Fill bestätigen -> Hedge platzieren -> reconciliieren
         -> Settlement überwachen -> Inventar freigeben oder rebalancieren

Bausteine sind Market Discovery, Token-Mapping, Live Order Books, Edge-Berechnung, Sizing, Fill-Reconciliation, Inventory, Hedge Routing, Settlement-Monitoring, Alerts und Kill Switches. Die Polymarket-Market-Data-Dokumentation und Order-API sind gute Referenzen für die Venue-Seite.

Ein vorhandener Polymarket-Bot kann Polygon-Wallets, CLOB, Cancel-and-Replace und Risk Controls wiederverwenden. Validiere trotzdem Kuest-IDs, Shared-Book-Verhalten, Auth, Fees, Order-Semantik, Lifecycle und Kampagnenpflichten.

So startest du Market Making auf Kuest

1. Öffne die Kuest-Market-Maker-Seite und das Protokoll.
2. Lass die operative Wallet für Market-Maker-Kampagnen freischalten.
3. Prüfe offene Kampagnen nach Hedge-Verfügbarkeit, Spread, Tiefe und Dauer.
4. Validieren den Mirror und das externe Buch unabhängig.
5. Akzeptiere nur passende Terms und hinterlege den Bond, falls erforderlich.
6. Starte mit konservativer Größe und prüfe Order-, Fill- und Reconciliation-Pfade.
7. Finalisiere und withdraw nach Service- und Review-Periode.

Warum native Crypto-Market-Maker für Kuest wichtig sind

Kuest braucht keine Wallets, die Kapital nur parken. Wertvoll sind Desks, die binäre CLOBs quoten, YES/NO-Inventar verwalten, Basisrisiko erkennen, Teilfills behandeln, Polygon und USDC betreiben und ihre Systeme mit Kill Switches und sauberem Audit Log absichern.

Diese Fähigkeiten geben Operatoren vom ersten Tag an ein glaubwürdiges Orderbuch. Gleichzeitig können Market Maker neue Flow-Quellen aus Operator-Communities und finanzierte Mandate über ein gemeinsames Netzwerk erschließen.

Weiterführende Lektüre

• Kuest-Architektur: Operatoren, Shared Liquidity und Settlement
• Polymarket-Orderbuch
• Polymarket-Orders senden
• Cross-Venue-Arbitrage-Scanner von Assymetrix
• Prediction-Market-Arbitrage-Leitfaden
• Preduck: Cross-Venue-Hedging und Market Matching

FAQ: Prediction-Market-Arbitrage

Ist Polymarket-Arbitrage risikofrei?

Nein. Ein Spread kann vor der Ausführung verschwinden, und ähnliche Märkte können unterschiedlich auflösen. Auch ein YES/NO-Paar benötigt passende Regeln und vollständige Fills.

Was ist ein Polymarket-Mirror?

Ein Kuest-Markt, der mit einem ausgewählten Polymarket-Quellmarkt verbunden ist, damit ein Operator das Ereignis über seine eigene Marke anbieten kann. Mapping, Resolution und Liquidität müssen geprüft werden.

Wie funktioniert eine Polymarket-Hedge-Strategie?

Der Maker nutzt Polymarket, um durch Kuest-Quotes entstandenes Inventar auszugleichen: durch Kauf desselben Outcomes, des komplementären Outcomes oder eines vollständigen Paars. Die beste Route hängt von Kontrakt, Tiefe, Fees und Teilfills ab.

Welche IDs muss ein Arbitrage-Bot mappen?

Source- und Kuest-Condition-ID, YES- und NO-Token-IDs, Resolution-Quelle, Schlusszeit und Mapping-Status. Bei Unklarheit sollte der Bot nicht handeln.

Was ist MarketMakerEscrow?

Ein Polygon-Smart-Contract für Reward, Bond, Service, Review und Withdrawal von finanzierten Market-Maker-Kampagnen. Er garantiert keinen Trading-Gewinn.

Brauchen Kuest Market Maker eine Zulassung?

Ja. Kampagnen sind approval-basiert. Die Wallet wird vor der Annahme geprüft.

Garantiert Kuest Arbitrage-Renditen?

Nein. Kuest stellt Infrastruktur, Netzwerk, Daten und Escrow bereit. Pricing, Execution, Inventar, Hedge und Kapitalrisiko bleiben beim Market Maker.