Polymarket lance le protocole V2, avec de nouveaux marchés qui seront transférés le 2 novembre

2026/10/13 17:00:00

Polymarket a commencé le déploiement du Protocole V2, une mise à niveau majeure de l'infrastructure de contrats intelligents soutenant ses marchés prédictifs basés sur la blockchain. Annoncé le 5 octobre 2026, le nouveau protocole introduit des jetons de position unifiés, des contrats de trading redessinés et une intégration élargie des oracles. L'entreprise cible le 2 novembre 2026 pour le transfert des nouveaux marchés vers V2, après plusieurs semaines de tests en direct. La mise à niveau affecte l'infrastructure sous-jacente au trading de marchés prédictifs, où les participants achètent et vendent des positions liées à des résultats du monde réel. Bien que les positions existantes restent sur leurs contrats actuels, les développeurs et les market makers doivent se préparer aux changements concernant les intégrations de trading, les autorisations de contrat et les services de données de marché.

Points clés

Lancement du protocole Polymarket V2 : Polymarket a introduit son infrastructure améliorée de marché de prévisions le 5 octobre 2026, en commençant un test en direct limité avant un déploiement plus large ciblant les marchés nouvellement créés.
Cible de migration du 2 novembre : Polymarket prévoit de déplacer les nouveaux marchés sur le Protocole V2 le 2 novembre, après les tests canari prévus jusqu'au 30 octobre. Les marchés existants ne seront pas migrés automatiquement.
Mises à jour des smart-contracts : le protocole V2 introduit des jetons de position ERC-1155, ExchangeV3 et des contrats modulaires prenant en charge quatre formats de marché, tout en conservant une garantie pUSD soutenue 1:1 par USDC.
Positions existantes et exigences pour les développeurs : Les détentions actuelles de CTF restent prises en charge sans conversion obligatoire. Les développeurs doivent mettre à jour les intégrations concernées, y compris les nouveaux identifiants de position, les approbations de contrat et les exigences de signature des ordres.
Date limite API du 24 octobre : Polymarket prévoit de retirer les points de terminaison Data API V1, avec des exceptions documentées, avant la transition générale vers V2. Les développeurs qui dépendent des services concernés doivent migrer vers Data API V2.
Sécurité et capacités futures : Six sociétés de sécurité ont examiné les contrats V2, tandis que la nouvelle infrastructure oracle prend en charge les intégrations UMA et Chainlink. La fonctionnalité cross-chain reste une capacité potentielle future plutôt qu'un déploiement général confirmé.

Lancement du protocole Polymarket V2 et calendrier de la migration du 2 novembre

Polymarket a introduit le Protocole V2 le 5 octobre 2026, entamant une mise à niveau progressive des contrats intelligents soutenant ses marchés de prévision basés sur la blockchain. Announcé par Rajath Alex, Responsable du Protocole de Polymarket, cette mise à jour remplace les composants clés de l'architecture originale de la plateforme construite sur le Gnosis Conditional Tokens Framework (CTF). Le déploiement vise à simplifier l'infrastructure des marchés, à prendre en charge des formats de marché supplémentaires et à améliorer la flexibilité pour les développements futurs. Le 2 novembre 2026 est la date cible provisoire pour que les nouveaux marchés adoptent V2, et non une date obligatoire de migration pour tous les marchés existants. L'approche progressive permet à Polymarket d'évaluer le système amélioré avant d'en étendre l'utilisation, tout en maintenant le soutien aux marchés fonctionnant sur l'infrastructure existante.

Pourquoi Polymarket teste le protocole V2 avec des marchés canari

Polymarket a commencé à tester le Protocole V2 à travers un nombre limité de marchés canaries en direct, au lieu de transférer immédiatement toute l'activité des marchés vers la nouvelle infrastructure. Ces marchés fonctionnent avec des contrats intelligents V2 et permettent aux développeurs d'évaluer les opérations de trading, le traitement des transactions et les interactions entre les composants du protocole dans des conditions réelles. En introduisant le système progressivement, Polymarket peut examiner comment la nouvelle architecture gère l'activité des marchés sans nécessiter une transition immédiate à l'échelle de la plateforme.

