Guide de migration Polymarket pUSD - USDC.e vers pUSD (avril 2026)

Chapitre 36 sur 36

Version courte

Le 28 avril 2026, Polymarket a migré son collatéral de règlement sur Polygon de USDC.e (le jeton USDC ponté, contrat 0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174) vers pUSD, une cryptomonnaie stable émise par Polymarket et rachetable à parité 1:1 contre l'USDC natif. Les traders de l'application web n'ont rien eu à faire - les soldes et les positions ont été convertis automatiquement au bloc instantané. Les opérateurs d'API et de bots doivent mettre à jour : l'adresse de l'actif collatéral dans chaque signature d'ordre CLOB a changé, les anciens ordres signés avec USDC.e ont été annulés, et py-clob-client 0.40 ou plus récent est requis. Ce guide vous accompagne à travers les changements exacts de code, de contrat et d'approbation nécessaires pour faire fonctionner un bot pendant et après la transition.

Partie 1: Trois cryptomonnaies stables, un Polygon

Avant la migration, trois cryptomonnaies stables adossées au USD existaient dans l'orbite de Polymarket sur Polygon. Connaître la différence est la première étape pour comprendre pourquoi Polymarket a changé de plateforme.

Polymarket a initialement choisi USDC.e parce que c'était la variante dominante de l'USDC sur Polygon au lancement en 2020. Circle a ensuite émis de l'USDC natif directement sur Polygon et a signalé la dépréciation éventuelle de la variante pontée. Continuer à régler chaque marché en USDC.e exposait Polymarket au risque rare mais réel d'une fermeture soudaine du pont. Migrer vers une cryptomonnaie stable contrôlée par Polymarket résout ce problème et ouvre de futures fonctionnalités produit (par exemple, la marge sur les contrats perpétuels, les dépôts dans les coffres, les reçus inter-chaînes) qui partagent la même unité de compte.

Partie 2 : Ce qu'est pUSD (et ce qu'il n'est pas)

pUSD est un jeton ERC-20 standard sur Polygon (ID de chaîne 137) avec 6 décimales, la même précision que USDC. Il ne peut être frappé que par le contrat du Trésor Polymarket et peut être échangé à tout moment à raison de 1:1 contre de l'USDC natif, sans frais de conversion (les frais de gas du réseau s'appliquent toujours). La réserve qui soutient pUSD est détenue dans des comptes séparés et fait l'objet d'un rapport mensuel avec une attestation d'un tiers.

pUSD n'est pas une cryptomonnaie stable algorithmique, n'est pas sur-collatéralisé en cryptomonnaies et ne rapporte pas de rendement. Si vous détenez du pUSD en dehors de Polymarket, considérez-le comme une reconnaissance de dette émise par Polymarket pour de l'USDC natif - utile sur la plateforme, rachetable sur demande, mais sans avantage à le conserver sur le long terme dans un portefeuille externe.

Partie 3 : Ce que les traders de l'application web ont vu

Si vous tradez uniquement via polymarket.com, la migration était invisible. Au bloc instantané du 28 avril 2026 :

• Chaque solde USDC.e détenu dans un portefeuille proxy Polymarket a été converti de manière atomique en pUSD à 1:1.
• Les positions ouvertes ont conservé la même valeur en dollars, les mêmes probabilités de résultat et la même échéance. Les identifiants des jetons conditionnels n'ont pas changé.
• Les ordres en attente libellés en USDC.e ont été annulés au moment du snapshot. Les nouveaux ordres après la migration sont signés automatiquement en pUSD.
• Les retraits vers des portefeuilles externes sont passés d'un envoi d'USDC.e à l'envoi de USDC natif (ou, sur demande, de pUSD brut - la plupart des utilisateurs n'en ont jamais besoin).

Aucune signature, transaction ni modification des paramètres n'était requise. Les ordres à cours limité en attente qui vous importaient devraient être remis manuellement après la migration; l'annulation était un événement ponctuel.

Partie 4 : Opérateurs d'API et de bots - changements critiques

C'est la partie qui fera planter un bot si vous n'agissez pas.

Mettre à niveau py-clob-client

Polymarket a publié py-clob-client 0.40.0 deux semaines avant le basculement, avec une prise en charge complète de pUSD. La branche 0.34.x a été retirée le lendemain de la migration.

# Passez à une version compatible avec pUSD
pip install --upgrade "py-clob-client>=0.40.0"

# Vérifiez l'actif de garantie configuré
python -c "from py_clob_client.constants import POLYGON; \
print('Adresse pUSD :', POLYGON.get('collateral'))"

Le nouveau SDK récupère l'adresse de garantie à partir de la configuration de la chaîne au démarrage, vous n'avez donc rien à coder en dur. Si vous avez forké ou figé une version plus ancienne, la solution la plus sûre est de supprimer le fichier de verrouillage, de réinstaller avec le dernier module de constantes, puis de relancer votre suite de tests.

Réapprouver les autorisations

Votre portefeuille proxy Polymarket a besoin d'une autorisation ERC-20 de votre compte de trading -> contrat CTF Exchange pour le jeton pUSD. L'ancienne autorisation pour USDC.e est toujours inscrite sur la chaîne, mais elle est totalement inutile : CLOB ne l'utilisera pas. Sans nouvelle autorisation pUSD, chaque ordre renvoie "INSUFFICIENT_ALLOWANCE".

