Eine Ordersignatur erlaubt einen Handel zu bestimmten Bedingungen. Sie bedeutet nicht, dass er stattgefunden hat. Die API kann die Order annehmen, das Orderbuch einen Teil zusammenführen und die Abwicklungstransaktion trotzdem scheitern.
Dieser fünfte Artikel von So funktionieren Polymarket und Kuest verfolgt die Autorisierung hinter den verbundenen YES- und NO-Orderbüchern. Wir gehen durch die getrennten Systemebenen: was Teilnehmer signieren, was der Matching-Service durchsetzt und was die Blockchain tatsächlich aufzeichnet.
Beginne mit einer Anweisung und verfolge dann die Assets
Wir behalten unsere hypothetische Frage bei: „Wird Observatorium A für Stadt B am Datum C um 12:00 UTC mindestens 30.0°C veröffentlichen?“ Ihren YES-Token zu kaufen bedeutet, das bestimmte Ergebnis-Asset zu erwerben. Eine BUY-Order zu signieren autorisiert diesen Erwerb lediglich.
Wir verwenden einen gewöhnlichen binären Markt des Conditional Tokens Framework (CTF) und allgemeine Collateral-Einheiten. Mengenbeispiele setzen sechs Dezimalstellen, genügend Mittel und Berechtigungen sowie keine Gas- oder Finanzierungskosten voraus. Gebühren erscheinen gesondert, wo angegeben.
Die folgenden Erklärungen verwenden öffentliche Signaturstandards, öffentliche CTF-Exchange-Beispiele und hypothetische Assetbewegungen. Welche Wallets, Ordertypen und Gebühren ein Handelsplatz unterstützt, muss aus seiner aktuellen öffentlichen Integrationsdokumentation hervorgehen.
Drei Autorisierungen haben verschiedene Aufgaben
Eine Ordersignatur autorisiert eine bestimmte Handelsanweisung. API-Authentifizierung identifiziert einen berechtigten Anfragenden gegenüber einem Service. Eine Wallet-Batch-Signatur autorisiert ein separates Bündel von Walletaufrufen, etwa das Setzen einer Ausgabefreigabe.
Ein API-Zugangsnachweis identifiziert einen berechtigten Anfragenden gegenüber einem Service. Er ist nicht der private Schlüssel des Teilnehmers und ersetzt keine Ordersignatur. Polymarkets öffentlicher Wallet- und Authentifizierungsleitfaden bietet ein dokumentiertes Produktbeispiel.
Getrennte Objekte, getrennte Prüfungen. Ein Wallet-Batch hat eine eigene Nonce und Frist. Diese Felder werden nicht Teil der Handelsorder.
EIP-712 definiert Hashbildung und Signatur strukturierter Nachrichten. Seine Domain kann eine Anweisung an Blockchain, Anwendungsname, Version und prüfenden Vertrag binden. So validiert eine für eine Domain bestimmte Signatur nicht unter einer anderen.
Der öffentliche CTF-Exchange-V2-Signaturcode illustriert eine anwendungsspezifische EIP-712-Domain. Name und Version einer Domain gehören zum signierten Kontext. Sie beweisen nicht, dass eine andere Exchange dieselbe Nachricht akzeptiert. Grenzen einer Wiederverwendung hängen auch vom Zustand und den Prüfregeln des tatsächlichen Vertrags ab.
In den Mengen steckt der Preis
In der öffentlichen Orderdefinition des CTF Exchange V2 enthält die signierte Anweisung unter anderem Token, Seite, Maker- und Takermengen sowie Kontoidentitäten. Die Signatur autorisiert genau diese Nachricht, nicht irgendeinen später angezeigten Oberflächenpreis.
maker bezeichnet hier das Assets liefernde Konto, auch wenn seine Order sofort Liquidität nimmt. Dieser Feldname unterscheidet sich von der Handelsrolle Maker, bei der eine Order zunächst im Buch liegt, bevor eine andere dagegen handelt.
Bei BUY ist makerAmount das angebotene Collateral und takerAmount die gewünschte Anteilsmenge. Eine Order mit 60 für 100 YES codiert ein Limit von 60 ÷ 100 = 0.60. Bei SELL mit 100 YES für 60 lautet der Preis dagegen takerAmount ÷ makerAmount.
Es gibt kein unabhängiges signiertes Preisfeld, das dieses Verhältnis überschreibt. Den angezeigten Preis zu ändern, ohne die entsprechenden Mengen neu aufzubauen und zu signieren, verändert die autorisierten Bedingungen nicht.
Ein Zeitstempel kann die Erstellung einer Order beschreiben, ohne eine durchsetzbare Ablaufzeit zu sein. Eine Integration muss signierte Felder von Serviceanweisungen unterscheiden und ihre Bedeutung in der aktuellen öffentlichen Orderspezifikation prüfen.
Die Prüfung entscheidet über die Aufnahme ins Orderbuch
Prüfe vor der Orderaufgabe das gewünschte Asset, Preislimit, Menge, Konto und den unterstützten Ordertyp. Clientprüfungen und eine API-Eingangsbestätigung ersetzen keine erfolgreiche Vertragsabwicklung.
Ein Preistick ist der zulässige Abstand zwischen quotierten Preisen. Prüfe vor der Signatur die aktuellen veröffentlichten Marktspezifikationen. Clientprüfung, Serviceantwort und Vertragsregel belegen unterschiedliche Dinge. Ein angezeigtes Minimum allein beweist keine On-Chain-Beschränkung.
Mittel und Berechtigungen sind verschiedene Prüfungen: BUY braucht nutzbares Collateral und eine ausreichende Ausgabefreigabe für den Abwicklungsvertrag; SELL braucht Ergebnis-Token und Übertragungsfreigabe. Eine Signatur allein liefert beides nicht. Eine Bestandsprüfung bei Aufnahme friert auch nicht jede spätere Kontoänderung ein.
Post-only bedeutet, dass eine Anweisung liegendes Interesse hinzufügen statt sofort Liquidität nehmen soll. Prüfe dokumentierte Kombinationen und Ablehnungsverhalten des Handelsplatzes. Die Bezeichnung allein definiert nicht jede Implementierung.
Die Gültigkeitsanweisung oder Time-in-force bestimmt, wie der Matching-Service mit der unausgeführten Menge umgeht:
- GTC — good till cancelled: zulässige Restmenge bis zur Stornierung im Buch lassen.
- GTD — good till date: bis zu einer bestimmten Ablaufzeit im Buch liegen lassen.
- FAK — fill and kill: verfügbare Menge sofort ausführen und den Rest verwerfen.
- FOK — fill or kill: die Ausführbarkeit der gesamten gewünschten Menge verlangen oder nichts ausführen.
Eine ablaufende Serviceorder und eine signierte Vertragsfrist sind unterschiedliche Zusagen. Prüfe, wo die aktuelle Spezifikation den Ablauf durchsetzt und was mit bereits gesendeten Transaktionen geschieht. Ein Feld in einer Anfrage begründet allein keine Vertragsgarantie.
Ein Match braucht weiterhin erfolgreiche Abwicklung
Betrachte diese didaktischen Schritte: signiert → angenommen/im Buch → zusammengeführt → gesendet → bestätigt. Eine Order kann vor der Aufnahme abgelehnt werden; eine angenommene Order kann mehrere Teilmatches und Abwicklungstransaktionen erzeugen. Diese Bezeichnungen erklären Verantwortlichkeiten statt einer allgemeingültigen API-Aufzählung.
Ein Teilmatch lässt Menge für spätere Matches übrig, soweit die Gültigkeitsanweisung das erlaubt. Eine gescheiterte Abwicklung verlangt eine Abstimmung vor jedem neuen Versuch.
Der öffentliche CTF-Exchange-V2-Vertrag zeigt autorisiertes Matching und Vertragsprüfungen vor Assetbewegungen. Die direkten, Erzeugungs- und Zusammenführungsbeispiele in Artikel 4 erklären die möglichen Bewegungen und ihren Finanzierungsbedarf.
Die Transaktion ist atomar: Schlägt eine erforderliche Übertragung oder Prüfung fehl und setzt zurück, werden ihre Zustandsänderungen rückgängig gemacht. Das hebt keine andere bereits erfolgreiche Transaktion auf. Eine zurückgesetzte Transaktion kann dennoch Gas verbrauchen.
Ein Transaktionshash identifiziert eine gesendete Transaktion, keinen erfolgreichen Kauf. Prüfe ihren Beleg und den vom gewählten Netzwerk geforderten Bestätigungszustand. Bis das Ergebnis bekannt ist, sollte die Oberfläche diese Unsicherheit zeigen statt gelieferte Assets zu melden.
Halte in der Betreiberoberfläche Orderkennung, zusammengeführte Menge und Transaktionsreferenz getrennt fest. Scheitert eine Transaktion oder bleibt ihr Ergebnis unklar, stimme den tatsächlichen Ausgang vor einem neuen Versuch ab. Eine geänderte lokale Beschriftung bewegt keine Assets.
Teilausführungen verbrauchen das angebotene Asset
Die liegende BUY biete 60 Collateral für 100 YES, und eine erste Ausführung erhalte 40 YES zu genau 0.60. Ohne Gebühren verbraucht sie 24 Collateral. Es bleiben 36 Collateral signierte Kapazität, entsprechend 60 YES zu demselben Preis.
Eine liegende SELL mit 100 YES für 60 Collateral verbraucht bei dieser Ausführung 40 YES und erhält 24 Collateral. Ihre übrige Makermenge beträgt 60 Anteile, nicht 36 Collateral. Beide Orders haben noch 60 YES handelbar, aber ihre On-Chain-Restmengenzähler verwenden verschiedene Assets.
Dieselbe Ausführung von 40 Anteilen, verschiedene Zählereinheiten. Genaue Ausführung zum Limitpreis; Gebühren ausgeschlossen.
Die öffentliche CTF-Exchange-V2-Arithmetik arbeitet mit ganzzahligen Basiseinheiten. Im folgenden proportionalen Modell mit Abrundung ist die erhaltene Menge gleich gelieferte Menge × signierte Takermenge ÷ signierte Makermenge, abgerundet. Eine genaue Abstimmung braucht die Rundungsregeln des tatsächlichen Wegs.
Wer etwa 1.000001 Anteile einer signierten Order über 3 Anteile für 1.8 Collateral verkauft, berechnet 1,000,001 × 1,800,000 ÷ 3,000,000, abgerundet auf 600,000 Collateral-Basiseinheiten. Kleine Ausführungen und Gebühren brauchen deshalb die Rundungsregeln der Implementierung. Gerundete Anzeigepreise zu multiplizieren reicht für eine genaue Abstimmung nicht aus.
Gebühren brauchen eine eigene Rechnung
Angenommen, 100 YES werden direkt für 60 Collateral gekauft und jeder Teilnehmer zahlt hypothetisch 0.60 Gebühr. Der Käufer benötigt 60.60 Collateral, der Verkäufer erhält 59.40. Die verbleibenden 1.20 sind die Gesamtgebühren. Damit ist der gesamte Mittelabfluss des Käufers erklärt.
Hypothetische Gebühren, kein aktueller Satz. Käuferabfluss 60.60 = Verkäufererlös 59.40 + Gesamtgebühren 1.20; 100 vorhandene YES gehen an den Käufer.
In diesem ausdrücklichen Beispiel wird die BUY-Gebühr zum Mittelbedarf des Käufers addiert und die SELL-Gebühr vom Erlös abgezogen. Tatsächliche Belastungen, Empfänger und Rundung sind für den gewählten Handelsplatz und Weg zu prüfen. Das Beispiel ist kein Gebührenverzeichnis.
Stornierung hat eine Grenze
Die Aufforderung, eine offene Order zu entfernen, betrifft ihre verbleibende unausgeführte Menge. Sie macht abgeschlossene Ausführungen nicht rückgängig. Behandle Stornierungsbestätigung und eine noch offene Abwicklungstransaktion als getrennte Datensätze. Prüfe beide vor der Wiederverwendung von Mitteln.
Wurde die Abwicklung bereits gesendet, kann eine spätere Stornierung im Orderbuch deren Stopp nicht zusagen. Prüfe das Transaktionsergebnis, bevor du die Assets als weiterhin verfügbar ansiehst, besonders bei einer bereits teilweise ausgeführten Order.
Die Stornierung des Rests und die Abwicklung eines früheren Matches können beide stattfinden. Keine verzögerte Schutzmaßnahme macht eine erfolgreiche Transaktion rückgängig.
Eine umfassendere Kontobeschränkung ist nicht dasselbe wie die Stornierung einer Order. Wiederherstellungskontrollen können verschiedene Reichweiten, Fristen und Zuständigkeiten haben. Nutze den veröffentlichten Vertrag und die Produktdokumentation des tatsächlichen Kontos, statt jede Kontrolle als sofortigen Stopp zu verstehen.
Die Deposit Wallet hat eine gesonderte Pause und Notfallwartezeit vor Notfallabhebungen oder Freigabewiderrufen. Die Walletpause allein deaktiviert in diesem Code weder Batchausführung noch Signaturprüfung. Sie ist kein sofortiger Handelsschalter.
Versionsnamen definieren keine Integration
Polymarkets ältere CTF-Order signierte taker, expiration, nonce und feeRateBps. Die separate CTF-Exchange-V2-Order entfernt diese Felder und ergänzt timestamp, metadata und builder. Der Preis bleibt ein Mengenverhältnis.
Das V2-Repository entfernt außerdem fillOrder/fillOrders und behält Operator-Matching über matchOrders. Dieser CTF Exchange V2 ist von der Protocol-V2-Positionsarchitektur in polymarket-v2-external zu unterscheiden. Kuest übernimmt Änderungen keines der beiden Repositorys automatisch.
Ein fehlendes Ablaufdatum in einer Vertragsstruktur bedeutet nicht, dass ein Produkt keine ablaufenden Orders hat. Polymarkets aktuelle Lebenszyklusdokumentation beschreibt GTD auf Produktebene; der Positionsleitfaden unterscheidet CTF- und Protocol-V2-Register. Prüfe vor einer Integration den Weg des tatsächlichen Markts.
Was ein Kuest-Betreiber offenlegen sollte
Kuests öffentlicher Betreiberleitfaden trennt Betreiberanwendung und gemeinsame Services. Lege für Teilnehmer den unterstützten Kontoablauf, eine vollständige Gebührenschätzung und getrennte Zustände für Annahme, Match und Bestätigung offen. Das sind beobachtbare Produktanforderungen, keine Implementierungsdetails.
Kuests öffentliche Gebührendokumentation beschreibt die Beteiligung von Betreibern an Handelsgebühren und eine konfigurierbare Aufteilung mit Affiliates. Die Verteilung einer Gebühr ist etwas anderes als eine zusätzliche Belastung des Handelsnominalwerts. Erkläre anhand der aktuellen öffentlichen Konfiguration und Abwicklungsdatensätze, was ein Teilnehmer zahlt.
Für einen Betreiber mit eigener Marke ergibt sich eine konkrete Integrationsentscheidung: die richtige Builderidentität bewahren, die tatsächliche Gesamtbelastung anzeigen und deren Verteilung mit Abwicklungsdatensätzen abstimmen. Ein Code oder Markenfrontend allein garantiert weder Aufnahme noch Gebührenanspruch oder Umsatz.
Starte mit Kuest deinen eigenen Prognosemarkt mit verständlichen Ausführungsregeln: vorgesehene Rechtsräume der Zielgruppe, genaue Marktregeln und Auflösungsweg, benötigte Handelsmengen, unterstützter Walletablauf, Gebührenangaben und getrennte Zustände für Annahme, Match und Bestätigung.