pUSD et Protocol V2 de Polymarket expliqués

Deux mises à niveau aux noms proches se confondent facilement. CLOB V2 a changé la plateforme d’échange, le backend des ordres et le jeton de collatéral. Protocol V2 a ajouté une seconde façon de détenir des positions sur les résultats. Ce guide explique les deux à partir de la documentation de Polymarket, garde le détail pour développeurs court et signale où les pages se taisent ou se contredisent. Une chronologie datée des entrées du changelog fait l’objet d’un article à part.

Qu’est-ce que le pUSD ?

La documentation de Polymarket décrit le pUSD comme le jeton de collatéral de tout le trading sur Polymarket. Techniquement, c’est un jeton ERC-20 sur Polygon adossé à l’USDC. ERC-20 est un standard de jeton, et la documentation parle d’un wrapper qui représente une créance sur de l’USDC. Le smart contract garantit l’adossement, et la page précise : pas d’ancrage algorithmique et pas de réserve fractionnaire. Une paire complète de jetons Oui et Non d’un marché est adossée à 1 pUSD de valeur.

Le pUSD peut se transférer comme n’importe quel jeton ERC-20, mais il est conçu pour fonctionner à l’intérieur de Polymarket : selon la documentation, il n’existe aucun projet à ce jour de le coter sur des bourses extérieures. Polymarket Perps utilise le même jeton, puisque le collatéral de Perps est pUSD (voir le guide Perps).

Pourquoi Polymarket l’a-t-il introduit ?

La documentation donne une raison brève : un règlement en USDC natif, qu’elle présente comme un standard plus efficace en capital, plus évolutif et mieux aligné sur les institutions à mesure que la plateforme grandit. Avant le pUSD, le collatéral était l’USDC.e, la forme pontée de l’USDC, et le pUSD l’a remplacé. Les pages ne comparent pas les deux jetons et n’en disent pas davantage sur cette décision.

Comment obtenir du pUSD ?

Cela dépend de votre façon d’utiliser Polymarket.

• Sur polymarket.com. L’interface enveloppe vos fonds automatiquement après une approbation unique. Ensuite, vous voyez simplement un solde et vous tradez.
• Par un dépôt. Le bridge s’occupe de la conversion : les actifs d’autres chaînes sont convertis automatiquement en pUSD sur Polygon. Vous pouvez envoyer de l’USDC natif ou de l’USDC.e ponté.
• Par les contrats. La documentation nomme deux groupes qui font le wrap à la main, les utilisateurs avancés et les traders qui passent uniquement par l’API, et qui vont envelopper de l’USDC.e en pUSD via le contrat Collateral Onramp. Elle ne décrit pas d’autres interfaces.

Dans l’autre sens, un retrait reconvertit le pUSD par le Collateral Offramp, et vous pouvez aussi retirer du pUSD tel quel, bien que certaines plateformes d’échange n’acceptent plus les dépôts directs de pUSD. Côté frais, la page Fees indique que Polymarket n’applique aucun frais pour déposer ou retirer de l’USDC, et la page Withdraw indique que Polymarket ne facture pas de frais de retrait ; un service que vous empruntez en chemin peut facturer les siens.

Quel type de wallet un compte utilise-t-il ?

La page Wallets indique qu’un Deposit Wallet est le choix par défaut et que tous les wallets de compte déployés à partir du 4 mai 2026 en utilisent un, les wallets Proxy et Safe étant des types hérités. Polymarket 101 le formule plus étroitement : les nouveaux utilisateurs de l’API utilisent des deposit wallets, et les wallets Safe et Proxy restent pris en charge pour les personnes et les intégrations qui les utilisent déjà. La page Contracts ajoute que le pUSD et les wallets de compte Polymarket fonctionnent avec les deux systèmes de positions, présentés plus bas.

Qu’a changé CLOB V2 ?

