Polymarket Bot Tutorial · Chapitre 6 sur 32

Authentification du Polymarket bot et configuration du wallet: proxy wallets vs EOA, génération de clé API via SDK, sigType 2 pour Gnosis Safe, bonnes pratiques de stockage des clés, et la migration de Magic vers Privy.

Par Harley Young, rédactrice en chef chez Polymarkets.co.il. Dernière révision: mai 2026.

Ce que couvre ce chapitre

Le modèle de wallet de Polymarket comporte trois éléments principaux: un externally owned account (EOA) qui signe les ordres, un smart-contract proxy qui détient les fonds, et la clé API Polymarket CLOB qui authentifie les requêtes HTTP. Les configurer correctement est de loin l'échec le plus courant le premier jour pour les nouveaux builders, et cela est devenu encore plus confus après la migration d'août 2025 de Magic Labs vers Privy. Ce chapitre passe en revue chaque élément dans l'ordre de configuration, avec les variables d'environnement spécifiques et le flag de signature type dont le code de production a besoin.

  • Proxy wallet vs EOA: lequel utiliser pour botter
  • Générer une API key (étapes SDK)
  • sigType 2 et POLY_FUNDER_ADDRESS (Gnosis Safe)
  • Stockage des clés: .env, vault, KMS
  • La migration de Magic Labs vers Privy
  • Approbation des dépenses USDC/pUSD
  • Récupération et sauvegarde du wallet

Proxy wallet vs EOA: lequel utiliser pour botter

Polymarket utilise un modèle de smart-contract proxy wallet. Votre EOA - l'adresse liée à votre private key - signe les transactions et les ordres. Un Gnosis Safe déployé à une adresse déterministe détient le pUSD réel et les outcome shares. L'adresse proxy est celle qui apparaît dans le panneau "wallet" de l'interface Polymarket; l'EOA est ce qui signe.

Pour les bots, vous signez toujours avec l'EOA (PRIVATE_KEY dans l'env) et vous référencez l'adresse proxy comme POLY_FUNDER_ADDRESS dans la configuration du client CLOB. Envoyer des ordres avec l'EOA comme funder provoque des erreurs "insufficient balance" même lorsque le proxy est approvisionné.

Vous ne pouvez pas botter avec l'EOA seule - le flux web de Polymarket crée toujours un proxy lors de l'inscription. Confirmez les deux adresses avec polymarket wallet show depuis la CLI, ou lisez l'adresse proxy dans les paramètres de l'interface Polymarket.

Générer une API key (étapes SDK)

L'API CLOB nécessite trois credentials: key, secret, passphrase. Ce ne sont pas la private key de votre wallet - ce sont un ensemble de credentials de type HMAC liés à votre wallet, utilisés uniquement pour l'authentification des requêtes HTTP.

Générez-les une fois avec le SDK:

# Python
from py_clob_client.client import ClobClient
c = ClobClient(host="https://clob.polymarket.com", chain_id=137,
               key="<PRIVATE_KEY>", signature_type=2,
               funder="<PROXY_ADDRESS>")
creds = c.create_or_derive_api_creds()
print(creds.api_key, creds.api_secret, creds.api_passphrase)

Stockez la sortie dans un fichier JSON et chargez-la à chaque démarrage du bot; ne régénérez pas à chaque session - le serveur API met en cache l'ensemble de credentials, et une rotation trop fréquente peut déclencher la logique de rate limit. Les credentials n'expirent jamais automatiquement. Faites-les tourner uniquement si vous suspectez une fuite.

sigType 2 et POLY_FUNDER_ADDRESS (Gnosis Safe)

