Polymarket V2 est lancé, les ordres fantômes sont-ils corrigés ?

Original | Odaily Planet Daily (@OdailyChina)

Author | Asher (@Asher_0210)

Hier soir, Polymarket est entré en mode maintenance, a suspendu les transactions et vidé le carnet d’ordres, puis a officiellement lancé CLOB V2.

Selon les divulgations officielles précédentes, cette mise à jour comprend de nouveaux contrats, un nouveau carnet d’ordres, un nouveau jeton de garantie Polymarket USD, et le SDK CLOB-Client version améliorée. Pour les utilisateurs, les changements tels que PUSD, SDK, et la structure des ordres ne seront peut-être pas immédiatement perceptibles. Ce qui mérite vraiment l’attention en premier lieu, ce sont les Ghost Fills, ou ce que la communauté appelle communément les “ordres fantômes”, un problème qui trouble Polymarket depuis longtemps.

V2 a effectivement traité ce problème. La mécanique nonce, qui était la plus vulnérable auparavant, a été supprimée, la structure des ordres et la méthode d’annulation ont également changé. Mais cela ne signifie pas que les ordres fantômes ont disparu complètement, car le mode de transaction principal de Polymarket reste le rapprochement hors chaîne et le règlement sur chaîne, et tant que ces deux étapes présentent un décalage temporel, des problèmes similaires seront difficiles à éliminer totalement.

Les ordres affichent une transaction réussie, pourquoi échoue-t-elle finalement ?

Les fameux ordres fantômes, en termes simples, sont des ordres qui semblent avoir été rapprochés avec succès hors chaîne, mais qui n’ont finalement pas été réglés sur la chaîne.

Polymarket utilise un rapprochement via un carnet d’ordres hors chaîne, puis effectue le règlement sur la chaîne. Les avantages de cette conception sont évidents : une vitesse de transaction plus rapide, des coûts moindres, et une meilleure adaptation aux marchés de prédiction à court terme, comme ceux de 5 minutes, à haute fréquence.

Le problème réside justement dans ce décalage temporel. Un ordre qui apparaît comme ayant été exécuté hors chaîne ne garantit pas que le règlement sur la chaîne sera réussi. Dans certains marchés à court cycle, l’utilisateur peut voir que l’ordre est marqué comme exécuté, pensant avoir acheté dans la bonne direction ; mais lorsque la transaction est réellement soumise sur la chaîne, le règlement échoue. Une transaction qui semblait terminée une seconde, peut être annulée par le système la suivante.

Pour l’utilisateur, cette expérience n’est pas simplement une erreur de traitement, mais une incertitude. On pense avoir acheté ou vendu, mais au final, la transaction ne se réalise pas ; lors d’un nouveau placement, le prix peut avoir changé, et l’opportunité de transaction peut être perdue.

Le problème de la version précédente, c’était le coût trop faible pour annuler

Dans V1, la vulnérabilité la plus exploitée des ordres fantômes venait de la mécanique incrementNonce. Le nonce peut être compris comme un identifiant d’état dans un ordre. À l’origine, il était destiné à aider le système à gérer les ordres, mais dans l’ancienne version, un attaquant pouvait utiliser incrementNonce pour faire échouer la validation d’un ordre d’une adresse spécifique lors du règlement sur la chaîne.

Cela donnait à l’attaquant un espace d’action basé sur le décalage temporel. Il pouvait d’abord faire en sorte que l’ordre soit rapproché hors chaîne, affichant “transaction effectuée” ; puis, avant que le règlement ne soit réellement soumis sur la chaîne, il pouvait mettre à jour le nonce pour faire échouer ces ordres. Résultat : une transaction qui semblait terminée n’était pas réellement finalisée sur la chaîne.

Le problème clé réside dans le fait que cette opération coûte très peu, mais peut affecter un lot d’ordres. L’attaquant n’a besoin que d’un faible coût en gas pour faire échouer la validation d’ordres qui devraient normalement aboutir lors du règlement. La front-end voit une transaction d’abord réussie, puis échouée, mais cela entraîne une instabilité dans le résultat final, et peut même faire manquer à l’utilisateur le prix ou l’opportunité initiale.

Les ordres fantômes ne sont pas simplement une erreur d’affichage côté front-end, ni un échec occasionnel sur la chaîne, mais ils affectent directement la confiance de l’utilisateur dans le résultat de la transaction.

