Le site d’un marché prédictif est l’entrée d’un système aux fonctions multiples. L’interface présente un marché, le système de négociation apparie les ordres, les contrats règlent les mouvements d’actifs et les services de données rendent le résultat lisible. Un oracle fournit la réponse finale du marché par son processus de résolution configuré.
Ces fonctions se déroulent à des endroits différents. Un clic, un ordre accepté et une transaction réglée sont des étapes distinctes. Comprendre leurs limites explique pourquoi un marché peut être visible alors que la négociation est indisponible, ou pourquoi une transaction terminée peut mettre du temps à apparaître dans un portefeuille.
Voici le deuxième article de Comment fonctionnent Polymarket et Kuest. Commencez par ce que signifie réellement le prix d’un marché prédictif si vous découvrez les prix et les versements.
Quatre couches, quatre responsabilités
| Couche | Rôle |
|---|---|
| Interface | Présenter les questions, les règles et les contrôles du compte |
| Système de négociation | Valider les ordres et trouver un intérêt de négociation compatible |
| Contrats | Appliquer les règles d’actifs et d’autorisations de la voie choisie |
| Services de données | Organiser les métadonnées, les soldes et l’activité pour les applications |
La présentation des API de Polymarket reflète cette séparation : Gamma permet la découverte, CLOB prend en charge les ordres et l’état du marché en temps réel, et Data API fournit l’activité des comptes et des marchés. Les WebSockets fournissent des mises à jour ; ils ne remplacent pas les règles de règlement sous-jacentes.
Une page n’est pas un identifiant de position
Un événement regroupe des marchés liés pour les présenter. Un marché binaire pose une question précise pouvant être résolue et propose des résultats YES et NO distincts. Un événement peut contenir plusieurs marchés : l’adresse de sa page ne suffit donc pas à préciser un ordre. Consultez le modèle de marchés et d’événements de Polymarket.
Dans le Conditional Tokens Framework, ou CTF, l’identifiant de question désigne l’entrée de résolution. L’identifiant de condition est dérivé de l’adresse de l’oracle, de l’identifiant de question et du nombre d’emplacements de résultat. L’identifiant d’une position de résultat dépend aussi du collatéral et du chemin de collections. Ces identifiants ne peuvent pas être substitués les uns aux autres sans risque.
Une carte de regroupement, pas une formule de hachage. Sélectionnez le marché et le résultat exacts avant de lire son carnet ou de passer un ordre.
Le guide des données on-chain de Polymarket distingue ces dérivations CTF des identifiants de Protocol V2. Un titre identique sur un autre site ne prouve pas qu’il s’agit du même actif.
Suivez un ordre à travers le système
D’abord, l’interface trouve un marché et obtient ses identifiants de résultat et sa configuration de négociation. Le client prépare un ordre et le signataire concerné en autorise les conditions. Signer un ordre n’est pas la même action que diffuser une transaction sur une blockchain.
L’instruction signée parvient au carnet central d’ordres à cours limité, ou CLOB. Le service vérifie son admissibilité et recherche des ordres compatibles. Un ordre admis peut rester ouvert s’il ne peut pas être exécuté immédiatement ; un appariement est un accord de transaction selon les règles de la plateforme, pas encore une preuve de livraison des actifs.
Vient ensuite le règlement. Un service d’exécution soumet une transaction aux contrats concernés sur Polygon. La voie de règlement valide la transaction autorisée et met à jour les actifs si l’exécution réussit. Une transaction échouée ne devient pas un achat réussi simplement parce que l’API avait auparavant signalé un appariement.
Les flèches pleines suivent l’instruction vers le règlement. Les flèches pointillées montrent les données enregistrées revenant à l’interface ; elles ne déplacent pas le collatéral.
Polymarket documente le cycle de vie des ordres et demande séparément aux intégrations d’attendre le règlement des exécutions avant de vérifier la position obtenue. L’inclusion de la transaction et l’état de confirmation requis comptent ; un identifiant d’ordre seul ne suffit pas.
Enfin, les indexeurs traitent les changements enregistrés et les API fournissent des vues actualisées. L’interface peut alors afficher la position et l’activité. Ces étapes demandent des messages d’état distincts plutôt qu’un unique « succès » ambigu.
Les contrats forment une famille, pas un seul bloc
Un système fondé sur CTF répartit les responsabilités entre plusieurs familles de contrats. Les noms suivants décrivent des rôles ; les contrats et autorisations exacts dépendent de la voie.
Une carte des responsabilités. Ces panneaux ne prétendent pas que chaque transaction appelle les cinq familles.
| Famille | Rôle |
|---|---|
| Portefeuilles, fabriques et infrastructure de mise à niveau | Détenir les actifs et appliquer les règles de propriété, de signature et d’implémentation |
| CTF Exchange ou une voie de négociation à risque négatif | Valider et régler les ordres appariés concernés |
| Conditional Tokens | Suivre les soldes de résultats CTF et permettre division, fusion et rachat |
| Adaptateurs d’oracle et voies de résolution | Relier une réponse acceptée au versement enregistré pour une condition |
| Soutien aux frais, récompenses et séquestres | Servir des processus supplémentaires de comptabilité, d’incitation ou de financement lorsqu’ils sont configurés |
Règlement et résolution répondent à des questions différentes. Le règlement demande si cette transaction peut déplacer des actifs. La résolution demande quel versement découle des règles du marché. La documentation de résolution de Polymarket distingue actuellement les marchés fondés sur UMA des marchés de hausse ou baisse avec Chainlink TWAP ; un moteur d’appariement ne décide pas de ce résultat en choisissant un prix de transaction.
La version compte. Polymarket documente actuellement des systèmes de positions CTF et Protocol V2. Protocol V2 utilise PositionManager, tandis que CTF utilise Conditional Tokens. Son registre des contrats énumère des composants de règlement différents. « Exchange V2 » n’est pas interchangeable avec « Protocol V2 » ; identifiez toujours ensemble la version du marché, le registre et la voie.
Les données rendent le registre utilisable, mais peuvent être en retard
Un indexeur transforme les événements des contrats en enregistrements consultables. Une API peut combiner ces enregistrements avec les métadonnées du marché, des prix ou des calculs. Ce sont des données utiles à l’application, mais leur rythme d’actualisation peut différer de celui d’un reçu de transaction ou d’un flux d’ordres en direct.
Le guide des données on-chain de Polymarket décrit les événements de transfert et d’exécution d’échanges. Ces enregistrements ne contiennent pas tous les ordres hors chaîne en attente. De même, appeler un indexeur « sous-graphe du carnet d’ordres » n’en fait pas le carnet en direct. Une cotation actuelle et une exécution historique appartiennent à des enregistrements différents.
Si un portefeuille semble obsolète, comparez son heure d’actualisation avec la transaction et le registre concerné. Si une cotation disparaît, examinez le carnet actuel. Ce sont des investigations distinctes ; actualiser un catalogue ne prouve ni un ordre non exécuté ni des fonds manquants.
Un relayer aide à soumettre des transactions ; il ne supprime pas les dépendances
Un relayer peut soumettre des actions de portefeuille prises en charge, comme le déploiement ou des approbations. La documentation des portefeuilles de Polymarket décrit des actions sponsorisées permettant au compte de fonctionner sans détenir le jeton natif de gas pour ces appels. Du gas reste consommé ; son coût est payé ailleurs.
Un relayer de portefeuille et les services d’appariement et de règlement ont des fonctions différentes. La disponibilité, les appels pris en charge et les politiques de sponsoring comptent. Ne supposez pas que chaque échange passe par un relayer de portefeuille, ni que le sponsoring prouve quoi que ce soit sur la garde des actifs, les pouvoirs de mise à niveau ou la justesse de l’oracle.
La différence Kuest : la vitrine peut changer et la voie rester partagée
Le guide public d’architecture de Kuest distingue la marque et le catalogue de l’opérateur de l’infrastructure de négociation partagée. Les opérateurs peuvent sélectionner des marchés pour leur audience tout en utilisant des services communs d’exécution compatibles.
L’exécution partagée exige des services, un réseau et des actifs correspondants. Une marque séparée ne crée ni ne garantit la liquidité.
Deux sites à leur propre marque utilisant les mêmes services et actifs Kuest peuvent donner accès au même intérêt de négociation tout en présentant des catalogues différents. Pour un opérateur, cela signifie réutiliser l’infrastructure d’exécution tout en composant une expérience ciblée pour une audience.
L’opérateur présente le marché aux traders ; un teneur de marché apporte un intérêt de négociation par ses ordres. Ces rôles de participants sont distincts des services qui apparient et règlent les échanges. Créer un marché n’apporte pas en soi des contreparties disposées à négocier ni une quantité exécutable.
Les services partagés de Kuest ne fusionnent pas son carnet avec celui de Polymarket, et une question miroir ne rend pas les soldes transférables entre plateformes.
Les familles de contrats ci-dessus expliquent des responsabilités, pas un inventaire complet de déploiement. Avant d’exploiter un marché, vérifiez le réseau réel, les adresses des contrats, le code publié, les autorisations et le système de positions pris en charge. Un audit du projet d’origine ne couvre pas automatiquement un autre déploiement ou des modifications propres.
Pour un opérateur, l’examen utile est concret : quels actifs de marché ce site affiche-t-il, quels services acceptent ses ordres, quels contrats les règlent et les enregistrements affichés sont-ils récents ? Une nouvelle marque devrait rendre ces réponses plus faciles à trouver.
Vous souhaitez construire cette expérience pour votre audience ? Créez votre propre marché prédictif avec la configuration guidée de Kuest.