Les conséquences diffèrent selon que l'on utilise l'application ou que l'on développe un service connecté à la plateforme. Le guide officiel de migration précise que les utilisateurs du site et de l'application n'ont aucune migration technique à effectuer. Les développeurs doivent, eux, intégrer les nouveaux contrats tout en conservant la prise en charge de l'ancien Conditional Tokens Framework, ou CTF.
Des tests en conditions réelles, à périmètre limité
Selon Unchained, dans son article du 6 octobre, le responsable du protocole Rajath Alex a annoncé le lancement des marchés pilotes le 5 octobre. Ces essais doivent se poursuivre jusqu'au 30 octobre, avant une bascule provisoirement prévue le 2 novembre pour les marchés nouvellement créés.
Ce déploiement progressif, dit canary, permet d'observer le nouveau système dans son environnement réel avec un périmètre restreint. Il ne signifie pas que l'ensemble des marchés a déjà changé de contrats.
La documentation précise que l'ajout du support de V2 ne convertit pas les positions CTF existantes. Pour un détenteur, la question utile reste donc de savoir dans quel système son solde est enregistré. Une application externe qui ne lirait plus que V2 ne couvrirait pas correctement les anciennes positions.
Ce qui change sous l'interface de négociation
La liste officielle des contrats situe le déploiement sur Polygon. PositionManager enregistre les soldes des positions ERC-1155. Des modules distincts prennent en charge les structures de marché, tandis que Router coordonne les opérations sur ces positions.
La norme ERC-1155 permet de gérer plusieurs types de jetons au sein d'un même contrat. Ici, ces jetons représentent les résultats possibles d'événements. La mutualisation de l'infrastructure ne fusionne donc pas tous les événements en un seul marché.
Il faut également distinguer une position de son collatéral. Polymarket décrit pUSD comme son jeton de règlement adossé à USDC. Il existait avant cette annonce d'octobre: le journal officiel des modifications documente son introduction avec CLOB V2, mis en production en avril. Protocol V2 renouvelle cette fois l'infrastructure des positions.
Les anciennes autorisations ne sont pas reconduites
Les instructions de migration des contrats prévoient de nouvelles autorisations pour les opérations V2. Les permissions accordées à CTF ne sont pas automatiquement valables pour les nouveaux contrats. Chaque intégration doit choisir le registre de positions et les contrats adaptés à la version du marché.
L'utilisateur de l'application peut ainsi rencontrer une nouvelle demande d'autorisation. Il doit vérifier la permission demandée et s'assurer qu'elle apparaît dans l'application officielle. Une annonce de migration ne justifie pas d'envoyer des jetons à une adresse reçue par message ou trouvée dans un article.
Le maintien des deux systèmes compte aussi pour le suivi du portefeuille. Un ancien solde ne doit pas disparaître de l'affichage simplement parce qu'un service a commencé à consulter uniquement les nouveaux contrats.
Une échéance distincte pour la Data API
Le guide de la Data API fixe au 24 octobre 2026 le retrait des routes v1 concernées. Il exclut expressément la route d'instantané comptable, qui ne possède pas d'équivalent en v2.
Les formats de réponse et la pagination changent. Les développeurs doivent donc vérifier leur intégration des données séparément de leur connexion de négociation. Cette échéance ne se confond pas avec le calendrier provisoire des nouveaux marchés.
Trois dates correspondent à trois étapes: le 24 octobre pour l'API, le 30 octobre pour la fin annoncée des tests, puis provisoirement le 2 novembre pour les nouveaux marchés. Aucune n'impose, à elle seule, le transfert manuel des positions existantes.