from py_clob_client.client import ClobClient

client = ClobClient(
    host="https://clob.polymarket.com",
    chain_id=137,
    key=os.environ["POLY_PRIVATE_KEY"],
    funder=os.environ["POLY_FUNDER"],
    signature_type=1,  # POLY_PROXY pour les comptes Magic-link
)
client.set_api_creds(client.create_or_derive_api_creds())

# Une seule fois : approuver pUSD pour le contrat CTF Exchange
# (assistant ajouté dans py-clob-client 0.40)
client.update_balance_allowance(asset_type="COLLATERAL")

Actualiser les identifiants API

Les clés API existantes continuent de fonctionner, mais si vous avez dérivé des identifiants avant le 1er avril, vous devriez les faire tourner par précaution : la signature ECDSA L1 est désormais liée à un domaine qui inclut la nouvelle adresse de garantie. Le plus simple :

creds = client.create_or_derive_api_creds()  # re-dérivation idempotente
client.set_api_creds(creds)

# À enregistrer dans votre .env
print(creds.api_key, creds.api_secret, creds.api_passphrase)

Partie 5 - Vérifier votre bot après la migration

Exécutez ce test de fumée minimal avant de laisser une quelconque logique de dimensionnement s'appliquer à de l'argent réel :

# 1. Confirmer le solde pUSD sur le portefeuille proxy
from py_clob_client.client import ClobClient
client = ClobClient(...)  # comme ci-dessus
balance = client.get_balance_allowance(params={"asset_type": "COLLATERAL"})
print("Solde pUSD (brut) :", balance["balance"])
print("Autorisation vers l'exchange :", balance["allowance"])

# 2. Passer un ordre à cours limité de 1 $ bien loin du prix touché
from py_clob_client.clob_types import OrderArgs
order = client.create_order(OrderArgs(
    token_id=test_token_id,
    price=0.05,        # rien à voir avec le marché
    size=20,           # notionnel de 1 $ à 0.05 $
    side="BUY",
))
resp = client.post_order(order)
print(resp)

# 3. Annuler et confirmer
client.cancel(order_id=resp["orderID"])

Si les trois appels réussissent, votre intégration est bonne - le SDK a signé contre pUSD, l'autorisation est reconnue, et le registre des ordres est cohérent. Remontez progressivement en taille.

Partie 6 - Erreurs courantes et corrections

Partie 7 : Jetons conditionnels, IDs d'ordre et autres choses qui n'ont pas changé

Pour garder un périmètre de refonte honnête, voici la liste des identifiants qui restent stables pendant la migration :

• Contrat de jeton conditionnel (CTF) : adresse identique. Vos positions ERC-1155 YES / NO ne sont pas touchées.
• condition_id et question_id : déterministes à partir des paramètres du marché ; non affectés par le changement de garantie.
• token_id (issue) : dérivé de condition_id + index de l'issue ; inchangé.
• Adresse du portefeuille proxy Polymarket : même adresse ; même code de type Gnosis Safe.
• Clé API, secret API, phrase secrète API : toujours valides (rotation recommandée ; non obligatoire).
• Schémas WebSocket : identiques ; le nouveau champ asset indique "pUSD" au lieu de "USDC.e" dans les événements de remplissage.
• APIs Gamma et Data : non authentifiées, inchangées. Elles ne faisaient jamais référence directement au jeton de garantie.

Partie 8 : Implications fiscales et de tenue de livres

Dans la plupart des juridictions, la conversion automatique de USDC.e en pUSD est un échange de type similaire de cryptomonnaies stables indexées sur l’USD à 1:1 et ne génère aucun événement imposable. Votre prix de revient et votre durée de détention se reportent.

Cela dit, deux éléments de tenue de livres méritent votre attention :

1. Mettez à jour le schéma de votre grand livre. Tout outil fiscal, grand livre SQLite ou export pour comptable qui filtre les transactions Polygon par le contrat USDC.e passera silencieusement à côté de chaque transaction post-migration. Ajoutez l’adresse du contrat pUSD comme alias.
2. Annotez la conversion du snapshot. Même si elle n’est pas imposable dans la plupart des régimes, consignez explicitement la conversion dans vos registres : montant, bloc, horodatage et note indiquant qu’il s’agit d’une migration de cryptomonnaie stable de 1:1. Si votre juridiction la remet en question plus tard, vous voudrez une piste d’audit propre.

Les traders israéliens doivent consulter le Guide fiscal pour les obligations de déclaration spécifiques à l’ITA ; la migration elle-même ne modifie pas le traitement standard, mais le changement d’adresse du contrat compte pour les outils de déclaration automatisés.

Partie 9 : Conseils de pro de la part des opérateurs qui ont vécu la transition

Et ensuite ?

• Guide de l'API Polymarket - le guide complet de l'API, mis à jour pour pUSD
• Guide de dépôt - dépôt de USDC et réception de pUSD dans l'application
• Guide de retrait - retrait de pUSD en USDC natif vers un portefeuille externe
• Outils et ressources - tableaux de bord tiers désormais mis à jour pour pUSD
• Glossaire - définitions en langage simple de tous les termes utilisés ici