V2 a corrigé le problème, mais pas de façon définitive

Le changement le plus crucial dans V2 est la suppression du mécanisme de nonce global. Autrement dit, la méthode qui consistait à influencer un lot d’anciens ordres via un seul incrementNonce a été bloquée. Par ailleurs, V2 a simplifié la structure des ordres, et le processus d’annulation s’appuie désormais sur un hash d’ordre plus granulaire. Comparé à la version précédente, la portée de l’impact d’une annulation est nettement réduite, rendant plus difficile pour un attaquant de perturber massivement des ordres avec un faible coût.

Cela constitue une réparation substantielle du problème des ordres fantômes. La faiblesse précédente était que le coût d’attaque était faible, et l’impact élevé, avec une barrière de reproduction peu élevée. Après V2, la voie la plus facilement exploitée a été bloquée. Si un attaquant veut continuer à créer des problèmes similaires, il devra dépenser plus, et dépendra davantage de la réponse spécifique du système. De plus, l’introduction de mécanismes comme pauseUser avec délai limite réduit aussi la possibilité d’abuser instantanément de certains changements d’état dans la fenêtre de rapprochement et de règlement.

Globalement, la direction de V2 est claire : traiter d’abord les vulnérabilités les plus facilement exploitées, puis réduire la rentabilité de telles attaques.

Mais cela ne signifie pas que le problème des ordres fantômes est complètement résolu. La raison en est que Polymarket n’a pas changé son mode fondamental de rapprochement hors chaîne et de règlement sur chaîne. Tant que les ordres ne seront pas rapprochés et réglés dans le même environnement, un décalage d’état existera toujours entre hors chaîne et sur chaîne. Les variations de solde, les autorisations, l’état des ordres, les annulations ou l’échec d’exécution du contrat peuvent faire qu’un ordre rapproché hors chaîne ne se concrétise pas sur la chaîne.

En d’autres termes, V2 résout les vulnérabilités les plus évidentes et faciles à exploiter dans l’ancienne version, mais ne change pas les conditions fondamentales qui génèrent les ordres fantômes.

Autres mises à jour, davantage pour renforcer le système de trading

Outre les ordres fantômes, V2 introduit également PUSD, SDK, et la signature 1271 :

• PUSD est une nouvelle stablecoin de garantie, Polymarket passant de USDC.e à Polymarket USD, supporté 1:1 par USDC. Les utilisateurs ne ressentent pas forcément la différence, mais la gestion des actifs sous-jacents sera plus cohérente ;
• Le nouveau SDK CLOB-Client est principalement destiné aux market makers, bots, et intégrateurs. Après V2, ces utilisateurs doivent mettre à jour leur client et signer à nouveau leurs ordres avec la nouvelle structure ;
• La prise en charge de la signature 1271 permet à des portefeuilles intelligents, multi-signatures, comptes institutionnels, et bots plus complexes d’accéder plus facilement à Polymarket.

En résumé, Polymarket ne se contente pas de corriger une faille, mais cherche à transformer son système, passant d’une simple plateforme de marché de prédiction à une infrastructure plus proche d’un échange. Avec l’augmentation du nombre de market makers, d’API et de traders automatisés, la stabilité des transactions, le règlement et la liquidité deviennent plus importants que la “divertissement” du marché.

V2 n’est pas la fin, mais le début d’un processus d’amélioration continue

Après le lancement de V2, Polymarket a au moins bloqué la voie la plus évidente pour exploiter les ordres fantômes. La méthode de retrait à faible coût et d’impact massif sur les ordres est désormais difficile à reproduire tel quel. Pour une plateforme en pleine croissance, c’est une étape essentielle.

Mais la racine du problème des ordres fantômes ne disparaîtra pas avec une seule mise à jour. Tant que Polymarket maintiendra son mode de rapprochement hors chaîne et de règlement sur chaîne, il faudra continuer à gérer le décalage entre l’état hors chaîne et le résultat sur la chaîne. V2 est une première étape — résoudre d’abord les vulnérabilités les plus évidentes, puis continuer à améliorer le rapprochement, le règlement, la surveillance et la gestion des risques dans les versions suivantes.

Les marchés de prédiction traitent d’incertitude, et si même la structure des ordres est elle-même incertaine, les utilisateurs ne font plus face uniquement au risque de marché, mais aussi à celui du système.

Contenu associé

Polymarket bloqué : le véritable test de la fin du boom du trafic arrive