CLOB V2 est la mise à niveau qui a introduit le pUSD. Le changelog de Polymarket la décrit comme une mise à niveau coordonnée, avec de nouveaux contrats d’échange, un backend CLOB reconstruit et le pUSD comme nouveau jeton de collatéral. Elle est entrée en service le 28 avril 2026 vers 11:00 UTC, et le trading a été suspendu pendant environ 1 heure. Pour les traders, les effets visibles ont été les suivants :

• Les ordres ouverts ont été effacés : tout ce qui attendait avant la bascule a dû être passé de nouveau.
• Les frais sont fixés par le protocole au moment de l’appariement au lieu de faire partie de l’ordre signé. Le guide des frais donne les taux.
• L’attribution des builders passe désormais par un champ builder code facultatif sur l’ordre. Le guide de migration précise que les builder codes permettent l’attribution et le partage des revenus avec les intégrateurs.

Qu’est-ce que Protocol V2 ?

Protocol V2 est un changement différent de CLOB V2, et ses pages de migration partent d’intégrations qui utilisent déjà le pUSD et le format d’ordre CTF Exchange V2. La documentation dit qu’il introduit de nouveaux jetons de position, ainsi que de nouveaux contrats pour le trading, les opérations sur positions et la résolution. Une particularité de nommage : la page Contracts place sur le jeton pUSD et ses contrats Onramp et Offramp le même badge Poly v2 que sur PositionManager, alors que le changelog et le guide de migration rattachent le pUSD à la mise en service de CLOB V2, lecture que ce guide suit.

Le cœur de Protocol V2 est un second registre pour les positions sur les résultats. Les marchés bâtis sur le Conditional Tokens Framework (CTF) tiennent leurs soldes Oui et Non dans le contrat Conditional Tokens. Les marchés Protocol V2 les tiennent dans un contrat nommé PositionManager, qui transmet chaque opération à un module : BinaryModule pour un marché Oui/Non simple, NegRiskModule pour les événements à plusieurs résultats et CombinatorialModule pour les positions construites à partir d’un ensemble de jambes. Les positions combinatoires, qui combinent plusieurs résultats existants en une nouvelle paire Oui et Non, utilisent Protocol V2 plutôt que le Conditional Tokens Framework. Les ordres sur positions V2 se règlent par un contrat d’échange distinct, ExchangeV3, et les splits, merges et remboursements passent par un contrat appelé Router.

Protocol V2 touche aussi la résolution. Polymarket 101 dit que les marchés V2 peuvent aussi utiliser d’autres mécanismes de résolution. La page Contracts montre le chemin : les résultats vont des modules de reporters, via un OracleAggregator, au module qui possède la condition, avec des modules de reporters nommés OO, Chainlink et EOA. Les données de résolution nomment un reporter pour chaque condition résolue : UMA_OO, CHAINLINK ou EOA. Les pages ne développent ni « OO » ni « EOA » et n’indiquent pas quels marchés utilisent quel reporter. Le guide de la résolution traite en détail le parcours UMA.

Quel rapport entre les deux systèmes de positions ?

Les deux systèmes de positions sur Polymarket. Source: docs.polymarket.com/trading/positions/how-positions-work, vérifié 19 octobre 2026.

Les deux systèmes détiennent les résultats Oui et Non sous forme de jetons ERC-1155 (le standard que la page 101 cite pour les parts de résultat), et la documentation dit que ces soldes signifient la même chose économiquement pour un trader. Diviser du pUSD en une paire Oui et Non (split), refusionner une paire (merge) et être payé après la résolution (redeem) existent dans les deux, par des contrats différents. La page How Positions Work avertit que un CTF token ID ne doit pas être envoyé à PositionManager, ni un Position ID à Conditional Tokens ; elle précise que la découverte de marché fournit les identifiants dont chaque flux a besoin.

