Polymarket Bot Tutorial · Chapitre 30 sur 32
Code de risk management de niveau production pour les bots Polymarket : position caps, daily loss limits, halt sentinels, fill-rate watchdogs, reconcile-on-restart, idempotent retries. Patterns de code tirés d'un trader de production réel.
Ce que couvre ce chapitre
Le code de risk représente la majeure partie d'un trading bot de production. La logique de stratégie est la partie la plus simple ; ce sont les caps, les halts, les watchdogs et les reconcilers qui déterminent si le bot survit à sa première mauvaise semaine. Ce chapitre présente le pattern de risk de niveau production.
- Pourquoi le code de risk est la majeure partie d'un vrai trading bot
- Position caps (par marché, par stratégie, total)
- Daily loss kill switch
- Halt sentinels (arrêt d'urgence basé sur un fichier)
- Fill-rate watchdog
- Reconcile du diary vs on-chain au redémarrage
- Code: boucle de production avec gestion des halts
Pourquoi le code de risk est la majeure partie d'un vrai trading bot
Une mesure que nous avons faite sur la base de code de notre propre bot : 60 % des LOC sont du code de risk (caps, halts, watchdogs, reconciliation). 30 % est de la stratégie. 10 % est du glue.
Ce ratio est correct. La stratégie est la partie facile - décrire quand entrer et quand sortir tient en quelques dizaines de lignes. Le code de risk, c'est tout le reste : quoi faire quand le prix évolue contre vous plus vite que prévu, quoi faire quand les fills cessent d'arriver, quoi faire quand le WebSocket tombe, quoi faire quand la stratégie se révèle non rentable.
La plupart des histoires d'échec de builders ont la même forme : la stratégie fonctionnait, mais le bot a continué à trader après un regime change parce qu'aucun halt ne s'est déclenché. Écrivez les halts avant d'écrire la stratégie.
Position caps (par marché, par stratégie, total)
Trois caps, appliqués dans le code.
- Per-market cap : maximum de $X par marché, quelle que soit la confiance dans l'edge. Typique : $25-100 pour les petits bots, $200-500 en production. Cela borne le blast radius d'un mauvais call sur un seul marché.
- Per-strategy cap : si vous exécutez plusieurs stratégies, chacune obtient une part du capital total. Typique : 30-50 % par stratégie. Cela empêche la mauvaise journée d'une stratégie de consommer le capital des autres.
- Total cap : pourcentage maximal du solde du wallet déployé simultanément. Typique : 50-70 %. Cela laisse du capital pour des opportunités inattendues ou pour attraper les bugs de bookkeeping du bot lui-même.
Les trois caps doivent être appliqués dans la fonction de placement d'ordre, pas seulement dans la logique de stratégie. La stratégie peut contenir un bug ; la gate de placement d'ordre est la dernière ligne de défense.
Daily loss kill switch
Le contrôle de risk le plus important à lui seul : un daily-loss kill switch.
Règle : si le PnL réalisé + non réalisé depuis minuit UTC passe sous -X % du solde journalier de départ, le bot cesse d'ouvrir de nouvelles positions et, éventuellement, flatten les positions existantes. X typique : 5-10 %.
Le calcul : un bot avec un taux de victoire attendu de 60 % a peut-être 5 % de chances d'enchaîner 10 pertes d'affilée. Sans kill switch, cette série s'amplifie : perte de $200 → le bot continue à trader → autre perte de $200 → wallet en baisse de 40 %. Avec le switch déclenché à -10 %, la mauvaise journée est plafonnée à $200, et le lendemain le bot repart de zéro.
Le switch est appliqué côté serveur : écrivez un fichier de halt ou définissez un flag de base de données que la boucle de trading vérifie à chaque itération. Redémarrez seulement après revue manuelle.
Halt sentinels (arrêt d'urgence basé sur un fichier)
Le mécanisme de halt le plus simple possible : le bot vérifie l'existence d'un fichier (par ex. /opt/pmt/HALT) à chaque itération de boucle et arrête de trader si le fichier existe.
def trading_loop():
while True:
if os.path.exists("/opt/pmt/HALT"):
log("HALT file detected, sleeping")
time.sleep(30)
continue
run_one_iteration()
time.sleep(5)Pour arrêter immédiatement depuis n'importe où (SSH, bot Telegram, système de monitoring) : touch /opt/pmt/HALT. Pour reprendre : rm /opt/pmt/HALT.
L'approche basée sur un fichier est volontairement low-tech parce qu'elle fonctionne dans des conditions où des mécanismes de halt plus sophistiqués échouent : quand le bot a partiellement crashé, quand la base de données est inaccessible, quand la clé API est rate-limited. L'accès au système de fichiers est toujours disponible.
Fill-rate watchdog
La stratégie suppose que les ordres FOK se remplissent à un certain taux (souvent 60-80 %). Lorsque ce taux chute fortement, quelque chose a changé : les market makers se sont retirés, votre stratégie a été identifiée, une API outage est en cours. Quelle qu'en soit la raison, l'hypothèse qui a servi de base au calcul du PnL de la stratégie est cassée.
Logique du watchdog : compteur glissant sur 24 heures du fill-rate. Si < 30 % (ou 50 % du niveau attendu), alerte + auto-halt. Reprise uniquement après revue manuelle.
Le watchdog est aussi utile comme outil de diagnostic. Une chute soudaine du fill-rate est généralement corrélée à un événement externe (déploiement Polymarket, congestion Polygon, votre IP mise en rate-limit) qu'il vaut mieux connaître indépendamment de l'impact sur le trading.
Reconcile du diary vs on-chain au redémarrage
Le bot maintient un diary des positions qu'il pense détenir. La chain détient la vérité. Ils devraient toujours être d'accord ; quand ce n'est pas le cas, le bot fonctionne sur une croyance erronée et va trader incorrectement.
Logique de reconciliation : à chaque redémarrage et une fois par heure en fonctionnement normal, récupérez les soldes on-chain de chaque token que le bot a touché. Comparez-les au diary ; alerte + halt si le solde d'un token diffère du diary de plus que la tolérance d'arrondi.
La cause la plus fréquente de divergence est un ordre réussi que l'appel API du bot a manqué (timeout, retry jamais enregistré). La chain a la position ; le bot pense ne pas l'avoir. Sans reconciliation, le bot ne placera pas la sortie take-profit et la position ira jusqu'à l'échéance.
Code: boucle de production avec gestion des halts
Référence : la boucle de trading de production avec tous les contrôles de risk branchés.
def production_loop():
while True:
# Halt checks
if os.path.exists("/opt/pmt/HALT"):
sleep_with_log(30); continue
if daily_pnl_below_threshold():
create_halt("daily PnL kill"); continue
# Reconcile every hour
if now() - last_reconcile > 3600:
ok = reconcile_diary_vs_chain()
last_reconcile = now()
if not ok: create_halt("reconciliation failed"); continue
# Fill-rate watchdog
if recent_fill_rate() < 0.30:
create_halt("fill rate collapse"); continue
# Strategy
try:
run_strategy_once()
except Exception as e:
log_exception(e)
if consecutive_exceptions >= 5:
create_halt(f"exceptions: {e}"); continue
time.sleep(5)Le pattern : chaque itération passe par la gate. Les bugs de stratégie ne peuvent pas contourner les contrôles, par construction.
