Note de la rédaction : Polymarket a supprimé sans préavis le délai de 500 ms et introduit des frais dynamiques, rendant instantanément obsolètes de nombreux bots existants. Cet article explore ces changements et présente systématiquement la bonne façon de construire un bot de trading sous les nouvelles règles, en couvrant le mécanisme de frais, la signature des ordres, la logique de market making et l'architecture à faible latence, offrant ainsi une voie claire et exécutable.

Après sa publication, l'article a été vu 1,1 million de fois, suscitant des discussions approfondies. Sous les nouvelles règles de Polymarket, l'avantage se déplace de l'arbitrage des takers vers une structure à long terme centrée sur le market making et la fourniture de liquidités.

Voici l'article original :

Polymarket a discrètement supprimé le délai de 500 millisecondes

Explication claire : Sous les nouvelles règles, comment construire un bot qui fonctionne réellement et qui est rentable.

Il y a deux jours, Polymarket a supprimé le délai de 500 ms pour les offres des takers sur les marchés crypto. Aucune annonce, aucun avertissement. Du jour au lendemain, la moitié des bots sur la plateforme sont devenus inutiles. Mais simultanément, cela a créé la plus grande fenêtre d'opportunité pour de nouveaux bots depuis le lancement de Polymarket.

Aujourd'hui, je vais expliquer en détail : Sous les nouvelles règles, comment construire un bot qui reste efficace.

Parce que tous les modèles que vous avez vus avant le 18 février sont maintenant dépassés.

Si vous demandez maintenant à un modèle d'IA de vous écrire du code pour un bot Polymarket, il vous donnera certainement encore une solution basée sur les anciennes règles : interrogation REST, non-prise en charge des frais, ignorance totale de la disparition du tampon de 500ms.

Un tel bot perdra de l'argent dès sa première transaction.

Je vais expliquer : ce qui a changé exactement, et comment reconcevoir le bot autour de ces changements.

Qu'est-ce qui a changé ?

Au cours des deux derniers mois, trois changements clés se sont produits :

1. Le délai de 500 ms pour les takers a été supprimé (18 février 2026)

Auparavant, tous les ordres taker attendaient 500 ms avant exécution. Les market makers comptaient sur ce temps tampon pour annuler les offres « périmées », ce qui équivalait presque à une assurance gratuite.

Maintenant, c'est différent. Les ordres taker sont exécutés immédiatement, sans fenêtre d'annulation.

2. Introduction de frais dynamiques pour les takers sur les marchés crypto (Janvier 2026)

Les marchés crypto de 15 et 5 minutes facturent maintenant des frais aux takers, selon la formule : Frais = C × 0,25 × (p × (1 - p))²

Pic des frais : environ 1,56% près d'une probabilité de 50%

Frais proches de 0 dans les extrêmes de probabilité (proches de 0 ou 1)

Vous souvenez-vous de ce bot qui arbitrait les délais de prix entre Binance et Polymarket, gagnant 515 000 $ en un mois avec un taux de réussite de 99% ?

Cette stratégie est totalement morte. Parce que les frais eux-mêmes dépassent désormais l'écart exploitable.

Quelle est la nouvelle Méta ?

En un mot : soyez maker, pas taker.

La raison est simple :

· Les makers ne paient aucun frais

· Les makers peuvent recevoir des ristournes quotidiennes en USDC (subventionnées par les frais des takers)

· Après la suppression du délai de 500ms, les ordres des makers sont exécutés plus rapidement

Les bots les plus performants aujourd'hui sont déjà rentables rien qu'avec les ristournes, sans même besoin de capturer les écarts de prix. Si vous faites toujours un bot taker, vous faites face à une courbe de frais sans cesse croissante. Près de 50% de probabilité, vous avez besoin d'un avantage d'au moins 1,56% pour simplement atteindre le seuil de rentabilité.

Bonne chance.

Alors, comment devrait fonctionner un bot vraiment viable en 2026 ?

Voici une conception d'architecture de bot toujours efficace en 2026 :

Composants principaux :

1. Utilisez WebSocket, pas REST

L'interrogation REST est totalement obsolète. Le temps que votre requête HTTP fasse un aller-retour, l'opportunité est déjà passée. Vous avez besoin d'un flux de données en temps réel du carnet d'ordres basé sur WebSocket, pas d'un tirage intermittent.

2. Signature d'ordre tenant compte des frais (Fee-aware order signing)

C'est une nouvelle exigence qui n'existait pas auparavant. Désormais, dans la charge utile de l'ordre que vous signez, vous devez inclure le champ feeRateBps. Si vous omettez ce champ, l'ordre sera purement rejeté sur les marchés où les frais sont activés.

3. Boucle d'annulation / remplacement ultra-rapide (cancel / replace loop)

Après la suppression du tampon de 500ms : Si votre processus d'annulation-remplacement dépasse 200ms, vous subirez une « sélection adverse » (adverse selection). D'autres mangeront votre ordre périmé avant que vous ne mettiez à jour votre offre.

Comment configurer

1. Obtenez votre clé privée

Utilisez la même clé privée que pour vous connecter à Polymarket (EOA / MetaMask / portefeuille matériel)

export POLYMARKET_PRIVATE_KEY="0xyour_private_key_here"

2. Configurez l'autorisation (opération unique)

Avant que Polymarket puisse exécuter vos trades, vous devez d'abord autoriser les contrats suivants : USDC, jetons conditionnels (conditional tokens)

À faire une seule fois par portefeuille.