Qu’advient-il de ce que vous détenez déjà ? L’aperçu indique que les avoirs CTF existants ne sont pas convertis, et la page de migration des contrats ajoute que mettre à jour une intégration ne convertit pas les soldes CTF existants. La page Contracts décrit aussi un chemin de migration des positions CTF vers PositionManager, mais Polymarket doit d’abord enregistrer la condition ou l’événement, et les pages ne disent ni qui peut l’utiliser ni quand. Pour les utilisateurs de l’application et du site Polymarket, l’aperçu dit que aucune migration technique n’est requise, hormis valider les demandes d’approbation qui s’affichent.

Ce qui a changé pour les traders, et ce qui n’a pas changé

Ce qui a changé

• Le collatéral est le pUSD au lieu de l’USDC.e : les soldes, les coûts d’ordre et les paiements sont donc en pUSD.
• Certains marchés gardent leurs positions sur le registre Protocol V2, et l’application Polymarket peut afficher des demandes d’approbation.

Ce qui est resté pareil

• La page pUSD de Polymarket le dit ainsi : au quotidien, rien ne change. Vous déposez, consultez un solde, tradez et retirez toujours de la même façon.
• Une part gagnante est toujours remboursée à $1.00 chacun et une part perdante ne vaut plus rien, quel que soit le système qui la détient.
• La page Prices & Orderbook indique que le carnet d’ordres est partagé entre les marchés, tandis que la voie de règlement dépend du système qui détient les jetons.
• Pour les intégrations déjà sur le pUSD, l’aperçu indique que, sous Protocol V2, le collatéral, les wallets, les identifiants CLOB et les points d’accès restent inchangés.

À vérifier sur la page d’un marché

• Les règles de résolution. Elles définissent comment le marché se résout, et certains marchés peuvent utiliser d’autres mécanismes qu’UMA. Voir le guide de la résolution.
• L’unité. Les soldes, les coûts d’ordre et les paiements sont en pUSD, et non en USDC.e, tandis que un ordre à cours limité est passé avec un prix et un nombre de parts.
• Les demandes d’approbation. L’aperçu demande aux utilisateurs de l’application et du site Polymarket de valider les demandes d’approbation qui s’affichent. Les pages ne disent pas ce que ces demandes autorisent.
• La version, si vous lisez des données. Les données de marché de l’API Gamma portent une version, « v1 » pour les marchés CTF et « v2 » pour les marchés Protocol V2. Le conseil de la documentation est de lire le champ version du marché, car la présence d’un champ ID ne l’indique pas. Les pages utilisées pour ce guide ne disent pas que l’application Polymarket l’affiche.
• Les avis officiels. Le changelog et la page de statut annoncent les changements et les incidents ; l’article chronologique liste les entrées datées du changelog.

Pour les développeurs

Les développeurs avaient plus à faire. Pour CLOB V2, la production ne prend plus en charge les anciens SDK V1 et les ordres signés en V1, et la structure des ordres ainsi que le domaine de signature ont changé ; le guide Migrating to CLOB V2 donne les détails. Pour Protocol V2, Polymarket publie des pages de migration pour les intégrations SDK, API et smart contracts, toutes accessibles depuis l’aperçu. En bref, vous choisissez les identifiants selon la version du marché, vous accordez de nouvelles approbations parce que les autorisations CTF existantes ne sont pas reprises dans V2, vous signez les ordres V2 pour l’échange V2 et vous conservez la prise en charge CTF pour les marchés CTF. Ce guide s’arrête là volontairement.

PolyTerminal est une interface indépendante pour Polymarket et n’est ni exploitée ni approuvée par Polymarket. Les ordres passés via PolyTerminal portent le builder code Polymarket de PolyTerminal, et PolyTerminal peut facturer un builder fee en plus des frais propres à Polymarket. Cette page est pédagogique et ne constitue pas un conseil en investissement. Les règles ont été comparées à la documentation officielle le 19 octobre 2026 ; vérifiez la source avant d’agir sur un chiffre.