La période de test est prévue pour se poursuivre jusqu'au 30 octobre 2026, offrant à Polymarket le temps d'identifier d'éventuels problèmes techniques ou d'intégration avant d'étendre le déploiement. Le test canari peut aider à révéler des problèmes que les environnements de développement contrôlés pourraient manquer, bien qu'il ne puisse pas garantir que le déploiement plus large sera exempt de vulnérabilités ou de perturbations opérationnelles. Les résultats seront essentiels pour déterminer si le protocole est prêt à une adoption plus large et si des ajustements supplémentaires sont nécessaires avant la transition prévue en novembre.

Quand les marchés Polymarket passeront-ils au protocole V2 ?

La migration de Polymarket suit un calendrier en étapes couvrant les services aux développeurs, les tests en direct et le déploiement de nouveaux marchés. La transition sépare également les positions CTF existantes des marchés créés sous le Protocole V2, ce qui signifie que les détentions actuelles ne seront pas automatiquement converties vers la nouvelle architecture. Cette distinction est importante car la mise à niveau affecte différentes parties de l'infrastructure de Polymarket à des moments différents. Selon les consignes de migration publiées par Polymarket, les principales étapes à venir sont :

24 octobre 2026 : Polymarket prévoit de retirer les points de terminaison de l'API Données V1, avec des exceptions documentées, obligeant les développeurs concernés à passer à l'API Données V2.
30 octobre 2026 : La période de test canari prévue prend fin, sous réserve des résultats des tests en production.
2 novembre 2026 : Polymarket prévoit provisoirement de commencer à créer de nouveaux marchés de prévision en utilisant le Protocole V2, tandis que les marchés CTF existants resteront séparés.

La cible de migration du 2 novembre reste conditionnelle, et le calendrier final de déploiement pourrait changer en fonction des résultats des tests et de la préparation technique. Les marchés existants ne seront pas automatiquement transférés vers V2 à cette date, donc la transition pourrait impliquer un fonctionnement simultané de l’infrastructure ancienne et de l’infrastructure mise à niveau. Polymarket n’a pas établi le 2 novembre comme date limite universelle pour convertir toutes les positions en cours.

Comment le protocole Polymarket V2 modifie les contrats intelligents, la garantie pUSD et l'intégration des oracles

Le protocole Polymarket V2 introduit une infrastructure de trading repensée qui unifie la gestion des positions, la logique spécifique aux marchés, la gestion des collatéraux et les processus de résolution. Cette mise à niveau remplace plusieurs composants de l'architecture ancienne Conditional Tokens Framework (CTF) par des contrats intelligents modulaires conçus pour prendre en charge différents formats de marchés de prévision. Ses principaux changements techniques impliquent des jetons de position ERC-1155, un collatéral pUSD, ExchangeV3 et un OracleAggregator qui relie plusieurs mécanismes de résolution.

Contrats intelligents ERC-1155 et marchés de prévision modulaires

La nouvelle architecture utilise un seul contrat PositionManager basé sur la norme ERC-1155 pour gérer les positions sur les marchés de prévision. ERC-1155 permet à plusieurs types de jetons d'exister au sein d'un seul contrat intelligent, réduisant ainsi le besoin de structures séparées pour la gestion des positions. Les échanges sont gérés par ExchangeV3, tandis qu'un contrat Router coordonne des opérations telles que la division, la fusion et le rachat des positions. Ce dispositif sépare la comptabilisation des jetons des fonctions spécifiques au marché, rendant le système sous-jacent plus facile à étendre sans avoir à redessiner son infrastructure centrale de positions.

Polymarket V2 prend en charge initialement quatre formats de marché : Binaire, Atomic Neg-risk, Incremental Neg-risk et Combinatorial. Ils fonctionnent via trois modules documentés : BinaryModule, NegRiskModule et CombinatorialModule. Les marchés binaires impliquent deux issues possibles, tandis que les formats à risque négatif permettent de prendre en compte des issues liées au sein d'événements plus larges. Les marchés combinatoires permettent des positions liées à des combinaisons d'issues. Chaque position reçoit également un identifiant structuré qui la relie au module approprié, permettant au système de déterminer quel contrat gère ses opérations.

