Polymarket a commencé les tests de production du Protocole V2 en amont d'un passage provisoire au 2 novembre pour les marchés nouvellement créés, remplaçant son architecture de marché Gnosis CTF datant de 2019 par un système de positions ERC-1155 unique, une garantie pUSD et une résolution modulaire.
Résumé
- Le Protocole V2 de Polymarket commencera à gérer les nouveaux marchés le 2 novembre après les tests canari d'octobre.
- V2 remplace les adaptateurs Gnosis CTF hérités par un système de positions ERC-1155 unique et une garantie pUSD unifiée.
- UMA et Chainlink peuvent fournir les résultats via la nouvelle couche de règlement modulaire OracleAggregator de Polymarket pour les marchés.
- Polymarket indique que les avoirs CTF existants resteront inchangés tandis que les nouvelles positions V2 utiliseront des contrats séparés.
- L'API de données V1 prend fin le 24 octobre, laissant aux développeurs neuf jours avant le passage prévu à V2.
Le responsable du protocole de Polymarket, Rajath Alex, a déclaré le 5 octobre que les marchés canari fonctionneraient en production jusqu'au 30 octobre avant que les marchés entièrement nouveaux ne commencent « provisoirement » à migrer vers le Protocole V2 le 2 novembre. Les marchés et positions CTF existants ne migreront pas automatiquement vers les nouveaux contrats.
Polymarket V2 reconstruit la façon dont les positions sont créées
Le système de marché existant de Polymarket remonte au Conditional Tokens Framework de Gnosis de 2019. Au fur et à mesure de l'introduction de nouveaux formats de marché, des adaptateurs et contrats distincts ont été ajoutés pour des fonctions telles que les marchés à risque négatif, la gestion des garanties et la résolution.
Le Protocole V2 supprime une grande partie de cette structure. Le dépôt de code officiel de Polymarket décrit V2 comme son « système de contrats intelligents de marché de prédiction de nouvelle génération », avec des jetons de position ERC-1155, la gestion des garanties, des oracles modulaires, la correspondance d'ordres et des fonctions inter-chaînes.
Les identifiants de position encodent désormais directement dans l'identifiant du jeton des informations telles que le module, la condition et le résultat. Le système utilise un contrat PositionManager commun et un Router, avec des modules distincts gérant différentes structures de marché.
Les modules initiaux couvrent les marchés binaires, les marchés à risque négatif atomiques, les marchés à risque négatif incrémentiels et les marchés combinatoires. La liste de déploiement Polygon publiée par Polymarket montre que le PositionManager, l'Exchange, le Router et chacun de ces modules sont déjà déployés sur le réseau principal.
La version d'octobre ne doit pas être confondue avec la mise à niveau antérieure CLOB v2 de Polymarket. Comme précédemment rapporté dans la couverture par crypto.news du déploiement de CLOB v2 de Polymarket, la mise à niveau d'avril a modifié les contrats d'échange, le moteur de correspondance et la garantie tout en introduisant pUSD pour le trading. Le Protocole V2 modifie l'infrastructure de positions et de marché sous-jacente à ce système de trading.
pUSD devient la garantie commune à travers les marchés V2
Le Protocole V2 de Polymarket utilise Polymarket USD, ou pUSD, comme actif de garantie commun à travers les nouveaux modules de marché.
La documentation officielle des contrats indique que pUSD est un jeton ERC-20 encapsulant USDC et USDC.e à un ratio de 1:1 via un coffre externe. Le code exige que la somme des USDC et USDC.e détenus par le coffre soit égale ou supérieure à l'offre de pUSD en circulation.
Le jeton lui-même n'est pas nouveau. pUSD est apparu avec les changements d'échange plus tôt en 2026, mais le Protocole V2 en fait la garantie commune utilisée par ses modules de marché. Les intégrations existantes utilisant déjà pUSD n'ont pas besoin de remplacer leur configuration de garantie lors de l'ajout du support V2, selon le guide de migration de Polymarket.
Pour les développeurs, les positions changent. Les soldes V2 résident dans le nouveau PositionManager, tandis que les fractionnements, fusions et rachats passent par le Router. Les approbations CTF existantes ne sont pas transférées, donc les intégrations ont besoin de nouvelles autorisations pour les opérations V2.
Polymarket indique explicitement aux développeurs de conserver le support CTF pour les marchés et avoirs plus anciens. Sa documentation de migration indique que les avoirs CTF existants ne sont pas convertis lorsqu'une intégration ajoute le Protocole V2.
UMA et Chainlink peuvent régler les marchés via une seule couche
La résolution fait l'objet d'une refonte distincte via le nouvel OracleAggregator.
Le code V2 de Polymarket montre que l'OracleAggregator se situe au-dessus de modules enfichables de rapporteur, de litige et d'arbitrage. Les contrats de rapporteur actuels incluent un module UMA Optimistic Oracle, un rapporteur Chainlink et un rapporteur EOA.
Le module UMA peut transmettre les résultats UMA réglés dans l'agrégateur en tant que votes de rapporteur. Le module de Chainlink gère la résolution basée sur les prix à l'aide de Chainlink Data Streams, selon la documentation contractuelle publiée. Différents modules de rapporteur peuvent être combinés sous des seuils définis pour des marchés individuels.
Polymarket avait déjà introduit Chainlink pour certains marchés objectifs. Dans la couverture connexe de crypto.news sur l'intégration de Chainlink, la plateforme utilisait Chainlink Data Streams et Automation pour régler les marchés de prix de crypto en utilisant des données de marché externes.
UMA reste pertinent pour les marchés nécessitant une résolution basée sur des événements. Crypto.news a documenté séparément comment UMA résout les marchés de prédiction Polymarket et comment les litiges peuvent progresser dans son processus de contestation. Le protocole V2 ne remplace pas simplement UMA par Chainlink. Son OracleAggregator permet à différentes sources de résolution de se connecter au même cadre.
Les contrats V2 contiennent également une infrastructure inter-chaînes. La documentation du bridge de Polymarket indique que les positions, le collatéral et les résultats de résolution peuvent circuler via une couche de transport dont l'implémentation actuelle utilise Chainlink CCIP. Polygon reste le hub de résolution dans la conception mainnet publiée.
Aucune date n'a été annoncée pour une activation multi-chaînes. Le code du bridge établit la structure technique, mais le plan de migration du 2 novembre concerne les nouveaux marchés V2 et n'annonce pas en soi la négociation sur des chaînes supplémentaires.
Les contrôles de sécurité couvrent les nouveaux contrats Polymarket
Polymarket a publié un dossier de sécurité détaillé pour le protocole V2 avant la migration prévue. Son dépôt officiel de sécurité des contrats répertorie les examens par Cantina, Certora, Quantstamp, Pashov, Sigma Prime et Zellic sur les principaux composants V2. Le dépôt répertorie les travaux de vérification formelle de Certora couvrant l'Exchange, le Collateral Token, le Position Manager, le Binary Module, le NegRisk Module, le Combinatorial Module et l'OracleAggregator.
Alex a déclaré que les vulnérabilités critiques restent éligibles à des récompenses allant jusqu'à 5 millions de dollars dans le cadre du programme de bug bounty de Polymarket. Le bounty a été lancé plus tôt en 2026 et couvre les contrats intelligents et d'autres parties de la pile technologique de la plateforme.
La période canari offre aux développeurs et aux teneurs de marché un environnement de production pour tester avant la transition prévue du 2 novembre. Alex a déclaré que le déploiement limité s'étend du 5 octobre au 30 octobre, les nouveaux marchés devant commencer à utiliser V2 par la suite si le calendrier est respecté.
Les développeurs font face à une échéance plus précoce le 24 octobre
Une migration distincte est déjà en cours pour l'API Data de Polymarket. La documentation officielle de Polymarket indique que l'API Data V1 sera retirée le 24 octobre 2026, obligeant les intégrations existantes à passer aux routes V2 avant cette date. Le nouveau système utilise une structure de réponse partagée, une pagination basée sur un curseur et des champs en snake_case.
L'API Data V2 consolide plusieurs routes de positions dans /v2/positions et ajoute des points de terminaison couvrant le profit et la perte de l'utilisateur, le volume, l'historique des prix, les résolutions et l'état du service. La pagination par curseur supprime l'ancienne limite de décalage de 10 000 lignes utilisée par V1.
Pour les utilisateurs réguliers de l'application et du site web, Polymarket indique qu'aucune migration technique n'est requise. Les utilisateurs peuvent rencontrer de nouvelles invites d'approbation lors de l'interaction avec les marchés V2, tandis que les développeurs et les intégrations de contrats intelligents doivent prendre en charge à la fois les positions V2 et les avoirs CTF hérités.
Le calendrier actuel donne aux développeurs d'API jusqu'au 24 octobre pour quitter l'API Data V1, maintient les marchés canari du protocole V2 en fonctionnement jusqu'au 30 octobre, et fixe le 2 novembre comme date provisoire à laquelle les marchés nouvellement créés commencent à utiliser le protocole V2.
