Polymarket V2 pourrait changer la façon dont les utilisateurs parient sur des événements

Polymarket a commencé les tests de production du Protocole V2 avant un passage provisoire au 2 novembre pour les marchés nouvellement créés, remplaçant son architecture de marché Gnosis CTF de 2019 par un système de position ERC-1155 unique, un collatéral pUSD et une résolution modulaire. Résumé

• Le Protocole Polymarket V2 commencera à gérer de nouveaux marchés le 2 novembre après des tests canari en octobre.
• V2 remplace les adaptateurs Gnosis CTF hérités par un système de position ERC-1155 et un collatéral pUSD unifié.
• UMA et Chainlink peuvent fournir des résultats via la nouvelle couche de règlement OracleAggregator de Polymarket pour les marchés.
• Polymarket affirme 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 sera retirée le 24 octobre, donnant aux développeurs neuf jours avant le passage prévu à V2.

Le responsable du protocole Polymarket, Rajath Alex, a déclaré le 5 octobre que les marchés canari fonctionneraient en production jusqu'au 30 octobre avant que de nouveaux marchés "provisoirement" ne commencent à passer au 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 Cadre des Tokens Conditionnels de Gnosis de 2019. À mesure que de nouveaux formats de marché étaient introduits, des adaptateurs et contrats séparés étaient ajoutés pour des fonctions telles que les marchés à risque négatif, la gestion des collatéraux 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 contrat intelligent de marché de prédiction de nouvelle génération", avec des tokens de position ERC-1155, la gestion des collatéraux, des oracles modulaires, le matching des ordres et des fonctions inter-chaînes.

Les ID de position codent désormais des informations incluant le module, la condition et le résultat directement dans l'identifiant du token. Le système utilise un contrat PositionManager commun et un Routeur, avec des modules séparés 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émentaux et les marchés combinatoires. La liste de déploiement Polygon publiée par Polymarket montre que le PositionManager, l'Échange, le Routeur et chacun de ces modules sont déjà déployés sur le mainnet.

La sortie d'octobre ne doit pas être confondue avec la mise à niveau CLOB v2 antérieure de Polymarket. Comme précédemment rapporté dans la couverture de crypto.news sur le déploiement de CLOB v2 de Polymarket, la mise à niveau d'avril a changé les contrats d'échange, le moteur de matching et le collatéral tout en introduisant le pUSD pour le trading. Le Protocole V2 change l'infrastructure de position et de marché sous ce système de trading.

pUSD devient le collatéral commun à travers les marchés V2

Le Protocole Polymarket V2 utilise le Polymarket USD, ou pUSD, comme son actif collatéral commun à travers les nouveaux modules de marché.

La documentation officielle des contrats indique que le pUSD est un token ERC-20 enveloppant l'USDC et l'USDC.e à un ratio de 1:1 via un coffre externe. Le code exige que l'USDC et l'USDC.e combinés détenus par le coffre soient égaux ou supérieurs à l'offre de pUSD en circulation.

Le token lui-même n'est pas nouveau. Le pUSD est arrivé avec les changements d'échange plus tôt en 2026, mais le Protocole V2 en fait le collatéral commun utilisé par ses modules de marché. Les intégrations existantes utilisant déjà le pUSD n'ont pas besoin de remplacer leur configuration de collatéral lors de l'ajout du support V2, selon le guide de migration de Polymarket.

Pour les développeurs, les positions changent. Les soldes V2 se trouvent dans le nouveau PositionManager, tandis que les divisions, fusions et rachats passent par le Routeur. 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 dit explicitement aux développeurs de conserver le support CTF pour les anciens marchés et avoirs. 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 à travers une seule couche

La résolution reçoit une nouvelle conception séparée à travers le nouvel OracleAggregator.

Le code V2 de Polymarket montre que l'OracleAggregator se situe au-dessus des modules de rapport, de litige et d'arbitrage pluggables. Les contrats de rapporteurs actuels incluent un module d'Oracle Optimiste UMA, un rapporteur Chainlink et un rapporteur EOA.

Le module UMA peut transmettre les résultats UMA réglés à l'agrégateur sous forme de votes de rapporteur. Le module de Chainlink gère la résolution basée sur les prix en utilisant les Flux de Données Chainlink, selon la documentation contractuelle publiée. Différents modules de rapporteurs 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 une couverture connexe de crypto.news sur l'intégration de Chainlink, la plateforme a utilisé les Flux de Données Chainlink et l'Automatisation pour régler les marchés de prix des cryptomonnaies 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 de Polymarket et comment les litiges peuvent passer par 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 brancher dans le même cadre.

Les contrats V2 contiennent également une infrastructure inter-chaînes. La documentation du pont de Polymarket indique que les positions, les garanties et les résultats de résolution peuvent circuler à travers une couche de transport dont l'implémentation actuelle utilise Chainlink CCIP. Polygon reste le hub de résolution dans le design de la mainnet publié.

Aucune date n'a été annoncée pour une activation multi-chaînes. Le code du pont établit la structure technique, mais le plan de migration du 2 novembre concerne de nouveaux marchés V2 et n'annonce pas à lui seul le trading sur des chaînes supplémentaires.

Les vérifications 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 liste les examens effectués par Cantina, Certora, Quantstamp, Pashov, Sigma Prime et Zellic sur les principaux composants V2. Le dépôt liste le travail de vérification formelle de Certora couvrant l'Échange, le Token de Garantie, le Gestionnaire de Position, le Module Binaire, le Module NegRisk, le Module Combinatoire et l'OracleAggregator.

Alex a déclaré que des vulnérabilités critiques restent éligibles à des récompenses allant jusqu'à 5 millions de dollars dans le cadre du programme de primes de bugs de Polymarket. La prime a été lancée plus tôt en 2026 et couvre les contrats intelligents et d'autres parties de la pile technologique de la plateforme.

La période de canari donne 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é se déroule du 5 octobre au 30 octobre, avec de nouveaux marchés devant commencer à utiliser V2 par la suite si le calendrier est respecté.

Les développeurs font face à une échéance anticipée au 24 octobre

Une migration distincte est déjà en cours pour l'API de Données de Polymarket. La documentation officielle de Polymarket indique que l'API de Données V1 sera retirée le 24 octobre 2026, nécessitant que les intégrations existantes passent 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 de Données V2 consolide plusieurs routes de position en /v2/positions et ajoute des points de terminaison couvrant le profit et la perte des utilisateurs, 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 d'applications et de sites 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 de Données 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 commenceront à utiliser le protocole V2.