Comment fonctionne la garantie pUSD dans le protocole Polymarket V2

Polymarket V2 utilise le Polymarket USD (pUSD) comme jeton de garantie, en maintenant un système de trading dénommé en dollars à travers différents formats de marchés prédictifs. Contrairement à une cryptomonnaie spéculative nouvellement émise, pUSD est un jeton ERC-20 sur Polygon garanti 1:1 par l'USDC, avec cette garantie appliquée par des contrats intelligents. Ce dispositif s'inscrit dans l'utilisation plus large du collatéral en stablecoin dans le trading de cryptomonnaies, où des actifs liés à des valeurs de référence plus stables soutiennent le trading et le règlement. Polymarket a initialement introduit le pUSD lors de sa mise à niveau de la plateforme d'échange du 28 avril 2026, ce qui signifie que la version V2 du protocole October poursuit un arrangement de garantie existant plutôt que d'introduire une nouvelle stablecoin.

L'infrastructure de garantie comprend les contrats CollateralOnramp et CollateralOfframp qui gèrent les conversions entre les actifs de garantie pris en charge et pUSD. La documentation de Polymarket identifie également des adaptateurs reliant pUSD à la garantie utilisée par les anciens marchés CTF, permettant à deux systèmes de position de fonctionner au sein de l'infrastructure commerciale plus large. Cette conception fournit une couche de garantie commune tout en maintenant la compatibilité entre différentes architectures de marché. Toutefois, l'utilisation de garanties adossées à l'USDC ne supprime pas les risques liés aux contrats intelligents, aux conversions ou aux stablecoins sous-jacents.

OracleAggregator relie UMA et Chainlink pour la résolution des marchés

Le protocole V2 introduit un OracleAggregator pour coordonner la manière dont les marchés de prévision déterminent leurs résultats finaux. Une oracle fournit des informations externes que les contrats intelligents sur blockchain ne peuvent pas vérifier indépendamment, telles que les résultats électoraux, les résultats sportifs ou les prix des actifs. Ces oracles décentralisés sur blockchain sont des composants essentiels des applications qui reposent sur des informations du monde réel. Au lieu de compter sur un seul mécanisme de résolution pour chaque marché, la nouvelle architecture utilise des modules configurables pouvant se connecter à différentes sources de rapports. Cela confère à Polymarket une plus grande flexibilité pour adapter le processus de résolution d’un marché au type d’information requis.

Le système oracle documenté comprend plusieurs composants distincts :

Intégration UMA : le module OOReporterModule peut transmettre les résultats établis de l'Optimistic Oracle de UMA dans le processus de résolution de Polymarket, en soutenant les marchés qui dépendent de résultats vérifiés externes.
Données de prix Chainlink : le module ChainlinkReporterModule prend en charge la résolution basée sur les prix en utilisant les informations des flux de données Chainlink configurés, y compris les comparaisons entre les prix de départ et de fin d'un actif.
Contrôles de contestation et d'arbitrage : OracleAggregator prend en charge les seuils de signalement, les fenêtres de contestation et les procédures d'arbitrage. Ces mécanismes permettent de contester les résultats signalés selon des règles configurées avant le règlement final.

Le système modulaire peut intégrer des sources de résolution supplémentaires sans nécessiter le remplacement de l'ensemble de l'architecture de gestion des positions. Toutefois, la fiabilité des oracles reste essentielle à la précision des marchés de prévision. Des données externes incorrectes, des erreurs de configuration ou des litiges concernant le résultat d'un événement peuvent toujours affecter le règlement, même lorsque plusieurs mécanismes de rapport sont pris en charge.

Ce que Polymarket V2 signifie pour les positions existantes, les développeurs et les marchés de prévisions futurs

La mise à niveau du protocole V2 de Polymarket introduit des exigences différentes pour les traders quotidiens, les développeurs et les market makers. Bien que la plateforme vise à maintenir une expérience de trading familière pour les utilisateurs réguliers, les applications connectées directement à son infrastructure doivent prendre en compte de nouveaux identifiants de position, des autorisations de contrat et des règles de signature des ordres. Le système redessiné crée également des opportunités pour des fonctionnalités supplémentaires de marchés de prévision, bien que plusieurs capacités restent en développement et ne soient pas encore disponibles pour une utilisation générale.