L'argument signature_type contrôle la manière dont le CLOB valide les signatures de vos ordres. Trois valeurs existent; deux sont réelles:

  • 0 / EOA: l'EOA est à la fois signataire et funder. Utilisé pour des configurations inhabituelles où les utilisateurs ont importé directement une private key.
  • 1 / POLY_PROXY: smart contract proxy hérité de Magic Labs. La plupart des comptes créés avant 2025.
  • 2 / POLY_GNOSIS_SAFE: standard actuel. Les fonds sont dans un Gnosis Safe, l'EOA signe.

Utilisez signature_type=2 pour tout compte créé après août 2025 (la migration Privy) ou tout compte pour lequel vous pouvez voir une adresse Gnosis Safe dans l'interface Polymarket. La variable d'environnement POLY_FUNDER_ADDRESS doit être l'adresse du Safe, pas celle de l'EOA. Un signature_type incohérent par rapport au type de funder produit silencieusement des rejets d'ordres qui ressemblent à "insufficient allowance" ou "balance: 0" - le message d'erreur est trompeur.

Stockage des clés: .env, vault, KMS

Trois niveaux de stockage raisonnables pour la private key de l'EOA.

  1. Fichier .env (développement sur une seule machine). Le fichier se trouve sur le VPS, le bot le lit au démarrage, la clé ne quitte jamais l'hôte. Suffisant pour des wallets de <1k$. chmod 600 .env et assurez-vous que le .gitignore de votre repo l'exclut.
  2. Vault auto-hébergé (HashiCorp Vault, fichier chiffré avec age, ou systemd-creds). Ajoute une étape de déverrouillage au démarrage du bot. Cela vaut le coup pour des wallets dans la plage 1k$-10k$.
  3. Cloud KMS (AWS KMS, GCP KMS). Le bot appelle KMS pour déchiffrer la clé en mémoire; la clé ne touche jamais le disque. Cela ne vaut la complexité opérationnelle qu'au-dessus de 10k$ ou pour des flottes multi-bot.

Ce qu'il ne faut jamais faire: committer une private key dans git, la coller dans un chat, la stocker dans un password manager qui se synchronise avec des services cloud sans mode local-only. Le rayon d'explosion on-chain d'une fuite de l'EOA Polymarket, c'est l'intégralité de votre solde pUSD et de votre inventaire d'outcome shares.

La migration de Magic Labs vers Privy

En août 2025, Polymarket a migré son principal fournisseur de embedded wallet de Magic Labs vers Privy. L'effet côté bot est faible mais précis.

Les comptes d'avant migration (créés via Magic) utilisent généralement signature_type=1 (POLY_PROXY). Les comptes créés après migration utilisent signature_type=2 (POLY_GNOSIS_SAFE). Certains utilisateurs ont migré leur ancien compte; d'autres ont conservé l'original. Il n'existe aucun moyen de savoir via l'API publique quel type votre compte utilise - vous le vérifiez en essayant de signer un ordre et en observant le rejet.

La migration a également changé la façon dont l'interface expose l'adresse du funder. Les anciens flux de l'interface Polymarket affichaient l'adresse proxy dans le tableau de bord; le flux actuel la cache dans les paramètres du compte. La commande CLI polymarket wallet show est la manière la plus simple de confirmer les deux valeurs, quelle que soit la date de création du compte.

Approbation des dépenses USDC/pUSD

Pour que le CLOB déplace votre pUSD lors de l'exécution d'un ordre, le proxy doit avoir approuvé les contrats d'échange Polymarket comme spenders. L'interface Polymarket définit ces approvals lors du premier dépôt. Pour les bots qui alimentent directement le proxy, vous devez les définir manuellement.

Trois approvals à définir, une fois par wallet:

  1. pUSD (ERC-20) → contrat d'exchange
  2. Conditional Tokens (ERC-1155) → contrat d'exchange (pour vendre des shares)
  3. Conditional Tokens (ERC-1155) → contrat d'exchange NegRisk (pour vendre des shares NegRisk)

