« Atteindra-t-on 30 degrés ? » laisse place à plusieurs transactions différentes. La prévision arrondie d’une application météo, la température mesurée par une station et un rapport officiel publié plus tard peuvent diverger. Le marché doit préciser lequel détermine le versement avant tout achat de YES ou de NO.
Ce sixième article de Comment fonctionnent Polymarket et Kuest transforme cette question en règle testable, puis suit ses preuves dans les couches distinctes du système. Une page lisible, les octets de résolution engagés et un document de métadonnées accessible démontrent chacun quelque chose de différent.
Reformulez la question jusqu’à ce que deux lecteurs obtiennent la même réponse
Conservez nos Observatoire A, Ville B et Date C fictifs. « À 12:00 » doit désigner l’heure d’observation ou l’échéance de publication ; ce sont des événements différents. Reformulez le titre ainsi : « L’observation de l’Observatoire A à 12:00 UTC pour la Ville B à la Date C sera-t-elle d’au moins 30.0°C ? » Précisez ensuite les preuves :
Utilisez le CSV officiel des observations quotidiennes de l’Observatoire A, station B-01, pour la Date C. Lisez le champ de température de l’air en degrés Celsius de l’enregistrement horodaté 12:00:00 UTC. Utilisez la dernière révision officielle disponible à 13:00:00 UTC à la Date C, y compris une révision publiée exactement à cette échéance. Comparez directement la valeur numérique publiée à 30.0 ; ne l’arrondissez pas à nouveau. Une valeur valide de 30.0 ou plus signifie YES ; une valeur valide inférieure signifie NO. Ignorez les prévisions, les autres stations et les révisions ultérieures. Si, à cette échéance, l’enregistrement a été retiré, des enregistrements contradictoires n’ont pas d’ordre officiel de révision, ou aucun enregistrement valide n’est disponible, utilisez le résultat prévu pour les données indisponibles.
Dans un vrai marché, remplacez chaque nom et date fictifs par l’URL exacte de la source, l’identifiant de station, la date du calendrier et la définition du champ. « Site officiel » seul laisse les lecteurs choisir entre pages, miroirs et révisions. Une source de secours exige aussi une priorité définie ; sinon, elle ajoute un choix après connaissance du résultat.
Ici, 29.96 signifie NO même si une application affiche 30.0. Une correction de 29.9 à 30.1 avant l’échéance signifie YES ; la même correction après ne change pas l’observation retenue. L’égalité est explicitement YES : le seuil ne laisse aucun cas d’égalité irrésolu.
L’heure d’observation sélectionne l’enregistrement. L’échéance sélectionne sa révision. La politique de versement traite les preuves manquantes.
Le résultat pour données indisponibles doit correspondre à la voie de contrat choisie. Pour cet exemple pédagogique, supposez un adaptateur binaire standard prenant en charge UNKNOWN : YES verse une unité de collatéral et NO zéro pour un résultat YES, l’inverse pour NO, et chacun verse une moitié pour UNKNOWN. C’est une hypothèse explicite du modèle, pas une règle universelle d’annulation ni une politique de versement NegRisk.
Une demi-unité par jeton n’est pas un remboursement de son prix d’achat. Un participant ayant payé 0.80 pour YES reçoit 0.50 selon ce résultat supposé. La mécanique de division et de rachat détermine le paiement ; les règles déterminent quel résultat pris en charge doit être déclaré.
Une échéance de source, une clôture de négociation et une heure de résolution ont des fonctions différentes. La première sélectionne les preuves ; la deuxième contrôle l’admission des ordres ; la troisième enregistre un résultat. Par exemple, les ordres peuvent s’arrêter à 11:55 UTC alors que les révisions admissibles restent ouvertes jusqu’à 13:00 ; la résolution peut suivre plus tard. L’opérateur doit configurer la négociation séparément et une transaction retardée ne prolonge pas l’échéance des preuves.
Suivez deux catégories de preuves
Un marché demande à la fois une question de résolution définie et des informations complémentaires lisibles. Les données auxiliaires, ou ancillary data, désignent les octets supplémentaires de la question utilisés par une intégration d’oracle donnée ; les métadonnées descriptives peuvent aussi comprendre images, libellés et liens. Elles ont des fonctions différentes et ne doivent pas être traitées comme des engagements interchangeables.
L’adaptateur public CTF de Polymarket est un exemple de données de question enregistrées selon un encodage défini. Recalculer un engagement demande cet encodage exact, pas un paragraphe visuellement similaire. Vérifiez l’interface publiée du déploiement choisi plutôt que de généraliser un exemple à plusieurs familles d’adaptateurs.
L’engagement de question et un document externe permettent des contrôles différents ; une référence ne prouve pas à elle seule l’intégrité ou la disponibilité.
Le contrat Conditional Tokens de Kuest au code publiquement vérifié enregistre un créateur et une référence externe de métadonnées. Une référence localise l’information ; elle ne prouve pas à elle seule qu’un document est disponible, immuable ou identique à l’engagement initial de résolution. Récupérez les documents et comparez-les aux preuves de question enregistrées.
La documentation publique de création de marché de Kuest décrit l’interface produit prise en charge. Un document téléversé, une condition préparée et un marché négociable sont des observations séparées. Confirmez les enregistrements appropriés plutôt que de déduire les trois d’un seul écran de succès.
Des identifiants similaires ont des fonctions différentes
Un slug localise une page. Un identifiant de question identifie une question selon le schéma de son adaptateur. Un identifiant de condition combine oracle, identifiant de question et nombre de résultats dans la construction publique CTF. Les entrées exactes comptent ; des textes similaires ne démontrent pas des conditions identiques.
Un identifiant de position identifie l’actif détenu et négocié. Dans CTF, sa dérivation dépend aussi du collatéral et de la collection représentant l’ensemble de résultats. Des titres ou slugs identiques ne prouvent pas des actifs identiques. L’adresse du créateur enregistre une attribution et certaines autorisations ; l’identifiant externe de métadonnées localise du contenu descriptif. Aucun ne remplace l’identifiant de condition ou de position.
Même « identifiant de question » n’est pas un encodage universel. Dans la NegRiskIdLib spécifique à Polymarket, une question partage les 31 premiers octets de l’identifiant de son marché et utilise le dernier pour son index. Appliquez cette règle uniquement à cette famille d’adaptateurs, pas à toutes les questions d’oracle.
Le champ metadata d’un ordre de négociation signé est un autre objet. Par exemple, la définition publique CTF Exchange V2 comprend un bytes32 metadata au niveau de l’ordre. Sa présence ne prouve pas que la signature engage le document affiché du marché.
Une mise à jour traçable reste une mise à jour
L’extension Conditional Tokens de Kuest enregistre le créateur de la condition et la référence externe actuelle de métadonnées. Le créateur ou un administrateur CTF peut remplacer cette référence. Chaque appel réussi incrémente un compteur et émet l’identifiant de condition, l’ancienne référence, la nouvelle et l’adresse de l’auteur de la mise à jour.
La fonction examinée ne fige pas les mises à jour à la résolution et ne vérifie pas qu’une chaîne de remplacement pointe vers un contenu disponible et non vide. Un identifiant de condition inchangé ne signifie donc pas que sa description actuelle affichée n’a jamais changé. Une mise à jour peut aussi ajouter une référence complémentaire ou corriger une image ; comparez les vrais documents avant de conclure que la proposition a changé.
Une mise à jour de référence peut enrichir un document ou modifier sa description. L’événement révèle qui a changé le pointeur ; comparez les contenus.
Changer le pointeur ne réécrit pas les octets originaux de la question et ne donne pas un nouveau droit de déclarer les versements. La fonction de déclaration de CTF dérive la condition en prenant l’appelant comme oracle. L’adaptateur et sa voie de résolution configurée déterminent comment un résultat parvient à cette fonction ; modifier les métadonnées est un pouvoir distinct.
Supposons que la version A indique 30.0°C et la version B 31.0°C. Un événement d’historique rend le remplacement visible ; il ne démontre pas que 31.0 est devenu le seuil légitime. Comparez les deux aux octets auxiliaires originaux et à la politique applicable de clarification avant d’interpréter le changement.
Les clarifications demandent un auteur et une politique
Polymarket possède déjà des engagements de question on-chain. Son adaptateur UMA CTF dans la version citée hache et stocke des données auxiliaires augmentées, tandis que son tableau d’annonces enregistre des mises à jour attribuées. Ce sont des mécanismes spécifiques à cet adaptateur CTF, pas une affirmation sur l’ABI de toutes les voies actuelles de Polymarket.
Une clarification demande aussi un auteur identifiable et une politique applicable. Dans l’exemple public de Polymarket, une publication attribuée ne réécrit pas les données auxiliaires originales. Ne traitez pas une déclaration quelconque mentionnant une question comme une modification officielle.
La documentation actuelle de résolution de Polymarket indique que le contexte des clarifications doit préserver l’intention fondamentale. Identifier une colonne CSV renommée peut clarifier les preuves ; remplacer un seuil de 30.0 par 31.0 change la proposition. Un horodatage prouve quand une déclaration a été enregistrée, pas qu’elle possède une autorité légitime.
Vérifiez le chemin de la référence à l’écran
Une revue pratique suit les preuves dans l’ordre :
- Identifiez le déploiement. Notez réseau, adresses des contrats, famille d’adaptateurs et référence de bloc. Obtenez le reçu de création, les octets originaux de la question, l’identité de l’oracle, le créateur et l’identifiant de condition.
- Recalculez les bons identifiants. Utilisez l’encodage, le traitement de l’initialiseur et le nombre de résultats de cette implémentation. Vérifiez les identifiants de position avec le collatéral réel et la correspondance des résultats.
- Suivez l’historique des métadonnées. Lisez référence de préparation, référence actuelle, compteur et journaux de mise à jour. Récupérez documents originaux et de remplacement, puis comparez changements et adresses des auteurs de mise à jour.
- Vérifiez séparément intégrité et disponibilité. Validez le contenu avec le véritable schéma de transaction ou d’engagement du système de stockage. Conservez les octets exacts récupérés et leur provenance ; une référence enregistrée ne peut pas fournir un document que personne ne peut récupérer.
- Comparez ce que voient les participants. Rapprochez source, dates, règles et libellés de résultat affichés des données originales de résolution et du contexte autorisé. Une interface lisible n’est pas un contrôle indépendant d’intégrité.
Un document accessible, une provenance valide et un affichage correspondant sont des contrôles séparés. Aucun n’établit seul la bonne résolution.
Pour un opérateur à sa marque, l’apport concret de Kuest est constitué des références de métadonnées liées au créateur et de l’historique visible des mises à jour aux côtés des données originales de résolution. Cela permet un catalogue vérifiable et un processus de publication attribuable. Cela ne place pas toutes les informations du marché on-chain, ne garantit pas la disponibilité des documents et ne tranche pas un désaccord sur leur sens.
Lancez votre propre marché prédictif avec Kuest en apportant une audience et des juridictions définies, une fiche de règles détaillée, des politiques de sources et de corrections, une voie de résolution prise en charge et un plan de conservation de preuves accessibles. Testez ces éléments sur des exemples ambigus avant d’accepter des transactions.