Que deviennent les positions et les wallets existants sur Polymarket ?

Les positions existantes sur Polymarket continueront à fonctionner via leurs contrats originaux du Conditional Tokens Framework (CTF), à moins qu'une migration séparée ne soit effectuée. Selon les instructions de migration de Polymarket, les utilisateurs du site web et de l'application mobile n'ont pas besoin d'effectuer une migration technique ni de transférer manuellement leurs actifs vers un autre wallet. Toutefois, les utilisateurs peuvent rencontrer de nouvelles demandes d'autorisation lorsqu'ils interagissent avec les marchés fonctionnant sur l'infrastructure mise à niveau. Ces autorisations permettent aux contrats intelligents concernés d'accéder aux actifs ou positions approuvés pour des opérations de trading spécifiques.

Plusieurs considérations pratiques sont importantes pour les détenteurs de position existants :

Autorisations de wallet : les utilisateurs peuvent devoir autoriser de nouveaux contrats de trading avant d'interagir avec les marchés V2. Les autorisations existantes pour les anciens contrats ne s'étendent pas automatiquement au nouveau système.
Gestion des positions : les détentions héritées restent associées à leurs contrats d'origine, tandis que les positions V2 utilisent un système de comptabilité séparé. Les applications de suivi de portefeuille doivent reconnaître les deux.
Migration facultative : La documentation des contrats de Polymarket décrit les mécanismes permettant de convertir certaines positions héritées éligibles en positions V2, mais les conditions ou événements concernés doivent d'abord être enregistrés. Ce n'est pas un processus automatique à l'échelle de la plateforme.

Pour les traders réguliers, la principale considération est de savoir si un marché donné fonctionne sous l'infrastructure ancienne ou améliorée. Les utilisateurs doivent suivre les instructions fournies via l'interface officielle de Polymarket et vérifier les demandes d'autorisation de wallet avant d'autoriser les transactions. La mise à niveau du protocole n'élimine pas les risques financiers liés aux marchés de prévision, notamment les pertes potentielles lorsqu'un événement se règle contre une position.

Comment les développeurs et les market makers doivent s'adapter à Polymarket V2

Les développeurs qui exploitent des bots de trading, des systèmes de market-making, des tableaux de bord de portefeuille ou des plateformes d'analyse font face à des changements d'intégration plus importants. L'infrastructure mise à jour de Polymarket exige que les applications distinguent entre les actifs CTF hérités et les positions V2 lors de la passation de commandes, de la vérification des soldes ou du traitement de l'activité du marché. Bien que les points de terminaison de carnet d'ordres existants et les arrangements d'authentification restent disponibles pour les intégrations compatibles, les transactions V2 nécessitent des identifiants différents, des approbations de contrat et des règles de signature distinctes.

Les principales exigences techniques incluent :

Identification du marché : les intégrations V2 utilisent des positionIds, tandis que les marchés hérités continuent d'utiliser des clobTokenIds. Les applications doivent identifier la version du marché avant de sélectionner l'identifiant d'actif approprié.
Authentification des commandes : les commandes ExchangeV3 utilisent la version 3 du domaine de signature EIP-712, tandis que les commandes existantes CTFExchangeV2 utilisent la version 2. Mélanger ces formats peut entraîner le rejet des commandes.
Permissions de trading : L'achat de positions V2 nécessite une approbation suffisante en pUSD pour ExchangeV3, tandis que la vente nécessite une autorisation de l'opérateur sur les jetons PositionManager concernés.
Intégration de l'API données : l'API données V2 introduit la pagination basée sur un curseur, des structures de réponse standardisées et des champs en snake_case. L'endpoint /v2/positions prend également en charge le filtrage des positions par statut, notamment les positions ouvertes, rachetables, fusionnables et fermées.

