Die Website eines Prognosemarkts ist der Eingang zu einem System mit mehreren Aufgaben. Die Oberfläche präsentiert den Markt, das Handelssystem führt Orders zusammen, Verträge wickeln Vermögensbewegungen ab und Datenservices machen die Ergebnisse nachvollziehbar. Ein Orakel liefert die spätere Antwort des Markts über das konfigurierte Auflösungsverfahren.
Diese Aufgaben finden an verschiedenen Stellen statt. Ein Klick, eine angenommene Order und ein abgewickelter Handel sind unterschiedliche Meilensteine. Wer die Grenzen versteht, erkennt, warum ein Markt sichtbar sein kann, obwohl kein Handel möglich ist, oder warum eine abgeschlossene Transaktion erst später im Portfolio erscheint.
Dies ist der zweite Artikel von So funktionieren Polymarket und Kuest. Beginne mit der tatsächlichen Bedeutung eines Prognosemarktpreises, wenn Preise und Auszahlungen neu für dich sind.
Vier Ebenen, vier Verantwortlichkeiten
| Ebene | Aufgabe |
|---|---|
| Oberfläche | Fragen, Regeln und Kontosteuerung darstellen |
| Handelssystem | Orders prüfen und passendes Handelsinteresse finden |
| Verträge | Asset- und Berechtigungsregeln des gewählten Wegs durchsetzen |
| Datenservices | Metadaten, Guthaben und Aktivitäten für Anwendungen aufbereiten |
Polymarkets API-Übersicht spiegelt diese Trennung wider: Gamma dient der Marktsuche, CLOB den Orders und dem aktuellen Marktzustand, die Data API den Konto- und Marktaktivitäten. WebSockets liefern Aktualisierungen; sie ersetzen die zugrunde liegenden Abwicklungsregeln nicht.
Eine Seite ist keine Positionskennung
Ein Ereignis gruppiert verwandte Märkte für die Darstellung. Ein binärer Markt stellt eine bestimmte auflösbare Frage und bietet getrennte YES- und NO-Ergebnisse. Ein Ereignis kann mehrere Märkte enthalten. Seine Seitenadresse reicht deshalb nicht aus, um eine Order festzulegen. Siehe Polymarkets Markt- und Ereignismodell.
Im Conditional Tokens Framework, kurz CTF, kennzeichnet die Frage-ID die Eingabe für die Auflösung. Die Bedingungs-ID wird aus Orakeladresse, Frage-ID und Anzahl der Ergebnisslots abgeleitet. Die ID einer Ergebnisposition hängt zusätzlich von Collateral und Collection-Pfad ab. Diese Kennungen lassen sich nicht sicher gegeneinander austauschen.
Eine Gruppierungsübersicht, keine Hashformel. Wähle den genauen Markt und das Ergebnis, bevor du dessen Orderbuch liest oder eine Order aufgibst.
Polymarkets Leitfaden zu On-Chain-Daten unterscheidet diese CTF-Ableitungen von den Kennungen des Protocol V2. Ein identischer Titel auf einer anderen Website beweist nicht, dass es dasselbe Asset ist.
Verfolge eine Order durch das System
Zunächst findet die Oberfläche einen Markt und erhält seine Ergebniskennungen und Handelseinstellungen. Der Client bereitet eine Order vor und der zuständige Unterzeichner autorisiert ihre Bedingungen. Eine Order zu signieren ist nicht dasselbe wie eine Blockchaintransaktion zu senden.
Die signierte Anweisung erreicht das zentrale Limitorderbuch, kurz CLOB. Der Service prüft die Zulässigkeit und sucht passende Orders. Eine zugelassene Order kann offen bleiben, wenn sie nicht sofort ausgeführt werden kann. Ein Match ist eine Handelsvereinbarung nach den Regeln des Handelssystems, noch kein Nachweis gelieferter Assets.
Danach folgt die Abwicklung. Ein Ausführungsservice sendet eine Transaktion an die betreffenden Verträge auf Polygon. Der Abwicklungsweg prüft den autorisierten Handel und aktualisiert die Assets bei erfolgreicher Ausführung. Eine gescheiterte Transaktion wird nicht zum erfolgreichen Kauf, nur weil die API zuvor ein Match gemeldet hat.
Durchgezogene Pfeile verfolgen die Anweisung zur Abwicklung. Gestrichelte Pfeile zeigen aufgezeichnete Daten auf dem Rückweg zur Oberfläche; sie bewegen kein Collateral.
Polymarket dokumentiert den Orderlebenszyklus und fordert Integrationen gesondert dazu auf, die Abwicklung der Ausführung abzuwarten, bevor die entstandene Position geprüft wird. Transaktionsaufnahme und erforderlicher Bestätigungszustand sind wichtig; eine Order-ID allein genügt nicht.
Schließlich verarbeiten Indexer die aufgezeichneten Änderungen und APIs stellen aktualisierte Ansichten bereit. Die Oberfläche kann nun Position und Aktivität anzeigen. Diese Phasen brauchen eigene Statusmeldungen statt eines einzigen mehrdeutigen „Erfolgreich“.
Verträge bilden eine Familie, keinen einzelnen Kasten
Ein CTF-basiertes System verteilt Verantwortlichkeiten auf mehrere Vertragsfamilien. Die folgenden Namen beschreiben Aufgaben. Die genauen Verträge und Berechtigungen hängen vom jeweiligen Weg ab.
Eine Übersicht der Verantwortlichkeiten. Die Felder behaupten nicht, dass jede Transaktion alle fünf Familien aufruft.
| Familie | Aufgabe |
|---|---|
| Wallets, Factories und Upgrade-Infrastruktur | Assets halten und Eigentums-, Signatur- und Implementierungsregeln anwenden |
| CTF Exchange oder ein Handelsweg für Negativrisiko | Die zutreffenden zusammengeführten Orders prüfen und abwickeln |
| Conditional Tokens | CTF-Ergebnisbestände führen und Aufteilen, Zusammenführen und Einlösen ermöglichen |
| Orakeladapter und Auflösungswege | Eine akzeptierte Antwort mit der für eine Bedingung aufgezeichneten Auszahlung verbinden |
| Unterstützung für Gebühren, Belohnungen und Escrow | Zusätzliche Buchungs-, Anreiz- oder Finanzierungsabläufe bedienen, soweit konfiguriert |
Abwicklung und Auflösung beantworten verschiedene Fragen. Die Abwicklung prüft, ob dieser Handel Assets bewegen darf. Die Auflösung bestimmt, welche Auszahlung aus den Marktregeln folgt. Polymarkets Auflösungsdokumentation unterscheidet derzeit UMA-basierte Märkte von Chainlink-TWAP-Aufwärts-/Abwärtsmärkten. Ein Matching-System entscheidet dieses Ergebnis nicht durch die Wahl eines Handelspreises.
Die Version zählt. Polymarket dokumentiert derzeit CTF- und Protocol-V2-Positionssysteme. Protocol V2 nutzt PositionManager, CTF dagegen Conditional Tokens. Das Vertragsverzeichnis führt unterschiedliche Abwicklungskomponenten auf. „Exchange V2“ und „Protocol V2“ sind nicht austauschbar. Bestimme Marktversion, Bestandsregister und Ausführungsweg immer gemeinsam.
Daten machen das Register nutzbar, können aber hinterherhinken
Ein Indexer macht Vertragsereignisse zu abfragbaren Datensätzen. Eine API kann diese mit Marktmetadaten, Preisen oder Berechnungen verbinden. Das sind nützliche Anwendungsdaten, deren Aktualisierung aber von einem Transaktionsbeleg oder einem aktuellen Orderfeed abweichen kann.
Polymarkets Leitfaden zu On-Chain-Daten beschreibt Übertragungs- und Handelsausführungsereignisse. Diese Datensätze enthalten nicht jede offene Off-Chain-Order. Ebenso wird ein Indexer nicht zum aktuellen Orderbuch, nur weil er „Orderbook-Subgraph“ heißt. Eine aktuelle Quote und eine historische Ausführung gehören zu unterschiedlichen Datensätzen.
Wirkt ein Portfolio veraltet, vergleiche seinen Aktualisierungszeitpunkt mit der Transaktion und dem zuständigen Bestandsregister. Verschwindet eine Quote, prüfe das aktuelle Orderbuch. Das sind verschiedene Untersuchungen. Ein aktualisierter Katalog beweist weder eine unausgeführte Order noch fehlende Mittel.
Ein Relayer hilft beim Senden von Transaktionen, beseitigt aber keine Abhängigkeiten
Ein Relayer kann unterstützte Walletaktionen wie Bereitstellung oder Freigaben senden. Polymarkets Walletdokumentation beschreibt gesponserte Aktionen, bei denen das Konto für diese Aufrufe keinen nativen Gas-Token halten muss. Gas wird weiterhin verbraucht; die Kosten werden an anderer Stelle bezahlt.
Ein Wallet-Relayer und die Matching- und Abwicklungsservices des Handelssystems haben unterschiedliche Aufgaben. Verfügbarkeit, unterstützte Aufrufe und Sponsoringregeln sind wichtig. Nimm weder an, dass jeder Handel über einen Wallet-Relayer läuft, noch dass Sponsoring etwas über Verwahrung, Upgradebefugnisse oder die Korrektheit eines Orakels beweist.
Kuests Unterschied: Die Oberfläche kann wechseln, die Infrastruktur gemeinsam bleiben
Kuests öffentlicher Architekturleitfaden trennt Marke und Katalog des Betreibers von der gemeinsamen Handelsinfrastruktur. Betreiber können Märkte für ihre Zielgruppen auswählen und dabei kompatible gemeinsame Ausführungsservices nutzen.
Gemeinsame Ausführung erfordert passende Services, Netzwerk und Assets. Eine getrennte Marke schafft oder garantiert keine Liquidität.
Zwei Websites mit eigener Marke können mit denselben Kuest-Services und Assets gemeinsames Handelsinteresse zeigen und dennoch unterschiedliche Kataloge präsentieren. Für einen Betreiber bedeutet das: Ausführungsinfrastruktur wiederverwenden und gleichzeitig ein gezieltes Erlebnis für die eigene Zielgruppe gestalten.
Der Betreiber präsentiert den Markt den Händlern; ein Market Maker stellt über Orders Handelsinteresse bereit. Diese Teilnehmerrollen sind von den Services getrennt, die Trades zusammenführen und abwickeln. Einen Markt anzulegen schafft für sich genommen weder bereite Gegenparteien noch ausführbare Mengen.
Gemeinsame Kuest-Services vereinigen Kuests Orderbuch nicht mit dem von Polymarket. Eine gespiegelte Frage macht Bestände nicht zwischen Handelsplätzen übertragbar.
Die Vertragsfamilien oben erklären Verantwortlichkeiten, kein vollständiges Bereitstellungsinventar. Prüfe vor dem Betrieb das tatsächliche Netzwerk, Vertragsadressen, veröffentlichten Code, Berechtigungen und das unterstützte Positionssystem. Ein Audit des Ursprungsprojekts deckt eine andere Bereitstellung oder eigene Änderungen nicht automatisch ab.
Für Betreiber ist die hilfreiche Prüfung konkret: Welche Marktassets zeigt diese Website, welche Services nehmen ihre Orders an, welche Verträge wickeln sie ab und wie aktuell sind die angezeigten Datensätze? Eine neue Marke sollte diese Antworten leichter auffindbar machen.
Möchtest du dieses Erlebnis für deine Zielgruppe aufbauen? Erstelle deinen eigenen Prognosemarkt mit Kuests geführter Einrichtung.