Explication de la résolution sur Polymarket

Explication de la résolution sur Polymarket : ce guide parcourt le cycle de vie de bout en bout, du reporting à la rédemption des tokens d'issue, en passant par la phase de contestation de l'oracle optimiste UMA, et les implications pratiques pour les traders. Vous apprendrez ce qui se passe on-chain et off-chain, quelles étapes sont sans gaz pour les utilisateurs, et le calendrier et les risques qui importent pour l'arbitrage et la gestion de positions.

Points clés

• La résolution commence par un report d'issue et peut entrer dans une période de contestation optimiste UMA avant le règlement final.
• Bien que les tokens d'issue soient des actifs ERC-1155 CTF, les opérations de split/merge/redeem et la passation d'ordres sont sans gaz pour les utilisateurs via le Relayer.
• Les contestations, les délais oracle, les remplissages partiels et le calendrier de règlement créent des risques réels, même lorsque les prix impliquent un avantage mathématique.
• Connaissez la séquence : report → fenêtre de contestation (UMA) → finalisation → rédemption des tokens gagnants pour pUSD.

Ce que signifie « résolution » sur Polymarket

Sur Polymarket, la résolution est le processus qui transforme les tokens d'issue négociables en fonds échangeables. Pour les marchés binaires et à issues multiples, un oracle détermine en dernier ressort quelle(s) issue(s) se résolvent à YES. Lorsqu'une issue est finale, chaque token gagnant devient échangeable contre $1.00 de pUSD ; les tokens perdants n'ont pas de valeur.

Les marchés utilisent le Gnosis Conditional Token Framework (CTF) pour les tokens d'issue. Ces tokens se comportent comme tout actif ERC-1155 : vous pouvez les négocier sur le CLOB, les transférer, ou les combiner via des opérations de split/merge. La différence clé à la résolution est que le report final de l'oracle débloque le flux de rédemption CTF qui transforme les tokens gagnants en pUSD.

L'étape de reporting : qui reporte et pourquoi c'est important

La résolution commence lorsqu'un reporter soumet une issue au système d'oracle. Polymarket utilise l'oracle optimiste UMA pour le reporting. Un report soumis nomme l'issue que le reporter juge correcte et déclenche le compte à rebours pour l'étape suivante.

Pourquoi c'est important :

• Le report est le premier signal public que l'événement du marché a atteint un état pouvant être résolu. Les traders qui surveillent les carnets d'ordres peuvent réagir immédiatement.
• Les reports sont visibles dans l'interface de Polymarket et via le Gamma API, de sorte que les bots d'arbitrage et les traders humains peuvent les détecter de manière programmatique.

Fenêtre de contestation de l'oracle optimiste UMA (ce que c'est, pas sa durée)

Après la publication d'un report, le modèle optimiste d'UMA permet une fenêtre de contestation pendant laquelle des challengers peuvent déposer des éléments contradictoires. Si une contestation est lancée, le flux optimiste est mis en pause et UMA résout le désaccord selon son processus.

Points pratiques importants :

• La fenêtre de contestation introduit de l'incertitude. Un marché qui semble résolu peut être rouvert pour investigation si UMA reçoit une contestation.
• Parce que le calendrier exact et les détails d'implémentation des procédures d'UMA sont externes à Polymarket, les traders doivent considérer tout marché en phase de contestation ou proche de celle-ci comme portant un risque de résolution.

Note : l'invite système précise qu'UMA est utilisée mais ne fournit pas la durée de la fenêtre de contestation. Voir la section Notes pour cette lacune.

Finalisation et rédemption des tokens CTF

Une fois que le processus de l'oracle est terminé et que l'issue est finale, le marché est finalisé on-chain. À ce stade, les utilisateurs peuvent rédemper les tokens d'issue gagnants ERC-1155 contre pUSD via l'opération de redeem du CTF.

Concrètement sur Polymarket :

• Les opérations CTF (split / merge / redeem) sont gérées par le Polymarket Relayer, donc elles sont sans gaz pour vous.
• La rédemption transforme chaque token gagnant en $1.00 de pUSD, que vous pouvez ensuite retirer ou utiliser pour splitter en de nouvelles positions.

Si vous détenez un ensemble complet de tokens d'issue avant la résolution, la rédemption est simple : vous ne recevez du pUSD que pour la(les) issue(s) gagnante(s). Si vous détenez des positions partielles, seuls les tokens gagnants correspondants sont rédemptés.

Cas limites courants rencontrés par les traders

• Finalisations contestées : les contestations UMA peuvent retarder le règlement et empêcher temporairement la rédemption. Cela affecte la liquidité et peut immobiliser du capital.
• Remplissages partiels et exécution d'ordres : un ordre partiellement rempli avant la résolution peut vous laisser long sur certains tokens et short sur d'autres ; assurez-vous de suivre les remplissages pour éviter une exposition inattendue.
• Changement de tick-size et mises à jour de prix : les modifications de tick size près de la résolution peuvent modifier les ordres disponibles ; le WebSocket émet des événements tick_size_change qui importent pour les bots.
• Effets des frais et des récompenses : les maker fees sont nulles ; les taker fees varient selon la catégorie. Les frais et l'attribution Builder (si vous routez via un Builder) affectent les résultats nets mais ne changent pas le processus de règlement de l'oracle.