Ces modifications sont particulièrement pertinentes pour les systèmes de trading automatisés qui dépendent d'une exécution précise des ordres et d'une comptabilité de portefeuille. Les développeurs doivent tester les opérations de marché à la fois héritées et V2, y compris la récupération des soldes, la soumission des ordres et le règlement des positions. Les market makers doivent également s'assurer que leur logiciel sélectionne le bon contrat et les bonnes autorisations pour chaque transaction, car une erreur d'intégration pourrait interrompre le trading même si le marché sous-jacent reste opérationnel.

Marchés de prévisions futurs : Trading cross-chain et nouvelles fonctionnalités

Au-delà de la migration immédiate, le protocole Polymarket V2 fournit une infrastructure conçue pour prendre en charge les transferts de positions entre chaînes et des fonctionnalités de marché supplémentaires. Son architecture de pont documentée utilise le protocole d'interopérabilité interchaînes de Chainlink (CCIP) pour permettre le transfert des positions éligibles, des collatéraux et des résultats de résolution entre les réseaux pris en charge. Dans le cadre du modèle hub-et-rayons proposé, Polygon sert de réseau de résolution autoritaire, tandis que d'autres réseaux pourraient prendre en charge des activités de trading compatibles. Toutefois, le trading interchaînes général n'a pas été confirmé comme actif, et le mécanisme de pont documenté ne prend pas actuellement en charge tous les formats de position.

Polymarket a également identifié des fonctionnalités potentielles telles que la résolution scalaire et le retour directionnel des collatéraux, qui pourraient élargir la manière dont les marchés prédictifs futurs représentent les résultats et gèrent les collatéraux. La résolution scalaire pourrait permettre de soutenir des marchés impliquant des résultats numériques plutôt que uniquement des catégories fixes, bien que sa mise en œuvre et sa disponibilité restent soumises à un développement ultérieur. L'architecture modulaire pourrait faciliter l'intégration de futures ajouts, mais elle ne garantit pas une baisse des coûts de trading ou une amélioration de la liquidité. Ces résultats dépendront de la mise en œuvre réelle, de la participation du marché et des performances de l'infrastructure améliorée.

Conclusion

Le protocole Polymarket V2 introduit des modifications importantes à l'infrastructure de marché prédictif de la plateforme, notamment des positions unifiées ERC-1155, des contrats intelligents modulaires et des intégrations d'oracles supplémentaires. Cette mise à jour vise à simplifier une architecture de trading de plus en plus complexe tout en ouvrant la voie à de futurs formats de marché et à une fonctionnalité interchaînes.

L'accent immédiat reste sur le déploiement progressif. Le 2 novembre 2026 est une date de transition provisoire pour les nouveaux marchés créés, tandis que les positions CTF existantes ne seront pas automatiquement migrées. Les développeurs doivent également respecter une date limite antérieure de retrait de l'API Données V1, prévue le 24 octobre. Bien que l'architecture offre une plus grande flexibilité, ses effets sur les performances de trading, la liquidité et les coûts opérationnels ne deviendront clairs qu'après un déploiement plus large. Pour les traders et les développeurs, comprendre ces distinctions est plus utile que d'assumer que tous les marchés changeront en même temps.

🔥 Au-delà des titres : ce que KuCoin 5.0 signifie pour vous

Les actualités du marché évoluent rapidement — mais où vous agissez dessus compte tout autant. Ce octobre, KuCoin lance KuCoin 5.0, transformant KuCoin en une plateforme entièrement重构. Voici ce qui change réellement pour vous :

