Polymarket Bot Tutorial · Chapitre 29 sur 32
Construisez un moteur de paper trading Polymarket avant de passer en live : simulez les ordres sur des prix réels, suivez le P&L, imposez le gate des 30 trades (>=55% de win rate, PnL positif) avant tout capital live, et codez le squelette.
Ce que ce chapitre couvre
Le paper trading est l’étape non négociable entre l’idée de stratégie et le déploiement en live. Ce chapitre présente le moteur de paper simple qui a servi de gate à chaque bot live que nous avons lancé - moins de 200 lignes de Python, suit chaque trade dans un journal JSONL, applique les mêmes fees/slippage que le chemin live.
- Pourquoi paper avant live (toujours)
- Le gate des 30 trades (WR vérifié +55% + PnL positif)
- Construire un moteur de paper simple
- Suivre le journal paper en parallèle du journal live
- Quand le paper diverge du live (et pourquoi)
- Passer au live : petit premier dépôt
- Code : moteur de paper minimal
Pourquoi paper avant live (toujours)
Le gate paper des 30 trades est la discipline unique qui sépare les 7,6% de traders Polymarket rentables des 84,1% qui perdent. La plupart des builders le sautent et paient les frais de scolarité. La raison honnête pour laquelle cela fonctionne : le paper trading révèle le vrai win rate d’une stratégie sur assez d’échantillons pour distinguer le signal de la chance.
Ne pas faire de paper coûte plus cher que cela n’économise. Une stratégie qui paraît rentable en backtest mais qui est en réalité pile ou face brûlera 200-500 $ de capital live avant de produire une taille d’échantillon de 30 trades en live. Faire du paper sur ces mêmes 30 trades coûte 0 $.
Le moteur de paper n’a pas besoin d’être sophistiqué. Il doit être honnête - mêmes fees, même slippage, même fill latency que le chemin live. Plus c’est simple, mieux c’est, car tout ce qui est optionnel finit coupé et le bot passe en live plus tôt qu’il ne le devrait.
Le gate des 30 trades (WR vérifié +55% + PnL positif)
Le gate est binaire : 30 paper trades clôturés, critères de succès définis à l’avance (généralement WR ≥ 55% pour une stratégie à EV positive), ou aucun déploiement live.
30 est la taille d’échantillon minimale à partir de laquelle l’intervalle de confiance à 95% sur le vrai win rate est suffisamment étroit pour distinguer le signal du bruit. En dessous de 30, un taux observé de 60% peut correspondre à un vrai taux de 45-75%. À partir de 30+, l’intervalle se resserre vers ~50-70% - encore large, mais suffisant pour exclure « la stratégie est pile ou face ».
Les critères de succès doivent être fixés AVANT le début du run paper. Les définir après coup produit une rationalisation post-hoc (vous trouverez toujours un moyen d’interpréter 30 trades comme « assez bien »).
Construire un moteur de paper simple
Le moteur de paper est essentiellement le code de trading live avec la fonction de placement d’ordre remplacée par un fill simulé. La simulation :
- Lit le order book live : même appel que celui que ferait le bot live.
- Simule le fill : si l’achat se fait en FOK avec un prix ≥ best ask, l’ordre est rempli au volume-weighted average des asks consommés ; enregistre le fill dans le journal paper.
- Applique les fees : soustrait les mêmes fees que le chemin live paierait.
- Suit l’inventaire : maintient un paper-balance et un dictionnaire de paper-positions parallèles.
L’ensemble tient en 100-200 lignes de Python. La discipline clé : chaque hypothèse faite par le chemin live (taux de fill, latency, fee) doit être reproduite en paper, même un peu pire que la réalité - le paper doit être le plancher, pas le plafond.
Suivre le journal paper en parallèle du journal live
Le run de paper trading produit un journal JSONL indiscernable dans sa structure du journal live que le bot écrira plus tard. Même champs : timestamp, action, market_slug, side, size, price, expected_fill_price, simulated_pnl_at_exit.
Deux raisons d’utiliser le même format. Premièrement, les outils d’analyse qui lisent les trades live (rapports de PnL, calculateurs de win rate) fonctionnent sur le paper sans modification. Deuxièmement, comparer paper et live plus tard permet de détecter des divergences qui révèlent des bugs.
Conseil de production : faites écrire par le moteur paper dans per_trade_paper.jsonl dans le même répertoire que le per_trade.jsonl live. Une seule commande compare les deux : diff -y <(jq -r .market_slug per_trade.jsonl) <(jq -r .market_slug per_trade_paper.jsonl).
Quand le paper diverge du live (et pourquoi)
Les divergences entre paper et live sont inévitables. Trois cas fréquents.
- Slippage : le paper remplit au snapshot du ask ; le live parcourt le book et peut remplir 1-2c moins bien sur des marchés peu liquides. Solution : simuler le slippage en paper en ajoutant une pénalité par trade égale à la moitié du spread.
- Fill latency : le paper remplit instantanément ; le live prend 200-500ms pendant lesquels le prix peut bouger. Solution : simuler en attendant et en relisant le book avant de « remplir » en paper.
- Adverse selection : le paper suppose que vous obtenez le meilleur ask ; le live se retrouve en concurrence avec d’autres bots qui ont peut-être déjà levé ce ask. Solution : plus difficile à simuler ; il faut se dire honnêtement que le paper surestime les performances.
Quand le paper affiche +5%/mois et que le live tourne à -2%/mois, l’écart vient généralement de l’un de ces points. Faites l’audit un par un au lieu de supposer que la stratégie elle-même était mauvaise.
Passer au live : petit premier dépôt
Le paper passe 30 trades. Plan de déploiement live :
- Déposez 25-50 $ comme capital de smoke-test. Considérez cela comme des frais de scolarité ; si vous le perdez, la leçon valait le coup.
- Faites tourner le bot en mode live pendant 5-10 trades avec des positions à la taille minimale (5 shares).
- Vérifiez que chaque fill correspond aux attentes du paper à 2c près. Enquêtez sur tout écart plus important avant de continuer.
- Si 5-10 trades live correspondent au paper, déposez 200-500 $ et lancez des positions de taille normale.
- S’ils ne correspondent pas, stoppez, debuggez, corrigez, redémarrez à l’étape 1.
L’écart live-paper le plus courant lors du premier déploiement est un fee manquant ou une mauvaise estimation du slippage. Corriger cela est simple ; la discipline consiste à détecter l’écart avant de scaler le capital.
Code : moteur de paper minimal
Référence : moteur de paper simple qui lit le book live + simule un fill FOK.
import json, time
PAPER_BAL = 10_000.0 # USD starting
positions = {} # token_id -> shares
def paper_fok_buy(token_id, max_price, size):
book = fetch_book(token_id)
# Walk asks, fill what we can within max_price
filled = 0; cost = 0
for level in book.asks:
px = float(level["price"])
if px > max_price: break
avail = float(level["size"])
take = min(avail, size - filled)
filled += take
cost += take * px
if filled >= size: break
if filled < size:
return {"status":"rejected","filled":0} # FOK semantics
global PAPER_BAL
PAPER_BAL -= cost
positions[token_id] = positions.get(token_id, 0) + filled
log_paper({"ts": int(time.time()), "action":"buy",
"token": token_id, "size": filled, "price": cost/filled})
return {"status":"matched","filled":filled,"cost":cost}Ajouts de production : fonction paper sell (miroir du buy), simulation paper GTC (poste sur le book à un prix donné, simule un fill quand le mid atteint le prix), réconciliation entre le journal paper et le journal live « qui aurait pu être ».