Ne supposez jamais qu'un marché réglé ne peut pas être rouvert si UMA déclenche un flux de contestation. Confirmez toujours le statut du marché avant d'initier toute opération de redeem CTF ou des transferts importants.

Comment cela affecte l'arbitrage et les stratégies endgame

Pour l'arbitrage intra-market (acheter un ensemble lorsque Σ bestAsk < $1.00), la mécanique de résolution est centrale : votre profit théorique se convertit en pUSD uniquement après la finalisation et la rédemption. Cela signifie que le timing, le risque de contestation de l'oracle et les délais de règlement importent autant que l'exécution d'ordres.

Règles pratiques :

• Considérez le spread comme un edge mathématique seulement après avoir pris en compte les frais, le slippage et les risques de contestation. Énumérez toujours ces risques avant de qualifier un trade d'arbitrage.
• Pour les stratégies endgame (prix proches de la résolution comme $0.95–$0.99), soyez particulièrement prudent : des marges plus faibles et des contestations UMA peuvent transformer un jeu court terme en perte.
• Utilisez les APIs de Polymarket et le Market WebSocket pour surveiller en temps réel les reports, tick_size_change, best_bid_ask et last_trade_price.

Surveillance de la résolution de façon programmatique

APIs et flux à surveiller :

• Gamma API (https://gamma-api.polymarket.com) : métadonnées de marché et d'événement, y compris les champs liés à la résolution. Utilisez le endpoint /markets avec pagination basée sur les curseurs.
• Data API (https://data-api.polymarket.com) : positions, trades et open interest pour suivre les remplissages et l'exposition.
• Market WebSocket (wss://ws-subscriptions-clob.polymarket.com/ws/market) : carnet en temps réel, price_change, best_bid_ask, last_trade_price et tick_size_change. PING toutes les 10s ; abonnez-vous avec custom_feature_enabled pour obtenir best_bid_ask.

Combinez ces flux pour détecter un report, surveiller les signaux de contestation UMA dans l'UI ou les flux de données, et attendez la finalisation du statut du marché avant de faire le comptage final.

Checklist : quoi faire lorsqu'un marché est reporté

• Confirmez l'issue reportée dans Gamma et l'interface Polymarket.
• Mettez en pause l'automatisation qui suppose une finalité immédiate jusqu'à la fin de la phase de contestation d'UMA.
• Suivez les ordres ouverts et les remplissages ; annulez ou ajustez si nécessaire pour éviter une exposition non souhaitée.
• Après la finalisation, rédempez les tokens gagnants via l'UI, le SDK ou votre flux intégré au Relayer.

Comment cela affecte votre trading

La résolution est le goulot d'étranglement final entre l'exécution d'un trade et le pUSD réalisé. Pour les traders actifs et les arbitragistes, cela signifie que vous devez gérer trois risques liés : l'exécution (remplissages et slippage), la résolution de l'oracle (reports et contestations), et le calendrier de règlement (rédemption et retraits). Une exécution réussie nécessite à la fois des outils rapides côté marché et des hypothèses conservatrices sur le risque de contestation.

Si vous construisez de l'automatisation, consignez chaque remplissage et surveillez les canaux WebSocket listés ci-dessus. Traitez les marchés en phase de report ou proches de celle-ci comme plus risqués jusqu'à ce qu'UMA les ait levés.

Note de clôture : « Explication de la résolution sur Polymarket » devrait vous donner la checklist opérationnelle et le modèle mental pour gérer le risque de règlement. Utilisez les APIs et le WebSocket pour surveiller les événements, rappelez-vous que la rédemption CTF est sans gaz via le Relayer, et tenez toujours compte des fenêtres de contestation avant de supposer qu'un trade s'est converti en pUSD.

Questions fréquentes

Qui reporte les issues sur Polymarket ?

Polymarket utilise l'oracle optimiste UMA pour le reporting. Les reports sont soumis à UMA et sont visibles dans l'UI et les APIs de Polymarket ; UMA gère les contestations ultérieures selon son processus.

Que se passe-t-il pendant la fenêtre de contestation UMA ?

Après un report, UMA autorise une période de contestation pendant laquelle des challengers peuvent contester l'issue reportée. Si une contestation est déposée, UMA met en pause le règlement optimiste et suit son flux de résolution des contestations, ce qui peut retarder la rédemption des tokens gagnants.

Les opérations CTF sont-elles sans gaz sur Polymarket ?

Oui. Polymarket sponsorise le gaz via son Relayer. Split, merge, redeem, transferts et passation d'ordres sont sans gaz pour l'utilisateur final parce qu'ils sont routés via le Relayer.

Un marché peut-il être rouvert après avoir semblé résolu ?

Oui. Si UMA reçoit une contestation, un marché qui semblait résolu peut être rouvert ou retardé en attendant la résolution d'UMA. Considérez tout marché en phase de contestation ou proche de celle-ci comme portant un risque de résolution.

Comment détecter de façon programmatique un report ou une contestation ?

Utilisez le Gamma API pour les métadonnées de marché et le Market WebSocket (wss://ws-subscriptions-clob.polymarket.com/ws/market) pour les événements en temps réel comme price_change, best_bid_ask, last_trade_price et tick_size_change. Combinez ces flux avec les endpoints du Data API pour surveiller les positions et les remplissages.