Un seul compte pour tout. Les anciennes plateformes répartissaient votre argent entre des comptes séparés « spot », « marge » et « futures » et s'attendaient à ce que vous compreniez pourquoi. Le compte unifié de KuCoin 5.0 élimine complètement cela — déposez une fois, et tout est simplement disponible (actuellement uniquement disponible pour les VIP).
Actions, indices et matières premières. KuCoin 5.0 s'étend au-delà du crypto vers les marchés mondiaux. Lorsque le crypto stagne et que les actions progressent (ou l'inverse), vous effectuez une rotation en quelques minutes au lieu d'ouvrir un compte de courtage et d'attendre des jours pour les voies monétaires.
Actifs du monde réel (RWA). Une exposition tokenisée à des actifs traditionnels comme les matières premières, directement dans votre compte crypto. L’un des segments à la croissance la plus rapide de la finance mondiale n’est plus réservé aux institutions — vous y accédez depuis le même solde que celui que vous utilisez pour trader.
Gagnez tout en apprenant. Pas prêt à trader ? KCUSD permet à vos stablecoins de générer des intérêts quotidiens, avec un auto-compound. La manière la moins stressante de faire travailler vos dépôts inactifs pour un rendement de 4 %.
Un assistant IA en langage simple. Posez des questions, obtenez du contexte sur le marché, comprenez ce que vous voyez — intégré à la plateforme, aucun jargon requis.
Une application qui ne submerge pas. Plus rapide, plus propre et cohérente — intuitive dès le premier toucher, sans besoin de tutoriel.
Sécurité que vous pouvez vérifier, et non simplement confier. Une entité européenne autorisée MiCAR, Proof of Reserves que vous pouvez vérifier vous-même, et une sécurité certifiée au niveau international (SOC 2 Type II, ISO 27001:2022).

Créez votre compte en quelques minutes — et commencez sur la plateforme conçue pour où va la crypto, pas où elle en est venue.

FAQ

Les traders peuvent-ils vendre des positions Polymarket V2 avant la fin d'un événement ?

Oui. Les traders peuvent vendre des jetons de résultat avant la résolution du marché, à condition que le marché reste ouvert et qu’il existe un intérêt d’achat suffisant. Le prix de vente dépend des ordres disponibles et des conditions du marché. Étant donné que l’exécution des ordres sur les marchés de prévision dépend de la liquidité disponible, le prix final de vente peut différer du prix du marché affiché. Quitter tôt peut entraîner un profit ou une perte, quel que soit le résultat final de l’événement.

Comment les positions gagnantes sont-elles payées après la résolution d'un marché Polymarket V2 ?

Après résolution, les jetons du résultat gagnant peuvent être rachetés contre la garantie selon le paiement enregistré du marché. Dans un marché binaire standard, chaque part gagnante peut généralement être rachetée pour 1 pUSD, tandis que les parts perdantes n'ont aucune valeur de rachat. Certains marchés peuvent utiliser des paiements fractionnés, selon leurs règles de résolution.

Où les utilisateurs peuvent-ils vérifier les contrats intelligents Polymarket Protocol V2 ?

Les utilisateurs peuvent vérifier les adresses de contrats déployés via la documentation officielle des développeurs de Polymarket et examiner les transactions correspondantes sur PolygonScan. Le registre des contrats identifie les contrats de trading, de garantie, de gestion de position et de résolution. Lorsqu'un contrat utilise un proxy, les utilisateurs doivent se référer à l'adresse proxy documentée plutôt qu'à une adresse d'implémentation ou à un lien tiers non vérifié.

Le protocole Polymarket V2 a-t-il subi des audits de sécurité ?

Oui. Polymarket a publié des audits de sécurité réalisés par Cantina, Certora, Quantstamp, SigmaPrime, Zellic et Pashov. Certora a également effectué des travaux de vérification formelle, tandis qu'un programme de bug-bounty de Cantina offre des récompenses allant jusqu'à 5 millions de dollars pour des vulnérabilités critiques qualifiantes. Ces mesures renforcent l'évaluation de la sécurité, mais ne garantissent pas que toutes les vulnérabilités ont été identifiées.

Avertissement

Les informations fournies sur cette page peuvent provenir de sources tierces et ne reflètent pas nécessairement les vues ou opinions de KuCoin. Ce contenu est destiné uniquement à des fins d'information générale et ne doit pas être considéré comme un conseil financier, d'investissement ou professionnel. KuCoin ne garantit pas l'exactitude, l'exhaustivité ou la fiabilité des informations et n'est pas responsable des erreurs, omissions ou conséquences résultant de son utilisation. L'investissement dans des actifs numériques comporte des risques inhérents. Veuillez évaluer attentivement votre tolérance au risque et votre situation financière avant de prendre toute décision d'investissement. Pour plus de détails, veuillez consulter les Conditions d'utilisation et les Avertissements sur les risques de KuCoin.

Avertissement : Pour votre confort, cette page a été traduite à l'aide de la technologie IA. Pour obtenir les informations à la source, consultez la version anglaise originale.