„Werden 30 Grad erreicht?“ lässt mehrere unterschiedliche Trades zu. Die gerundete Prognose einer Wetter-App, die Messung einer Station und ein später veröffentlichter amtlicher Bericht können voneinander abweichen. Vor dem Kauf von YES oder NO muss der Markt festlegen, welcher Wert die Auszahlung bestimmt.
Dieser sechste Artikel von So funktionieren Polymarket und Kuest macht daraus eine prüfbare Regel und verfolgt ihre Belege durch die getrennten Systemebenen. Eine lesbare Seite, festgehaltene Auflösungsbytes und ein zugängliches Metadatendokument beweisen jeweils etwas anderes.
Formuliere die Frage, bis zwei Leser dieselbe Antwort erhalten
Wir behalten das fiktive Observatorium A, Stadt B und Datum C bei. „Um 12:00“ muss Beobachtungszeit oder Veröffentlichungsfrist bezeichnen; das sind unterschiedliche Ereignisse. Formuliere den Titel so: „Wird die Beobachtung von Observatorium A für Stadt B am Datum C um 12:00 UTC mindestens 30.0°C betragen?“ Lege anschließend die Belege fest:
Verwende die offizielle CSV mit Tagesbeobachtungen von Observatorium A, Station B-01, für Datum C. Lies das Lufttemperaturfeld in Grad Celsius für den Datensatz mit Zeitstempel 12:00:00 UTC. Verwende die neueste offizielle Fassung, die am Datum C bis 13:00:00 UTC verfügbar ist, einschließlich einer genau zu diesem Zeitpunkt veröffentlichten Korrektur. Vergleiche den veröffentlichten Zahlenwert direkt mit 30.0; runde ihn nicht erneut. Ein gültiger Wert von mindestens 30.0 bedeutet YES, ein gültiger niedrigerer Wert NO. Ignoriere Prognosen, andere Stationen und spätere Korrekturen. Ist der Datensatz zu diesem Stichtag zurückgezogen, fehlt widersprüchlichen Datensätzen eine maßgebliche Versionsreihenfolge oder ist kein gültiger Datensatz verfügbar, verwende das festgelegte Ergebnis für nicht verfügbare Daten.
Ersetze in einem realen Markt jeden fiktiven Namen und jedes Datum durch genaue Quellen-URL, Stationskennung, Kalenderdatum und Felddefinition. „Offizielle Website“ allein lässt Leser zwischen Seiten, Spiegeln und Überarbeitungen wählen. Auch eine Ersatzquelle braucht eine festgelegte Rangfolge, sonst entsteht nach Bekanntwerden des Ergebnisses eine zusätzliche Wahlmöglichkeit.
Hier bedeutet 29.96 NO, selbst wenn eine App 30.0 anzeigt. Eine Korrektur von 29.9 auf 30.1 vor dem Stichtag bedeutet YES; dieselbe spätere Korrektur ändert die ausgewählte Beobachtung nicht. Gleichheit ist ausdrücklich YES. An der Schwelle bleibt somit kein ungeklärter Gleichstand.
Die Beobachtungszeit wählt den Datensatz. Der Stichtag wählt dessen Fassung. Die Auszahlungsregel behandelt fehlende Belege.
Das Ergebnis für nicht verfügbare Daten muss zum gewählten Vertragsweg passen. Für dieses Lehrbeispiel setzen wir einen gewöhnlichen binären Adapter mit UNKNOWN voraus: Bei YES zahlt YES eine Collateral-Einheit und NO null, bei NO umgekehrt und bei UNKNOWN jeweils die Hälfte. Das ist eine ausdrückliche Modellannahme, keine allgemeine Stornierungsregel oder NegRisk-Auszahlungsrichtlinie.
Eine halbe Einheit je Token erstattet nicht dessen Kaufpreis. Wer 0.80 für YES bezahlt hat, erhält bei diesem angenommenen Ergebnis 0.50. Die Aufteilungs- und Einlösungsmechanik bestimmt die Zahlung; die Regeln bestimmen, welches unterstützte Ergebnis gemeldet werden sollte.
Quellenfrist, Handelsschluss und Auflösungszeit haben verschiedene Zwecke. Die erste wählt Belege aus, der zweite steuert die Orderaufnahme, die dritte zeichnet ein Ergebnis auf. Orders könnten zum Beispiel um 11:55 UTC enden, während zulässige Korrekturen bis 13:00 offen bleiben. Die Auflösung kann später erfolgen. Der Betreiber muss den Handel separat konfigurieren; eine verzögerte Transaktion verlängert den Belegstichtag nicht.
Verfolge zwei Arten von Belegen
Ein Markt braucht eine definierte Auflösungsfrage und lesbare Begleitinformationen. Ancillary data bezeichnet die zusätzlichen Fragebytes einer bestimmten Orakelintegration. Beschreibende Metadaten können auch Bilder, Bezeichnungen und Links enthalten. Beides hat unterschiedliche Zwecke und darf nicht als austauschbare Festlegung behandelt werden.
Der öffentliche Polymarket-CTF-Adapter zeigt beispielhaft Fragedaten mit festgelegter Codierung. Eine Bindung neu zu berechnen verlangt genau diese Codierung, nicht einen optisch ähnlichen Absatz. Prüfe die veröffentlichte Schnittstelle der gewählten Bereitstellung, statt ein Beispiel über Adapterfamilien hinweg zu verallgemeinern.
Die festgehaltene Frage und ein externes Dokument ermöglichen unterschiedliche Prüfungen. Eine Referenz allein beweist weder Integrität noch Verfügbarkeit.
Kuests öffentlich verifizierter Conditional-Tokens-Vertrag zeichnet einen Ersteller und eine externe Metadatenreferenz auf. Eine Referenz lokalisiert Informationen. Sie beweist nicht allein, dass ein Dokument verfügbar, unveränderlich oder mit der ursprünglichen Auflösungsfestlegung identisch ist. Rufe die Dokumente ab und vergleiche sie mit den aufgezeichneten Fragebelegen.
Kuests öffentliche Dokumentation zur Markterstellung beschreibt die unterstützte Produktschnittstelle. Ein hochgeladenes Dokument, eine vorbereitete Bedingung und eine handelbare Listung sind getrennte Beobachtungen. Bestätige die passenden Datensätze, statt alle drei aus einer Erfolgsanzeige abzuleiten.
Ähnlich aussehende Kennungen haben unterschiedliche Aufgaben
Ein Slug lokalisiert eine Seite. Eine Frage-ID kennzeichnet eine Frage nach dem Schema ihres Adapters. Eine Bedingungs-ID kombiniert in der öffentlichen CTF-Konstruktion Orakel, Frage-ID und Ergebnisanzahl. Die genauen Eingaben zählen. Ähnlicher Seitentext beweist keine identischen Bedingungen.
Eine Positions-ID kennzeichnet das gehaltene und gehandelte Asset. Bei CTF hängt ihre Ableitung auch vom Collateral und der Collection der Ergebnismenge ab. Gleiche Titel oder Slugs belegen keine identischen Assets. Die Erstelleradresse hält Zuordnung und bestimmte Berechtigungen fest; die externe Metadatenkennung lokalisiert beschreibenden Inhalt. Keine ersetzt Bedingungs- oder Positions-ID.
Selbst „Frage-ID“ bezeichnet keine universelle Codierung. In Polymarkets bestimmter NegRiskIdLib teilt eine Frage die ersten 31 Bytes ihrer Markt-ID und nutzt das letzte Byte für den Frageindex. Wende diese Regel nur auf diese Adapterfamilie an, nicht auf jede Orakelfrage.
Das Feld metadata einer signierten Handelsorder ist ein anderes Objekt. Die öffentliche CTF-Exchange-V2-Definition enthält etwa bytes32 metadata auf Orderebene. Das beweist nicht, dass die Signatur das angezeigte Marktdokument bindet.
Eine nachvollziehbare Änderung bleibt eine Änderung
Kuests Conditional-Tokens-Erweiterung führt Bedingungsersteller und aktuelle externe Metadatenreferenz. Ersteller oder CTF-Administrator können diese Referenz ersetzen. Jeder erfolgreiche Aufruf erhöht einen Zähler und gibt Bedingungs-ID, alte und neue Referenz sowie Änderungsadresse aus.
Die geprüfte Funktion friert Änderungen bei der Auflösung nicht ein und prüft nicht, ob eine Ersatzzeichenfolge auf verfügbaren, nicht leeren Inhalt verweist. Eine unveränderte Bedingungs-ID bedeutet daher nicht, dass ihre aktuell angezeigte Beschreibung niemals geändert wurde. Eine Aktualisierung könnte auch nur eine Belegquelle ergänzen oder ein Bild korrigieren. Vergleiche die tatsächlichen Dokumente, bevor du eine veränderte Aussage annimmst.
Eine Referenzänderung kann ein Dokument ergänzen oder seine Beschreibung ändern. Das Ereignis zeigt, wer den Verweis geändert hat; vergleiche die Inhalte.
Ein geänderter Verweis schreibt ursprüngliche Fragebytes nicht um und gewährt kein neues Auszahlungsmelderecht. Die CTF-Meldefunktion leitet die Bedingung mit dem Aufrufer als Orakel ab. Adapter und konfigurierter Auflösungsweg bestimmen, wie das Ergebnis die Funktion erreicht. Die Erlaubnis zur Metadatenbearbeitung ist eine separate Befugnis.
Version A nenne 30.0°C und Version B 31.0°C. Ein Historienereignis macht den Austausch sichtbar. Es belegt nicht, dass 31.0 zur legitimen Schwelle wurde. Vergleiche beide Fassungen mit den ursprünglichen Ancillary-Bytes und der geltenden Klarstellungsrichtlinie, bevor du die Änderung auslegst.
Klarstellungen brauchen einen Urheber und eine Regel
Polymarket hält Fragen bereits On-Chain fest. Der UMA-CTF-Adapter in der genannten Version hasht und speichert erweiterte Ancillary Data. Sein Bulletin Board zeichnet zugeordnete Aktualisierungen auf. Das sind bestimmte CTF-Adaptermechanismen, keine Aussage über die ABI jedes aktuellen Polymarket-Wegs.
Eine Klarstellung braucht außerdem einen identifizierbaren Urheber und eine anwendbare Regel. Im öffentlichen Polymarket-Beispiel überschreibt ein zugeordneter Beitrag die ursprünglichen Ancillary Data nicht. Behandle eine beliebige Aussage über eine Frage nicht als offizielle Änderung.
Polymarkets aktuelle Auflösungsdokumentation verlangt, dass Klarstellungen die grundlegende Absicht bewahren. Eine umbenannte CSV-Spalte zu identifizieren kann Belege präzisieren; die Schwelle von 30.0 auf 31.0 zu ändern verändert die Aussage. Ein Zeitstempel beweist den Aufzeichnungszeitpunkt, nicht die legitime Befugnis einer Aussage.
Prüfe den Weg vom Verweis zur Anzeige
Eine praktische Prüfung folgt den Belegen der Reihe nach:
- Bestimme die Bereitstellung. Halte Netzwerk, Vertragsadressen, Adapterfamilie und eine Blockreferenz fest. Beschaffe Erstellungsbeleg, ursprüngliche Fragebytes, Orakelidentität, Ersteller und Bedingungs-ID.
- Berechne die passenden Kennungen neu. Nutze Codierung, Initialisiererbehandlung und Ergebnisanzahl dieser Implementierung. Prüfe Positions-IDs gegen das tatsächliche Collateral und die Ergebniszuordnung.
- Verfolge die Metadatenhistorie. Lies ursprüngliche und aktuelle Referenz, Zähler und Änderungsprotokolle. Rufe Original- und Ersatzdokumente ab und vergleiche Änderungen und Änderungsadressen.
- Prüfe Integrität und Verfügbarkeit getrennt. Validiere Inhalte nach dem tatsächlichen Transaktions- oder Bindungsschema des Speichersystems. Bewahre genaue abgerufene Bytes und Herkunft. Eine aufgezeichnete Referenz kann kein Dokument bereitstellen, das niemand abrufen kann.
- Vergleiche die Teilnehmeransicht. Gleiche angezeigte Quelle, Daten, Regeln und Ergebnisbezeichnungen mit ursprünglichen Auflösungsdaten und autorisiertem Kontext ab. Eine lesbare Oberfläche ist keine unabhängige Integritätsprüfung.
Ein erreichbares Dokument, gültige Herkunft und eine passende Anzeige sind getrennte Prüfungen. Keine allein bestimmt die richtige Auflösung.
Für Betreiber mit eigener Marke ist Kuests konkrete Ergänzung die Zuordnung von Metadatenreferenzen zum Ersteller sowie eine sichtbare Änderungshistorie neben ursprünglichen Auflösungsdaten. Das unterstützt einen prüfbaren Katalog und einen Veröffentlichungsprozess mit nachvollziehbarer Urheberschaft. Es bringt nicht alle Marktinformationen On-Chain, garantiert keine Dokumentverfügbarkeit und entscheidet keinen Bedeutungsstreit.
Starte mit Kuest deinen eigenen Prognosemarkt mit definierter Zielgruppe und Rechtsräumen, ausgearbeiteten Regeln, Quellen- und Korrekturrichtlinien, einem unterstützten Auflösungsweg und einem Plan für zugängliche Belege. Teste diese Grundlagen an mehrdeutigen Beispielen, bevor du Trades zulässt.