Signer un ordre autorise une transaction selon des conditions précises. Cela ne signifie pas qu’elle a eu lieu. L’API peut l’accepter, le carnet en apparier une partie et la transaction de règlement peut encore échouer.
Ce cinquième article de Comment fonctionnent Polymarket et Kuest suit l’autorisation derrière les carnets YES et NO reliés. Nous parcourons les couches distinctes du système : ce que signe le participant, ce qu’impose le service d’appariement et ce qu’enregistre réellement la blockchain.
Commencez par une instruction, puis suivez les actifs
Conservez notre question fictive : « L’Observatoire A publiera-t-il une température d’au moins 30.0°C pour la Ville B à 12:00 UTC à la Date C ? » Acheter son jeton YES signifie acquérir l’actif de résultat indiqué ; signer un ordre BUY autorise seulement cette acquisition.
Nous utilisons un marché binaire standard du Conditional Tokens Framework (CTF) et des unités génériques de collatéral. Les exemples de montants supposent six décimales, des fonds et autorisations suffisants et aucun coût de gas ou de financement ; les frais apparaissent séparément lorsqu’ils sont précisés.
Les explications suivantes utilisent des normes publiques de signature, des exemples publics CTF Exchange et des flux d’actifs fictifs. Les portefeuilles, types d’ordres et frais propres à une plateforme doivent provenir de sa documentation publique actuelle d’intégration.
Trois autorisations remplissent des fonctions différentes
Une signature d’ordre autorise une instruction particulière de négociation. L’authentification API identifie un demandeur autorisé auprès d’un service. Une signature de lot du portefeuille autorise un ensemble distinct d’appels au portefeuille, comme la définition d’une autorisation de dépense.
Un identifiant d’API identifie un demandeur autorisé auprès d’un service ; ce n’est pas la clé privée du participant et il ne remplace pas une signature d’ordre. Le guide public des portefeuilles et de l’authentification de Polymarket fournit un exemple documenté de produit.
Objets distincts, vérifications distinctes. Un lot du portefeuille possède son propre nonce et sa propre échéance ; ces champs ne font pas partie de l’ordre de négociation.
EIP-712 définit le hachage et la signature de messages structurés. Son domaine peut lier une instruction à une chaîne, un nom d’application, une version et un contrat de vérification, empêchant une signature destinée à un domaine d’être valide dans un autre.
Le code public de signature de CTF Exchange V2 illustre un domaine EIP-712 propre à l’application. Un nom ou une version de domaine fait partie du contexte signé ; il ne prouve pas qu’un autre système accepte le même message. Les limites de réutilisation dépendent aussi de l’état et des règles de validation du contrat réel.
Les montants contiennent le prix
Dans la définition publique des ordres CTF Exchange V2, l’instruction signée comprend notamment le jeton, le côté, les montants maker et taker et les identités des comptes. La signature autorise ce message défini, pas le prix qu’une interface afficherait ensuite.
Ici, maker désigne le compte qui fournit les actifs, même lorsque son ordre prend immédiatement de la liquidité. Ce nom de champ diffère du rôle de négociation maker, qui désigne un ordre restant dans le carnet avant qu’un autre ordre ne négocie contre lui.
Pour un BUY, makerAmount est le collatéral offert et takerAmount les parts demandées. Un ordre offrant 60 pour 100 YES encode une limite de 60 ÷ 100 = 0.60 ; pour un SELL offrant 100 YES contre 60, le prix est au contraire takerAmount ÷ makerAmount.
Aucun champ indépendant de prix signé ne remplace ce rapport. Modifier le prix affiché sans reconstruire et signer les montants correspondants ne change pas les conditions autorisées.
Un horodatage peut indiquer la création d’un ordre sans être une échéance d’expiration exécutoire. Une intégration doit distinguer les champs signés des instructions de service et vérifier leur signification dans la spécification publique actuelle des ordres.
La validation décide si l’ordre peut entrer dans le carnet
Avant de passer un ordre, vérifiez l’actif voulu, la limite de prix, la quantité, le compte et le type d’ordre pris en charge. Les contrôles du client et un accusé de réception API ne remplacent pas un règlement réussi par le contrat.
Le pas de cotation est l’incrément autorisé entre prix proposés. Vérifiez les spécifications publiques actuelles du marché avant de signer. Un contrôle côté client, une réponse du service et une règle du contrat établissent des choses différentes ; un minimum affiché ne démontre à lui seul aucune contrainte on-chain.
Les fonds et autorisations sont des contrôles distincts : un BUY demande du collatéral utilisable et une autorisation de dépense suffisante pour le contrat de règlement ; un SELL demande les jetons de résultat et l’approbation de transfert. Une signature seule ne fournit ni l’un ni l’autre et un contrôle de solde à l’admission ne peut pas figer tous les changements ultérieurs du compte.
Post-only signifie qu’une instruction vise à ajouter de l’intérêt en attente plutôt qu’à prendre immédiatement de la liquidité. Vérifiez les combinaisons et comportements de rejet documentés par la plateforme ; ce libellé ne définit pas à lui seul toutes les implémentations.
La durée de validité indique au service d’appariement quoi faire de la quantité non exécutée :
- GTC — good till cancelled : laisser la quantité restante admissible dans le carnet jusqu’à annulation.
- GTD — good till date : lui permettre de rester jusqu’à une expiration définie.
- FAK — fill and kill : exécuter immédiatement la quantité disponible et supprimer le reste.
- FOK — fill or kill : exiger que toute la quantité demandée soit exécutable ou ne rien exécuter.
Un ordre de service qui expire et une échéance signée du contrat sont des engagements différents. Vérifiez où la spécification actuelle impose l’expiration et ce qu’il advient des transactions déjà soumises. La présence d’un champ dans une demande n’établit pas en soi une garantie du contrat.
Un appariement exige encore un règlement réussi
Prenez ces étapes pédagogiques : signé → accepté/en attente → apparié → soumis → confirmé. Un ordre peut être rejeté avant admission ; un ordre accepté peut produire plusieurs appariements partiels et transactions de règlement. Ces libellés expliquent les responsabilités plutôt qu’ils ne définissent une énumération universelle d’API.
Un appariement partiel laisse une quantité pour des appariements ultérieurs si la durée de validité le permet. Un règlement échoué exige un rapprochement avant toute nouvelle tentative.
Le contrat public CTF Exchange V2 illustre l’appariement autorisé et les contrôles du contrat avant mouvement d’actifs. Les exemples directs, d’émission et de fusion de l’article 4 expliquent les mouvements possibles et leurs besoins de financement.
La transaction est atomique : si un transfert ou contrôle requis échoue en annulant l’exécution, ses changements d’état sont annulés. Cela n’annule pas une autre transaction déjà réussie et une transaction annulée peut tout de même consommer du gas.
Un hash de transaction identifie une transaction soumise, pas un achat réussi. Vérifiez son reçu et l’état de confirmation requis par le réseau choisi. Tant que l’issue est inconnue, l’interface doit préserver cette incertitude plutôt qu’annoncer des actifs livrés.
Dans l’interface d’un opérateur, conservez séparément l’identifiant d’ordre, la quantité appariée et la référence de transaction. Si une transaction échoue ou reste incertaine, rapprochez son issue réelle avant de réessayer ; changer un libellé local ne déplace pas d’actifs.
Les exécutions partielles consomment l’actif offert
Supposons que le BUY en attente offre 60 de collatéral pour 100 YES et qu’une première exécution reçoive 40 YES exactement à 0.60. Sans frais, elle consomme 24 de collatéral, laissant 36 de collatéral de capacité signée, soit 60 YES au même prix.
Un SELL en attente offrant 100 YES pour 60 de collatéral consomme 40 YES lors de cette exécution et reçoit 24 de collatéral. Son montant maker restant est de 60 parts, pas 36 de collatéral. Les deux ordres ont encore 60 YES à négocier, mais leurs compteurs restants on-chain utilisent des actifs différents.
Même exécution de 40 parts, unités de compteur différentes. Exécution exacte au prix limite ; frais exclus.
L’arithmétique publique de CTF Exchange V2 utilise des unités de base entières. Dans le modèle proportionnel de division avec arrondi inférieur ci-dessous, le montant reçu égale le montant fourni × montant taker signé ÷ montant maker signé, arrondi vers le bas. Un rapprochement exact demande les règles d’arrondi de la voie réelle.
Par exemple, vendre 1.000001 parts d’un ordre signé de 3 parts contre 1.8 de collatéral calcule 1 000 001 × 1 800 000 ÷ 3 000 000, arrondi vers le bas à 600 000 unités de base de collatéral. Les petites exécutions et les frais exigent donc les règles d’arrondi de l’implémentation ; multiplier des prix affichés arrondis ne suffit pas pour un rapprochement exact.
Les frais demandent leur propre registre
Supposons un achat direct de 100 YES pour 60 de collatéral avec des frais fictifs de 0.60 pour chaque participant. L’acheteur a besoin de 60.60 de collatéral ; le vendeur reçoit 59.40. Les 1.20 restants représentent les frais totaux : tous les fonds de l’acheteur sont ainsi comptabilisés.
Frais fictifs, pas un tarif actuel. Sortie acheteur 60.60 = recette vendeur 59.40 + frais totaux 1.20 ; 100 YES existants passent à l’acheteur.
Dans cet exemple explicite, les frais BUY s’ajoutent aux fonds nécessaires à l’acheteur et les frais SELL sont déduits des recettes. Les frais, bénéficiaires et arrondis réels doivent être vérifiés pour la plateforme et la voie choisies ; l’exemple n’est pas un barème.
L’annulation a une limite
Une demande de retrait d’un ordre ouvert concerne sa quantité restante non exécutée. Elle n’inverse pas les exécutions terminées. Traitez la confirmation d’annulation et toute transaction de règlement en cours comme des enregistrements séparés ; vérifiez les deux avant de réutiliser les fonds.
Si le règlement a déjà été soumis, une annulation ultérieure dans le carnet ne peut pas promettre de l’arrêter. Vérifiez l’issue de la transaction avant de supposer les actifs encore disponibles, surtout si l’ordre initial a été partiellement exécuté.
Annuler le reste et régler un appariement précédent peuvent tous deux se produire. Aucune protection différée n’inverse une transaction réussie.
Une restriction plus large du compte n’équivaut pas à annuler un ordre. Les contrôles de récupération peuvent avoir des périmètres, délais et autorités différents. Utilisez la documentation publique du contrat et du produit pour le compte réel plutôt que de supposer que chaque contrôle est un arrêt immédiat.
La Deposit Wallet possède une pause et un délai d’urgence distincts avant les retraits d’urgence ou révocations d’approbations. Dans ce code, la pause du portefeuille seule ne désactive ni l’exécution de lots ni la validation des signatures ; ce n’est pas un arrêt instantané de la négociation.
Les noms de version ne définissent pas une intégration
L’ancien ordre CTF de Polymarket signait taker, expiration, nonce et feeRateBps. Son ordre distinct CTF Exchange V2 retire ces champs et ajoute timestamp, metadata et builder ; le prix reste un rapport de montants.
Le dépôt V2 retire également fillOrder/fillOrders, conservant l’appariement par opérateur via matchOrders. Ce CTF Exchange V2 est distinct de l’architecture de positions Protocol V2 dans polymarket-v2-external ; Kuest n’hérite automatiquement des mises à jour d’aucun de ces dépôts.
L’absence d’expiration dans une structure du contrat ne signifie pas qu’un produit n’a pas d’ordres expirants. La documentation actuelle du cycle de vie de Polymarket décrit GTD au niveau du produit ; son guide des positions distingue les registres CTF et Protocol V2. Vérifiez la voie du marché réel avant de construire une intégration.
Ce qu’un opérateur Kuest devrait communiquer
Le guide public pour opérateurs de Kuest sépare l’application de l’opérateur des services partagés. Communiquez aux participants le parcours de compte pris en charge, l’estimation complète des frais et les états distincts accepté, apparié et confirmé ; ce sont des exigences observables du produit, pas des détails d’implémentation.
La documentation publique des frais de Kuest décrit la participation de l’opérateur aux frais de négociation et le partage configurable avec les affiliés. Une répartition de frais diffère d’un prélèvement supplémentaire sur le montant nominal négocié. Utilisez la configuration publique actuelle et les enregistrements de règlement pour expliquer ce que paie un participant.
Pour un opérateur à sa propre marque, cela crée une décision concrète d’intégration : préserver l’identité correcte du builder, afficher le prélèvement total réel et rapprocher sa répartition des enregistrements de règlement. Un code ou un frontend à sa marque ne garantit à lui seul ni admission, ni droit à des frais, ni revenus.
Lancez votre propre marché prédictif avec Kuest avec une politique d’exécution compréhensible pour vos participants : juridictions de l’audience prévue, règles précises et voie de résolution, quantités de négociation nécessaires, parcours de portefeuille pris en charge, information sur les frais et états distincts accepté, apparié et confirmé.