Exécutez polymarket approve depuis la CLI lors de la première configuration. La transaction coûte quelques centimes en gas MATIC. Vérifiez avec polymarket approve check - les trois doivent renvoyer "approved." Le bug silencieux le plus courant pour les nouveaux builders est l'approval NegRisk manquante, qui n'échoue que lors de la vente de shares sur des marchés multi-outcomes et ressemble à une erreur de solde.

Récupération et sauvegarde du wallet

Le wallet du bot comporte deux éléments récupérables: la private key de l'EOA, et le mot de passe du compte Polymarket (qui contrôle l'accès via l'interface web mais pas via le SDK).

La private key de l'EOA est la seule chose qui compte pour le bot. Perte = perte de tout ce qui se trouve dans le proxy. Sauvegarde à froid: écrivez-la sur papier, scellez-la dans une enveloppe, conservez-la hors site. Sauvegarde à chaud: clé USB chiffrée. Ne vous l'envoyez jamais par email; ne la stockez jamais non chiffrée dans un cloud storage.

Le mot de passe du compte Polymarket est récupérable via la récupération email de Magic Labs / Privy tant que vous contrôlez encore l'email d'inscription d'origine. Il ne bloque pas l'accès au bot - le bot utilise directement la private key de l'EOA.

Si vous soupçonnez une fuite de clé: immédiatement retirez le pUSD et les tokens d'outcome vers un nouveau wallet, générez une nouvelle EOA, redéployez le bot avec la nouvelle clé. La clé divulguée ne peut pas être révoquée; elle ne peut qu'être vidée.

Questions fréquemment posées

Ai-je besoin d'un wallet séparé pour mon bot?
Oui, fortement recommandé. Utilisez une EOA fraîche ou un proxy wallet fraîchement dérivé d'un compte email qui ne contient que le capital que vous avez alloué au bot. Si la clé du bot fuit, seuls les fonds du bot sont menacés - vos avoirs principaux restent en sécurité.
Qu'est-ce que sigType 2 dans l'API Polymarkets?
sigType 2 indique une signature Gnosis Safe (proxy wallet), utilisée lorsque vous vous connectez avec email/Google et que Polymarket crée le proxy pour vous. Pour sigType 2, la variable d'environnement POLY_FUNDER_ADDRESS doit être l'adresse du PROXY (celle affichée dans l'interface Polymarket), et non l'EOA sous-jacente. C'est un bug de configuration courant.
Comment générer une Polymarket API key?
Utilisez le SDK. En Python: ApiCreds renvoyés par client.create_api_key() une fois que vous vous êtes authentifié avec votre wallet. En Node.js: similaire via @polymarket/clob-client-v2 client.createApiKey(). Enregistrez la key/secret/passphrase renvoyée dans votre .env (ne jamais committer dans git).
Les Polymarket API keys sont-elles révocables?
Oui. Vous pouvez dériver de nouvelles keys à tout moment via le SDK; les anciennes keys restent valides jusqu'à révocation explicite via client.deleteApiKey(creds). La bonne pratique consiste à faire tourner les keys périodiquement et à révoquer toute key ayant touché une machine compromise.
Qu'est-ce qui a changé lorsque Polymarket est passé de Magic Labs à Privy?
Les codes OTP de connexion sont passés de 3 chiffres (vulnérables au brute force, exploités dans le hack de décembre 2025) à des codes plus longs, avec device binding via Privy. Pour les bots, le changement pratique concerne la cérémonie d'auth - le SDK en abstrait la majeure partie. Si votre bot était codé en dur sur les endpoints API de Magic Labs (rare), mettez à jour vers le flux Privy.
Dois-je stocker les clés dans un fichier .env?
Pour un bot sur un seul VPS - oui, avec des permissions de fichier appropriées (chmod 600 .env, appartenant à l'utilisateur du bot). Pour des configurations multi-machines ou des opérations de niveau production - passez à un secrets manager (AWS Secrets Manager, Vault, doppler.com). Ne committer jamais .env dans git, jamais.