3. Connectez-vous au CLOB (Central Limit Order Book - Carnet d'ordres central)

Le client Python officiel peut être utilisé directement : pip install py-clob-client

Cependant, dans l'écosystème Rust, il existe désormais des options plus rapides :

· polyfill-rs (zéro allocation dans le chemin critique, analyse JSON SIMD, gain de performance d'environ 21%)

· polymarket-client-sdk (SDK Rust officiel de Polymarket)

· polymarket-hft (framework HFT complet, intégrant CLOB + WebSocket)

Le choix n'a pas d'importance, l'essentiel est de choisir une solution que vous pouvez déployer et faire fonctionner le plus rapidement possible.

4. Interrogez le taux de frais avant chaque placement d'ordre

GET /fee-rate?tokenID={token_id}

Ne codez jamais les frais en dur.
Les frais varient selon le marché, et Polymarket peut les ajuster à tout moment.

5. Incluez le champ de frais dans la signature de l'ordre

Lors de la signature de l'ordre, le champ des frais doit être inclus dans la charge utile. Sans cela, l'ordre ne sera pas accepté sur les marchés où les frais sont activés.

{
"salt": "...",
"maker": "0x...",
"signer": "0x...",
"taker": "0x...",
"tokenId": "...",
"makerAmount": "50000000",
"takerAmount": "100000000",
"feeRateBps": "150"
}

Le CLOB validera la signature de votre ordre en fonction du feeRateBps. Si le taux inclus dans la signature ne correspond pas au taux actuel, l'ordre sera purement rejeté.

Si vous utilisez le SDK officiel (Python ou Rust), cette logique est gérée automatiquement ; mais si vous implémentez votre propre logique de signature, vous devez la gérer vous-même, sinon l'ordre ne sera tout simplement pas envoyé.

6. Passez des ordres maker des deux côtés (achat et vente)

Fournissez de la liquidité au marché en passant des ordres limite : sur les jetons OUI et NON ; passez simultanément des ordres d'ACHAT et de VENTE. C'est le cœur de votre moyen d'obtenir des ristournes (rebates).

7. Exécutez la boucle d'annulation / remplacement (cancel / replace loop)

Vous devez surveiller simultanément : une source de prix externe (par exemple le WebSocket de Binance) ; vos ordres en cours sur Polymarket.

Dès que le prix change : Annulez immédiatement l'offre périmée ; Replacez un ordre au nouveau prix. L'objectif : contrôler toute la boucle en moins de 100 ms.

Note spéciale sur les marchés de 5 minutes

Le marché haussier/baissier du BTC sur des périodes de 5 minutes est déterministe.

Vous pouvez calculer directement le marché spécifique correspondant en utilisant uniquement l'horodatage :

Il y a 288 marchés par jour. Chacun est une nouvelle opportunité.

Stratégie actuellement validée : Dans les 10 secondes avant la fin de la fenêtre T–10, la direction haussière/baissière du BTC est déjà déterminée à environ 85%, mais les cotes sur Polymarket ne reflètent pas encore pleinement cette information.

La méthode opérationnelle est : Du côté avec la probabilité de gain la plus élevée ; passez des ordres maker à un prix de 0,90–0,95 $.

Si exécuté : À la liquidation, un profit de 0,05–0,10 $ par contrat ; zéro frais ; plus des ristournes (rebates).

Le véritable avantage vient de : votre capacité à déterminer la direction du BTC plus rapidement que les autres market makers, et à placer vos ordres plus tôt.

Erreurs courantes qui vous « élimineront » directement

· Utiliser encore REST au lieu de WebSocket

· Ne pas inclure feeRateBps dans la signature de l'ordre

· Exécuter le bot sur le Wi-Fi domestique (latence de 150 ms et plus, contre <5 ms pour un VPS en datacenter)

· Faire du market making près de l'intervalle de probabilité de 50% sans considérer le risque de sélection adverse

· Coder en dur le taux de frais

· Ne pas consolider les positions OUI / NON (ce qui bloque le capital)

· Utiliser encore la logique d'arbitrage taker de 2025

La bonne façon d'utiliser l'IA

La partie technique s'arrête ici. Maintenant vous maîtrisez : la conception de l'architecture, le calcul des frais, les nouvelles règles du marché.

Ensuite, vous pouvez ouvrir Claude ou n'importe quel modèle d'IA fiable, et lui donner une description de tâche suffisamment claire et spécifique, par exemple : « Voici le SDK de Polymarket. Aidez-moi à écrire un bot maker pour le marché BTC de 5 minutes : Surveiller le WebSocket de Binance pour obtenir le prix, Passer simultanément des ordres maker des côtés OUI et NON, Inclure feeRateBps dans la signature de l'ordre, Utiliser WebSocket pour obtenir les données du carnet d'ordres, Contrôler la boucle d'annulation/remplacement en moins de 100 ms. »

Le flux de travail correct est : Vous définissez la pile technique, l'infrastructure et les contraintes, l'IA génère la logique stratégique et d'implémentation spécifique sur cette base.

Bien sûr, même si vous décrivez la logique du bot parfaitement, vous devez absolument le tester avant le déploiement. Surtout à ce stade, où les frais commencent à réellement éroder les marges bénéficiaires, le backtesting sous la courbe de frais réelle est désormais une étape obligatoire avant le déploiement.

Le bot qui gagnera vraiment en 2026 n'est pas le taker le plus rapide, mais le meilleur fournisseur de liquidités.

Construisez votre système dans cette direction.